Hi Eric, On Fri, Feb 20, 2026 at 09:58:00AM +0100, Eric Dumazet wrote: > Hi Simon, thanks for the clean series. > > I would guess you use some AI ? This is fine, just curious.
Thank you! Yes, Iâve found AI helpful for getting familiar with a new code base. I also use it to refine or clean up the wording of bigger commit messages. Code generation works quite well for quick, throwâaway code (like reproducers). > Can you add more tests, in memory stress situations ? > > Like : > > A receiver grew the RWIN over time up to 8 MB. > > Then the application (or the kernel under stress) used SO_RCVBUF to 16K. > > I want to make sure the socket wont accept packets to fill the prior > window and consume 8MB I suspect generating 8â¯MB worth of RX data in packetdrill won't be fun (unless thereâs a trick Iâm missing). And using regular TCP sockets on both ends would probably be rather uninteresting (no packets sent once RWIN = 0) It might be more practical to extend one of the tests to create two situations in packetdrill: 1. Zero window: 0 == RWIN < 2 * squeezed SO_RCVBUF < tracked max. RWIN < 2 * original SO_RCVBUF 2. Small window: 0 < RWIN < 2 * squeezed SO_RCVBUF < tracked max. RWIN < 2 * original SO_RCVBUF If these limits are sufficiently distinct, we could probe tcp_sequence() and tcp_data_queue() paths in detail using: * pure ACK or data packet * in-order or out-of order * within, partially within, or beyond (max) window If we can show that we can't use more memory than expected for the squeezed buffer, then the original max window size shouldnât really matter. wdyt? - Simon -- Simon Baatz <[email protected]>
