aboutgitcodebugslistschat
path: root/Makefile
diff options
context:
space:
mode:
authorJon Maloy <jmaloy@redhat.com>2024-06-04 14:29:08 -0400
committerStefano Brivio <sbrivio@redhat.com>2024-06-05 21:13:16 +0200
commite84a01e94c9f0ced5b1c0a6b87c053c01c686c86 (patch)
tree4e9d5a54bb2acc02a93db3a191e48e18c20453ac /Makefile
parent765eb0bf1651d20ca319eeb8b41ff35f52f2a29c (diff)
downloadpasst-e84a01e94c9f0ced5b1c0a6b87c053c01c686c86.tar
passt-e84a01e94c9f0ced5b1c0a6b87c053c01c686c86.tar.gz
passt-e84a01e94c9f0ced5b1c0a6b87c053c01c686c86.tar.bz2
passt-e84a01e94c9f0ced5b1c0a6b87c053c01c686c86.tar.lz
passt-e84a01e94c9f0ced5b1c0a6b87c053c01c686c86.tar.xz
passt-e84a01e94c9f0ced5b1c0a6b87c053c01c686c86.tar.zst
passt-e84a01e94c9f0ced5b1c0a6b87c053c01c686c86.zip
tcp: move seq_to_tap update to when frame is queued
commit a469fc393fa1 ("tcp, tap: Don't increase tap-side sequence counter for dropped frames") delayed update of conn->seq_to_tap until the moment the corresponding frame has been successfully pushed out. This has the advantage that we immediately can make a new attempt to transmit a frame after a failed trasnmit, rather than waiting for the peer to later discover a gap and trigger the fast retransmit mechanism to solve the problem. This approach has turned out to cause a problem with spurious sequence number updates during peer-initiated retransmits, and we have realized it may not be the best way to solve the above issue. We now restore the previous method, by updating the said field at the moment a frame is added to the outqueue. To retain the advantage of having a quick re-attempt based on local failure detection, we now scan through the part of the outqueue that had do be dropped, and restore the sequence counter for each affected connection to the most appropriate value. Signed-off-by: Jon Maloy <jmaloy@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions