aboutgitcodebugslistschat
path: root/test/lib
diff options
context:
space:
mode:
authorStefano Brivio <sbrivio@redhat.com>2025-12-04 06:43:16 +0100
committerStefano Brivio <sbrivio@redhat.com>2025-12-08 09:15:36 +0100
commit9139e60fd455fafb753c838e554732aed5ecbcd3 (patch)
tree6ab076ee3d75cc812abd457e4d0e23bcb8802369 /test/lib
parent28f413d0332c923f1a4a7a05359d90116cbcb4a3 (diff)
downloadpasst-9139e60fd455fafb753c838e554732aed5ecbcd3.tar
passt-9139e60fd455fafb753c838e554732aed5ecbcd3.tar.gz
passt-9139e60fd455fafb753c838e554732aed5ecbcd3.tar.bz2
passt-9139e60fd455fafb753c838e554732aed5ecbcd3.tar.lz
passt-9139e60fd455fafb753c838e554732aed5ecbcd3.tar.xz
passt-9139e60fd455fafb753c838e554732aed5ecbcd3.tar.zst
passt-9139e60fd455fafb753c838e554732aed5ecbcd3.zip
tcp: Acknowledge everything if it looks like bulk traffic, not interactive
...instead of checking if the current sending buffer is less than SNDBUF_SMALL, because this isn't simply an optimisation to coalesce ACK segments: we rely on having enough data at once from the sender to make the buffer grow by means of TCP buffer size tuning implemented in the Linux kernel. This is important if we're trying to maximise throughput, but not desirable for interactive traffic, where we want to be transparent as possible and avoid introducing unnecessary latency. Use the tcpi_delivery_rate field reported by the Linux kernel, if available, to calculate the current bandwidth-delay product: if it's significantly smaller than the available sending buffer, conclude that we're not bandwidth-bound and this is likely to be interactive traffic, so acknowledge data only as it's acknowledged by the peer. Conversely, if the bandwidth-delay product is comparable to the size of the sending buffer (more than 5%), we're probably bandwidth-bound or... bound to be: acknowledge everything in that case. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'test/lib')
0 files changed, 0 insertions, 0 deletions