netdev - Re: [PATCH net-next 3/3] net: increase skb_defer

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: <CANn89i+4OKrAq6DPZ_=MeDhGmEXDn6k-dRrEyzO8pmy=hN6VwA@mail.gmail.com>
Date: Fri, 7 Nov 2025 08:08:40 -0800
From: Eric Dumazet <edumazet@...gle.com>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	Kuniyuki Iwashima <kuniyu@...gle.com>, Willem de Bruijn <willemb@...gle.com>, netdev@...r.kernel.org, 
	eric.dumazet@...il.com
Subject: Re: [PATCH net-next 3/3] net: increase skb_defer_max default to 128

On Fri, Nov 7, 2025 at 8:04 AM Jason Xing <kerneljasonxing@...il.com> wrote:
>
> On Sat, Nov 8, 2025 at 12:00 AM Eric Dumazet <edumazet@...gle.com> wrote:
> >
> > On Fri, Nov 7, 2025 at 7:50 AM Jason Xing <kerneljasonxing@...il.com> wrote:
> > >
> > > On Fri, Nov 7, 2025 at 11:47 PM Eric Dumazet <edumazet@...gle.com> wrote:
> > > >
> > > > On Fri, Nov 7, 2025 at 7:37 AM Jason Xing <kerneljasonxing@...il.com> wrote:
> > > > >
> > > > > On Fri, Nov 7, 2025 at 4:30 AM Eric Dumazet <edumazet@...gle.com> wrote:
> > > > > >
> > > > > > skb_defer_max value is very conservative, and can be increased
> > > > > > to avoid too many calls to kick_defer_list_purge().
> > > > > >
> > > > > > Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> > > > >
> > > > > I was thinking if we ought to enlarge NAPI_SKB_CACHE_SIZE() to 128 as
> > > > > well since the freeing skb happens in the softirq context, which I
> > > > > came up with when I was doing the optimization for af_xdp. That is
> > > > > also used to defer freeing skb to obtain some improvement in
> > > > > performance. I'd like to know your opinion on this, thanks in advance!
> > > >
> > > > Makes sense. I even had a patch like this in my queue ;)
> > >
> > > Great to hear that. Look forward to seeing it soon :)
> >
> > Oh please go ahead !
>
> Okay, thanks for letting me post this minor change. I just thought you
> wanted to do this on your own :P
>
> Will do it soon :)

Note that I was thinking to free only 32 skbs if we fill up the array
completely.

Current code frees half of it, this seems better trying to keep 96
skbs and free 32 of them.

Same for the bulk alloc, we could probably go to 32 (instead of 16)