netdev - Re: [PATCH net-next 0/4] net: adjust conservative values around napi

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+tcoCyQm0QxAJkJCFzFZK1Q2Zz1v=zQZWcTzq7jY5Nu6QU3A@mail.gmail.com>
Date: Thu, 20 Nov 2025 07:56:57 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Alexander Lobakin <aleksander.lobakin@...el.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, 
	pabeni@...hat.com, horms@...nel.org, netdev@...r.kernel.org, 
	Jason Xing <kernelxing@...cent.com>
Subject: Re: [PATCH net-next 0/4] net: adjust conservative values around napi

On Thu, Nov 20, 2025 at 1:52 AM Alexander Lobakin
<aleksander.lobakin@...el.com> wrote:
>
> From: Jason Xing <kerneljasonxing@...il.com>
> Date: Tue, 18 Nov 2025 15:06:42 +0800
>
> > From: Jason Xing <kernelxing@...cent.com>
> >
> > This series keeps at least 96 skbs per cpu and frees 32 skbs at one
> > time in conclusion. More initial discussions with Eric can be seen at
> > the link [1].
> >
> > [1]: https://lore.kernel.org/all/CAL+tcoBEEjO=-yvE7ZJ4sB2smVBzUht1gJN85CenJhOKV2nD7Q@mail.gmail.com/
> >
> > ---
> > Please note that the series is made on top of the recent series:
> > https://lore.kernel.org/all/20251116202717.1542829-1-edumazet@google.com/
> >
> > Jason Xing (4):
> >   net: increase default NAPI_SKB_CACHE_SIZE to 128
> >   net: increase default NAPI_SKB_CACHE_BULK to 32
> >   net: use NAPI_SKB_CACHE_FREE to keep 32 as default to do bulk free
> >   net: prefetch the next skb in napi_skb_cache_get()
> >
> >  net/core/skbuff.c | 20 ++++++++++++--------
> >  1 file changed, 12 insertions(+), 8 deletions(-)
>
> For the series:
>
> Reviewed-by: Alexander Lobakin <aleksander.lobakin@...el.com>
>
> BTW I picked these numbers of 64 (size), 16 (bulk), 32 (free) when I was
> working on 1G NICs/switches on a 32-bit MIPS board back in 2020. Lots of
> things have changed since then and even back then, these numbers could
> be suboptimal for faster NICs/architectures (and yes, the cache never
> was NUMA aware as the MIPS arch code doesn't support even building the
> kernel in the "NUMA simulation" mode).
>
> I remember clearly that the cache size of 64 was taken to match
> NAPI_POLL_WEIGHT.
> The size of bulk to allocate was conservative, but back then it gave the
> best perf numbers. I believe the bulk allocator has improved a lot for
> the past years (note that let's say cpumap still allocates only 8 skbs
> per bulk, not sure about veth).
>
> Anyway, lots of things around NAPI caches have changed since then,
> especially when it comes to how the kernel now tries to free the skb on
> the same CPU it was allocated on. So I'm glad to see these parameters
> tweaked.

Thanks for sharing the important background :) I believe along with
the fast development of NICs we still have many things to work on in
the kernel.

Thanks,
Jason