diff options
author | Stefano Brivio <sbrivio@redhat.com> | 2024-11-19 20:53:43 +0100 |
---|---|---|
committer | Stefano Brivio <sbrivio@redhat.com> | 2024-11-21 06:51:25 +0100 |
commit | af464c4ffbb7a5341f8a7beedce8382d598dbaf7 (patch) | |
tree | 410cad2ae6dd3dda0e38851f7faa810019bc390b | |
parent | 5ae21841acd7f55a4b57b99a5097ca99b84f07c4 (diff) | |
download | passt-af464c4ffbb7a5341f8a7beedce8382d598dbaf7.tar passt-af464c4ffbb7a5341f8a7beedce8382d598dbaf7.tar.gz passt-af464c4ffbb7a5341f8a7beedce8382d598dbaf7.tar.bz2 passt-af464c4ffbb7a5341f8a7beedce8382d598dbaf7.tar.lz passt-af464c4ffbb7a5341f8a7beedce8382d598dbaf7.tar.xz passt-af464c4ffbb7a5341f8a7beedce8382d598dbaf7.tar.zst passt-af464c4ffbb7a5341f8a7beedce8382d598dbaf7.zip |
tcp: Reset ACK_TO_TAP_DUE flag whenever an ACK isn't needed anymore
We enter the timer handler with the ACK_TO_TAP_DUE flag, call
tcp_prepare_flags() with ACK_IF_NEEDED, and realise that we
acknowledged everything meanwhile, so we return early, but we also
need to reset that flag to avoid unnecessarily scheduling the timer
over and over again until more pending data appears.
I'm not sure if this fixes any real issue, but I've spotted this
in several logs reported by users, including one where we have some
unexpected bursts of high CPU load during TCP transfers at low rates,
from https://github.com/containers/podman/issues/23686.
Link: https://github.com/containers/podman/discussions/24572
Link: https://github.com/containers/podman/issues/23686
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
-rw-r--r-- | tcp.c | 4 |
1 files changed, 3 insertions, 1 deletions
@@ -1235,8 +1235,10 @@ int tcp_prepare_flags(const struct ctx *c, struct tcp_tap_conn *conn, int s = conn->sock; if (SEQ_GE(conn->seq_ack_to_tap, conn->seq_from_tap) && - !flags && conn->wnd_to_tap) + !flags && conn->wnd_to_tap) { + conn_flag(c, conn, ~ACK_TO_TAP_DUE); return 0; + } if (getsockopt(s, SOL_TCP, TCP_INFO, &tinfo, &sl)) { conn_event(c, conn, CLOSED); |