Re: [PATCH net] tcp: reduce tcp_comp_sack_slack_ns default value to 10 usec

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 14 Nov 2025 06:08:58 -0800 Eric Dumazet wrote:
> On Fri, Nov 14, 2025 at 5:51 AM Eric Dumazet <edumazet@google.com> wrote:
> >
> > net.ipv4.tcp_comp_sack_slack_ns current default value is too high.
> >
> > When a flow has many drops (1 % or more), and small RTT, adding 100 usec
> > before sending SACK stalls the sender relying on getting SACK
> > fast enough to keep the pipe busy.
> >
> > Decrease the default to 10 usec.
> >
> > This is orthogonal to Congestion Control heuristics to determine
> > if drops are caused by congestion or not.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>  
> 
> This was meant for net-next, but applying this to net tree should be
> fine as well.
> 
> No need for backports though.

Sorry to piggy back on a random post but looks like the changes from
a ~week ago made ncdevmem flaky: 

https://netdev.bots.linux.dev/contest.html?executor=vmksft-fbnic-qemu&test=devmem-py

Specifically it says:

using ifindex=3
using queues 2..3
got tx dmabuf id=5
Connect to 2001:db8:1::2 37943 (via enp1s0)
sendmsg_ret=6
ncdevmem: did not receive tx completion

This is what was in the branch that made the test fail:

[+] tcp: add net.ipv4.tcp_comp_sack_rtt_percent
[+] net: increase skb_defer_max default to 128
[+] net: fix napi_consume_skb() with alien skbs
[+] net: allow skb_release_head_state() to be called multiple times

https://netdev.bots.linux.dev/static/nipa/branch_deltas/net-next-hw-2025-11-08--00-00.html

I'm guessing we need to take care of the uarg if we defer freeing 
of Tx skbs..