aboutgitcodebugslistschat
path: root/Makefile
diff options
context:
space:
mode:
authorStefano Brivio <sbrivio@redhat.com>2023-03-21 23:14:58 +0100
committerStefano Brivio <sbrivio@redhat.com>2023-03-21 23:14:58 +0100
commit1ee2f7cada9e6f739a00d39bb9821f1ce3493d92 (patch)
treea6f948febc8f47e3a7f958f222fe3f7ec342c96e /Makefile
parent9ffccf7acc98c1b22b9b5e0b22c55fca7760a7df (diff)
downloadpasst-1ee2f7cada9e6f739a00d39bb9821f1ce3493d92.tar
passt-1ee2f7cada9e6f739a00d39bb9821f1ce3493d92.tar.gz
passt-1ee2f7cada9e6f739a00d39bb9821f1ce3493d92.tar.bz2
passt-1ee2f7cada9e6f739a00d39bb9821f1ce3493d92.tar.lz
passt-1ee2f7cada9e6f739a00d39bb9821f1ce3493d92.tar.xz
passt-1ee2f7cada9e6f739a00d39bb9821f1ce3493d92.tar.zst
passt-1ee2f7cada9e6f739a00d39bb9821f1ce3493d92.zip
tcp: Don't reset ACK_TO_TAP_DUE on any ACK, reschedule timer as needed2023_03_21.1ee2f7c
This is mostly symmetric with commit cc6d8286d104 ("tcp: Reset ACK_FROM_TAP_DUE flag only as needed, update timer"): we shouldn't reset the ACK_TO_TAP_DUE flag on any inbound ACK segment, but only once we acknowledge everything we received from the guest or the container. If we don't, a client might unnecessarily hold off further data, especially during slow start, and in general we won't converge to the usable bandwidth. This is very visible especially with traffic tests on links with non-negligible latency, such as in the reported issue. There, a public iperf3 server sometimes aborts the test due do what appears to be a low iperf3's --rcv-timeout (probably less than a second). Even if this doesn't happen, the throughput will converge to a fraction of the usable bandwidth. Clear ACK_TO_TAP_DUE if we acknowledged everything, set it if we didn't, and reschedule the timer in case the flag is still set as the timer expires. While at it, decrease the ACK timer interval to 10ms. A 50ms interval is short enough for any bandwidth-delay product I had in mind (local connections, or non-local connections with limited bandwidth), but here I am, testing 1gbps transfers to a peer with 100ms RTT. Indeed, we could eventually make the timer interval dependent on the current window and estimated bandwidth-delay product, but at least for the moment being, 10ms should be long enough to avoid any measurable syscall overhead, yet usable for any real-world application. Reported-by: Lukas Mrtvy <lukas.mrtvy@gmail.com> Link: https://bugs.passt.top/show_bug.cgi?id=44 Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions