Re: [PATCH net-next 1/2] tcp: do not set a zero size receive buffer

[Jakub Kicinski <kuba@kernel.org>]

On Mon, 21 Jul 2025 16:56:06 +0200 Paolo Abeni wrote:
> >> I *think* that catching only the !sk_rmem_alloc case would avoid the
> >> stall, but I think it's a bit 'late'.  
> > 
> > A packetdrill test here would help understanding your concern.  
> 
> I fear like a complete working script would take a lot of time, let me
> try to sketch just the relevant part:
> 
> # receiver state is:
> # rmem=110592 rcvbuf=174650 scaling_ratio=253 rwin=63232
> # no OoO data, no memory pressure,
> 
> # the incoming packet is in sequence
> +0 > P. 109297:172528(63232) ack 1
> 
> With just the 0 rmem check in tcp_prune_queue(), such function will
> still invoke tcp_clamp_window() that will shrink the receive buffer to
> 110592.
> tcp_collapse() can't make enough room and the incoming packet will be
> dropped. I think we should instead accept such packet.
> 
> Side note: the above data are taken from an actual reproduction of the issue
> 
> Please LMK if the above clarifies a bit my doubt or if a full pktdrill
> is needed.

Not the first time we stumble on packetdrills for scaling ratio.
Solving it is probably outside the scope of this discussion but 
I wonder what would be the best way to do it. My go to is to
integrate packetdrill with netdevsim and have an option for netdevsim
to inflate truesize on demand. But perhaps there's a clever way we can
force something like tap to give us the ratio we desire. Other ideas?