On Thu, Apr 9, 2026 at 2:24 PM Simon Baatz <[email protected]> wrote: > > Hi Eric, > > On Thu, Apr 09, 2026 at 07:52:03AM -0700, Eric Dumazet wrote: > > On Wed, Apr 8, 2026 at 2:50???PM Simon Baatz via B4 Relay > > <[email protected]> wrote: > > > > > > Hi, > > > > > > this series ensures that rcv_wnd and window_clamp do not exceed the > > > maximum window size representable for the connection's window scale > > > factor. > > > > > > This is most visible when TCP window scaling is not used for a > > > connection. In that case, the advertised window is limited to 65535 > > > bytes, but rcv_wnd or window_clamp can still grow beyond 65535 when > > > large receive buffers are used. The resulting mismatch breaks > > > calculations that depend on the advertised window, such as the ACK > > > decision in __tcp_ack_snd_check(), and can prevent immediate ACKs. > > > > > > Similar effects may also occur when window scaling is in use, e.g. if > > > the application dynamically adjusts SO_RCVBUF in unusual ways or when > > > the rmem sysctl parameters change during a connection???s lifetime. > > > > > > Summary: > > > > > > - Patch 1 keeps rcv_wnd capped by the (window scale-limited) > > > window_clamp at connection start. > > > - Patch 3 and 6 ensure that window_clamp is limited to the > > > representable window when it is updated. > > > - The other patches add packetdrill tests to verify the new behavior. > > > > > > A simple iperf test on a virtme-ng VM (Intel i5-7500, 4 cores, > > > loopback) shows a noticeable improvement with window scaling disabled: > > > > Explain why we should spend time reviewing patches trying to help > > stacks from 2 decades ago, > > risking breaking other usages. > > > > Almost every time we change the rcvbuf logic, we introduce bugs. > > As soon as someone gives me access to a link with a bandwidth delay > product of probably > 500 MB I am happy to provide another set of > benchmarks results: > > `./defaults.sh > sysctl -q net.ipv4.tcp_rmem="4096 2147483647 2147483647"`
Please do not do this. Stick to reasonable limits. You might have missed that we are flooded with bug reports (and buggy patches). We have very limited time for bugs not proven by real-world conditions.
