Hi Wesley, On Tue, Mar 24, 2026 at 02:53:01PM -0600, Wesley Atwell wrote: > Add a packetdrill reproducer for the free_space-limited scaled > no-shrink quantization case. > > Grow rcv_ssthresh with in-order data, then queue tiny OOO skbs so > receive memory drives raw free_space just below rcv_ssthresh without > advancing rcv_nxt. The final ACK reaches the case where raw free_space > sits just above 84 scaled units while rcv_ssthresh stays slightly > larger.
While this may be the intended behavior, this test case does not actually demonstrate this: After the second in-order packet rcv_nxt == rcv_wup == 11024 and rcv_wnd is 84*1024 (with your patch). Even if __tcp_select_window() returns smaller values as more and more OOO packets get queued, the externally visible advertised window can't go below 84, as the advertised window can't shrink (as you point out in your cover letter). > Old code rounds that final free_space value up and advertises 85. With > the fix, the ACK stays at 84. The old code is consistent as well, it simply uses 85 throughout: ... +0 < P. 19024:19025(1) ack 1 win 257 * > . 1:1(0) ack 11024 win 85 // The last tiny OOO skb pushes raw free_space just below rcv_ssthresh // without crossing the next lower scaled unit. +0 < P. 20024:20025(1) ack 1 win 257 * > . 1:1(0) ack 11024 win 85 So, like the v1 version, this test demonstrates that the offered window differs when constrained by rcv_ssthresh (old: 83, 85, 85, ... ; new: 82, 84, 84, ...). But as this window cannot shrink, OOO packets will not cause the peer-visible window to change in this scenario (for either the old or the new code). - Simon -- Simon Baatz <[email protected]>
