[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251024075027.3178786-1-edumazet@google.com>
Date: Fri, 24 Oct 2025 07:50:24 +0000
From: Eric Dumazet <edumazet@...gle.com>
To: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>
Cc: Simon Horman <horms@...nel.org>, Neal Cardwell <ncardwell@...gle.com>,
Willem de Bruijn <willemb@...gle.com>, Kuniyuki Iwashima <kuniyu@...gle.com>,
Matthieu Baerts <matttbe@...nel.org>, Mat Martineau <martineau@...nel.org>,
Geliang Tang <geliang@...nel.org>, netdev@...r.kernel.org, eric.dumazet@...il.com,
Eric Dumazet <edumazet@...gle.com>
Subject: [PATCH net-next 0/3] tcp: fix receive autotune again
Neal Cardwell found that recent kernels were having RWIN limited
issues, even when net.ipv4.tcp_rmem[2] was set to a very big value like 512MB
He suspected that tcp_stream default buffer size (64KB) was triggering
heuristic added in ea33537d8292 ("tcp: add receive queue awareness
in tcp_rcv_space_adjust()").
After more testing, it turns out the bug was added earlier
with commit 65c5287892e9 ("tcp: fix sk_rcvbuf overshoot").
I forgot once again that DRS has one RTT latency.
MPTCP also got the same issue.
This series :
- adds rcv_ssthresh, window_clamp and rcv_wnd to trace_tcp_rcvbuf_grow().
- Refactors code in a patch with no functional changes.
- Fixes the issue in the final patch.
Eric Dumazet (3):
trace: tcp: add three metrics to trace_tcp_rcvbuf_grow()
tcp: add newval parameter to tcp_rcvbuf_grow()
tcp: fix too slow tcp_rcvbuf_grow() action
include/net/tcp.h | 2 +-
include/trace/events/tcp.h | 9 +++++++++
net/ipv4/tcp_input.c | 21 ++++++++++++++-------
net/mptcp/protocol.c | 23 +++++++++++++++--------
4 files changed, 39 insertions(+), 16 deletions(-)
--
2.51.1.821.gb6fe4d2222-goog
Powered by blists - more mailing lists