diff options
author | David Gibson <david@gibson.dropbear.id.au> | 2023-01-06 11:43:08 +1100 |
---|---|---|
committer | Stefano Brivio <sbrivio@redhat.com> | 2023-01-23 18:54:33 +0100 |
commit | f1d2d3541689e099c6d360204b1afa662437695d (patch) | |
tree | eed49f5fd9f747866545dcc4afcc74558e3b2139 /tap.c | |
parent | 99f0be3cad2292c61c79cef1afeb5cc2ba8507c2 (diff) | |
download | passt-f1d2d3541689e099c6d360204b1afa662437695d.tar passt-f1d2d3541689e099c6d360204b1afa662437695d.tar.gz passt-f1d2d3541689e099c6d360204b1afa662437695d.tar.bz2 passt-f1d2d3541689e099c6d360204b1afa662437695d.tar.lz passt-f1d2d3541689e099c6d360204b1afa662437695d.tar.xz passt-f1d2d3541689e099c6d360204b1afa662437695d.tar.zst passt-f1d2d3541689e099c6d360204b1afa662437695d.zip |
tcp: Don't compute total bytes in a message until we need it
tcp[46]_l2_buf_bytes keep track of the total number of bytes we have
queued to send to the tap interface. tcp_l2_buf_flush_passt() uses this
to determine if sendmsg() has sent all the data we requested, or whether
we need to resend a trailing portion.
However, the logic for finding where we're up to in the case of a short
sendmsg() can equally well tell whether we've had one at all, without
knowing the total number in advance. This does require an extra loop after
each sendmsg(), but it's doing simple arithmetic on values we've already
been accessing, and it leads to overall simpler code.
tcp[46]_l2_flags_buf_bytes were being calculated, but never used for
anything, so simply remove them.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'tap.c')
0 files changed, 0 insertions, 0 deletions