Re: [PATCH net] tcp: do not change rcv_ssthresh in tcp_measure_rcv_mss()

On Mon, Aug 3, 2026 at 1:09=E2=80=AFAM Paolo Abeni <[email protected]> wrot=
e:
>
> On 8/1/26 2:46 AM, Jakub Kicinski wrote:
> > On Fri, 24 Jul 2026 20:08:06 -0700 Nathan Gao wrote:
> >> Commit f5da7c45188e ("tcp: adjust rcvq_space after updating scaling
> >> ratio") replaced the direct window_clamp update in tcp_measure_rcv_mss=
()
> >> with a call to tcp_set_window_clamp(), a helper that implements the
> >> TCP_WINDOW_CLAMP setsockopt. As a side effect, the helper also shrinks
> >> rcv_ssthresh via __tcp_adjust_rcv_ssthresh().
> >>
> >> As a result, each scaling_ratio decrease detected by
> >> tcp_measure_rcv_mss() also cuts rcv_ssthresh. Elsewhere in TCP,
> >> rcv_ssthresh is usually cut under memory pressure and grows via
> >> tcp_grow_window().
> >>
> >> Flows whose segment sizes vary keep scaling_ratio oscillating, which
> >> leads to an unstable rcv_ssthresh: a dip of rcv_ssthresh only recovers
> >> via tcp_grow_window(), keeping the advertised window at a relatively
> >> low level even after the ratio itself has recovered, and can even stal=
l
> >> the sender.
> >>
> >> Observed on a customer's proxy gateway after upgrading from kernel 6.1
> >> to 6.12: in the worst case, rcv_ssthresh was cut in half by a
> >> scaling_ratio dip. P99 latency jumped from <10ms on 6.1 to ~100ms on
> >> 6.12, and almost returned to the 6.1 level with this patch applied.
> >>
> >> Restore the plain WRITE_ONCE() update of window_clamp, as introduced
> >> in commit a2cbb1603943 ("tcp: Update window clamping condition"), and
> >> keep the rcvq_space.space adjustment. Now rcv_ssthresh is decoupled fr=
om
> >> scaling_ratio changes in tcp_measure_rcv_mss().
> >>
> >> Fixes: f5da7c45188e ("tcp: adjust rcvq_space after updating scaling ra=
tio")
> >> Signed-off-by: Nathan Gao <[email protected]>
> >
> > Not sure, I mean regression is a regression, but also the previous
> > behavior seems to have just been lucky rather than correct in principle=
?
> >
> > Looks like Eric and Neal are AFK, Kuniyuki, Paolo, any opinion on this
> > patch?
> A quick grep confirm that except for f5da7c45188e, only the control path
> calls tcp_set_window_clamp(), which IMHO supports this patch rationale.
> My understanding is also that this patch should not re-introduce the
> issue addressed by the blamed commit.

+1, and

>
> It would be great to have a pktdrill tests for at least one of the 2

+1.  I also told Nathan offlist that it would be nicer to write a
packetdrill test.


> relevant scenarios (the one described here and the one relevant for
> f5da7c45188e). My totally uneducated impression is that writing a packet
> drill for the case described here should be slightly less difficult than
> the other option, as there is no MTU dependency.
>
> TL;DR: I *think* this patch make sense, pktdrill would be helpful but
> not a blocker.
>
> /P
>