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: <CAL+tcoBkzggvE=3Y4jeeY9BnnBkNTFXjxN1H1ceKkDGg1ktzAQ@mail.gmail.com>
Date: Sat, 8 Nov 2025 00:20:34 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Eric Dumazet <edumazet@...gle.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 Sat, Nov 8, 2025 at 12:08 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> 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)

Thanks for your suggestion!

However, sorry, I didn't get it totally. I'm wondering what the
difference between freeing only 32 and freeing half of the new value
is? My thought was freeing the half, say, 128/2, which minimizes more
times of performing skb free functions. Could you shed some light on
those numbers?

Thanks,
Jason