aboutgitcodebugslistschat
path: root/port_fwd.c
diff options
context:
space:
mode:
authorStefano Brivio <sbrivio@redhat.com>2023-09-22 23:35:08 +0200
committerStefano Brivio <sbrivio@redhat.com>2023-10-04 23:39:58 +0200
commita469fc393fa1dfadc7c51c2729550597ee171a8e (patch)
treeb8252a1d499ec87a2f20ffb187c53c7d17c77bcc /port_fwd.c
parentd3192f67c492f6caa3d0779ae016c34e3d847b22 (diff)
downloadpasst-a469fc393fa1dfadc7c51c2729550597ee171a8e.tar
passt-a469fc393fa1dfadc7c51c2729550597ee171a8e.tar.gz
passt-a469fc393fa1dfadc7c51c2729550597ee171a8e.tar.bz2
passt-a469fc393fa1dfadc7c51c2729550597ee171a8e.tar.lz
passt-a469fc393fa1dfadc7c51c2729550597ee171a8e.tar.xz
passt-a469fc393fa1dfadc7c51c2729550597ee171a8e.tar.zst
passt-a469fc393fa1dfadc7c51c2729550597ee171a8e.zip
tcp, tap: Don't increase tap-side sequence counter for dropped frames
...so that we'll retry sending them, instead of more-or-less silently dropping them. This happens quite frequently if our sending buffer on the UNIX domain socket is heavily constrained (for instance, by the 208 KiB default memory limit). It might be argued that dropping frames is part of the expected TCP flow: we don't dequeue those from the socket anyway, so we'll eventually retransmit them. But we don't need the receiver to tell us (by the way of duplicate or missing ACKs) that we couldn't send them: we already know as sendmsg() reports that. This seems to considerably increase throughput stability and throughput itself for TCP connections with default wmem_max values. Unfortunately, the 16 bits left as padding in the frame descriptors we use internally aren't enough to uniquely identify for which connection we should update sequence numbers: create a parallel array of pointers to sequence numbers and L4 lengths, of TCP_FRAMES_MEM size, and go through it after calling sendmsg(). Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'port_fwd.c')
0 files changed, 0 insertions, 0 deletions