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: <de4ce073-5df8-4d00-ab26-c42ce73a5f48@intel.com>
Date: Wed, 19 Nov 2025 18:51:54 +0100
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Jason Xing <kerneljasonxing@...il.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

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,
Olek