netdev - Re: [PATCH net] tcp: reduce tcp_comp_sack_slack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89iLJGwBunzho9+Q1aRDgA3ihw=OrEuT3cBDiZn2QmVNkWA@mail.gmail.com>
Date: Fri, 14 Nov 2025 11:35:12 -0800
From: Eric Dumazet <edumazet@...gle.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "David S . Miller" <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, 
	Simon Horman <horms@...nel.org>, Neal Cardwell <ncardwell@...gle.com>, 
	Kuniyuki Iwashima <kuniyu@...gle.com>, netdev@...r.kernel.org, eric.dumazet@...il.com
Subject: Re: [PATCH net] tcp: reduce tcp_comp_sack_slack_ns default value to
 10 usec

On Fri, Nov 14, 2025 at 8:17 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Fri, Nov 14, 2025 at 8:03 AM Jakub Kicinski <kuba@...nel.org> wrote:
> >
> > On Fri, 14 Nov 2025 06:08:58 -0800 Eric Dumazet wrote:
> > > On Fri, Nov 14, 2025 at 5:51 AM Eric Dumazet <edumazet@...gle.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@...gle.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..
>
> Makes sense, or expedite/force the IPI if these skbs are 'deferred'
>
> I did not complete the series to call skb_data_unref() from
> skb_attempt_defer_free().
> I hope to finish this soon.
>

In the meantime we could add this  fix:

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index f34372666e67cee5329d3ba1d3c86f8622facac3..12d65357fc7f83cfa9f8714227c7b69035441644
100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1480,6 +1480,9 @@ void napi_consume_skb(struct sk_buff *skb, int budget)
        DEBUG_NET_WARN_ON_ONCE(!in_softirq());

        if (skb->alloc_cpu != smp_processor_id() && !skb_shared(skb)) {
+               if (skb_zcopy(skb))
+                       return consume_skb(skb);
+
                skb_release_head_state(skb);
                return skb_attempt_defer_free(skb);
        }