Re: [PATCH net-next 2/2] tcp: add net.ipv4.tcp_rtt_threshold sysctl

[Paolo Abeni <pabeni@redhat.com>]

Hi,

On 11/17/25 2:28 PM, Eric Dumazet wrote:
> This is a follow up of commit aa251c84636c ("tcp: fix too slow
> tcp_rcvbuf_grow() action") which brought again the issue that I tried
> to fix in commit 65c5287892e9 ("tcp: fix sk_rcvbuf overshoot")
> 
> We also recently increased tcp_rmem[2] to 32 MB in commit 572be9bf9d0d
> ("tcp: increase tcp_rmem[2] to 32 MB")
> 
> Idea of this patch is to not let tcp_rcvbuf_grow() grow sk->sk_rcvbuf
> too fast for small RTT flows. If sk->sk_rcvbuf is too big, this can
> force NIC driver to not recycle pages from the page pool, and also
> can cause cache evictions for DDIO enabled cpus/NIC, as receivers
> are usually slower than senders.
> 
> Add net.ipv4.tcp_rtt_threshold sysctl, set by default to 1000 usec (1 ms)
> If RTT if smaller than the sysctl value, use the RTT/tcp_rtt_threshold
> ratio to control sk_rcvbuf inflation.
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

I gave this series a spin in my test-bed: 2 quite old hosts b2b
connected via 100Gbps links. RTT is < 100us. Doing bulk/iperf3 tcp
transfers, with irq and user-space processes pinned.

The average tput for 30s connections does not change measurably: ~23Gbps
per connection. WRT the receiver buffer, in 30 runs prior to this patch
I see:

min 1901769, max 4322922 avg 2900036

On top of this series:

min 1078047 max 3967327 avg 2465665.

So I do see smaller buffers on average, but I'm not sure I'm hitting the
 reference scenario (notably the lowest value here is considerably
higher than the theoretical minimum rcvwin required to handle the given
B/W).

Should I go for longer (or shorter) connections?

Thanks,

Paolo