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: <CANn89iJr4R4dgFmqCPtSWqgvPiY5YB4svD_4D7tO1BoZr=Y1-Q@mail.gmail.com>
Date: Fri, 14 Nov 2025 08:17:47 -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: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.

Thanks.