aboutgitcodebugslistschat
path: root/test/distro
diff options
context:
space:
mode:
authorStefano Brivio <sbrivio@redhat.com>2023-02-12 22:26:55 +0100
committerStefano Brivio <sbrivio@redhat.com>2023-02-12 22:26:55 +0100
commitcc6d8286d1043d04eb8518e39cebcb9e086dca17 (patch)
tree68c85479bf3d711f951aeefb53c5c811b502090e /test/distro
parentac153595c0427e994bad730ae760b4e0742ec30b (diff)
downloadpasst-cc6d8286d1043d04eb8518e39cebcb9e086dca17.tar
passt-cc6d8286d1043d04eb8518e39cebcb9e086dca17.tar.gz
passt-cc6d8286d1043d04eb8518e39cebcb9e086dca17.tar.bz2
passt-cc6d8286d1043d04eb8518e39cebcb9e086dca17.tar.lz
passt-cc6d8286d1043d04eb8518e39cebcb9e086dca17.tar.xz
passt-cc6d8286d1043d04eb8518e39cebcb9e086dca17.tar.zst
passt-cc6d8286d1043d04eb8518e39cebcb9e086dca17.zip
tcp: Reset ACK_FROM_TAP_DUE flag only as needed, update timer
David reports that TCP transfers might stall, especially with smaller socket buffer sizes, because we reset the ACK_FROM_TAP_DUE flag, in tcp_tap_handler(), whenever we receive an ACK segment, regardless of its sequence number and the fact that we might still be waiting for one. This way, we might fail to re-transmit frames on ACK timeouts. We need, instead, to: - indicate with the @retrans field only re-transmissions for the same data sequences. If we make progress, it should be reset, given that it's used to abort a connection when we exceed a given number of re-transmissions for the same data - unset the ACK_FROM_TAP_DUE flag if and only if the acknowledged sequence is the same as the last one we sent, as suggested by David - keep it set otherwise, if progress was done but not all the data we sent was acknowledged, and update the expiration of the ACK timeout Add a new helper for these purposes, tcp_update_seqack_from_tap(). To extend the ACK timeout, the new helper sets the ACK_FROM_TAP_DUE flag, even if it was already set, and conn_flag_do() triggers a timer update. This part should be revisited at a later time, because, strictly speaking, ACK_FROM_TAP_DUE isn't a flag anymore. One possibility might be to introduce another connection attribute for events affecting timer deadlines. Reported-by: David Gibson <david@gibson.dropbear.id.au> Link: https://bugs.passt.top/show_bug.cgi?id=41 Suggested-by: David Gibson <david@gibson.dropbear.id.au> Fixes: be5bbb9b0681 ("tcp: Rework timers to use timerfd instead of periodic bitmap scan") Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'test/distro')
0 files changed, 0 insertions, 0 deletions