From: Jakub Kicinski <kuba@kernel.org>
To: edumazet@google.com
Cc: davem@davemloft.net, netdev@vger.kernel.org, pabeni@redhat.com,
andrew+netdev@lunn.ch, horms@kernel.org, ncardwell@google.com,
kuniyu@google.com, willemb@google.com, dsahern@kernel.org,
quic_subashab@quicinc.com, quic_stranche@quicinc.com
Subject: Re: [PATCH net] tcp: update window_clamp when SO_RCVBUF is set
Date: Wed, 8 Apr 2026 11:11:07 -0700 [thread overview]
Message-ID: <20260408111107.077659c6@kernel.org> (raw)
In-Reply-To: <20260408001438.129165-1-kuba@kernel.org>
On Tue, 7 Apr 2026 17:14:38 -0700 Jakub Kicinski wrote:
> Commit under Fixes moved recomputing the window clamp to
> tcp_measure_rcv_mss() (when scaling_ratio changes).
> I suspect it missed the fact that we don't recompute the clamp
> when rcvbuf is set. Until scaling_ratio changes we are
> stuck with the old window clamp which may be based on
> the small initial buffer. scaling_ratio may never change.
>
> Inspired by Eric's recent commit d1361840f8c5 ("tcp: fix
> SO_RCVLOWAT and RCVBUF autotuning") plumb the user action
> thru to TCP and have it update the clamp.
>
> A smaller fix would be to just have tcp_rcvbuf_grow()
> adjust the clamp even if SOCK_RCVBUF_LOCK is set.
> But IIUC this is what we were trying to get away from
> in the first place.
Hi Eric, any thoughts?
I always assume you are displeased if you don't reply within 8 hours :)
I should say that everyone has obviously discouraged the team that run
into this from using SO_RCVBUF. I'm fascinated by how they decided that
it helps since it clearly doesn't work. AI sure makes it easy for
people to "try things". Sigh.
next prev parent reply other threads:[~2026-04-08 18:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 0:14 [PATCH net] tcp: update window_clamp when SO_RCVBUF is set Jakub Kicinski
2026-04-08 18:11 ` Jakub Kicinski [this message]
2026-04-08 18:13 ` Eric Dumazet
2026-04-08 19:27 ` Eric Dumazet
2026-04-13 13:40 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260408111107.077659c6@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuniyu@google.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=quic_stranche@quicinc.com \
--cc=quic_subashab@quicinc.com \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.