Re: [PATCH net-next v4 0/6] page_pool: a couple of assorted optimizations

[Alexander Lobakin <aleksander.lobakin@intel.com>]

From: Patchwork-Bot+netdevbpf <patchwork-bot+netdevbpf@kernel.org>
Date: Mon, 07 Aug 2023 20:20:23 +0000

> Hello:
> 
> This series was applied to netdev/net-next.git (main)
> by Jakub Kicinski <kuba@kernel.org>:

Just got back from the long weekend and saw that mail, nice :D Thanks!

> 
> On Fri,  4 Aug 2023 20:05:23 +0200 you wrote:
>> That initially was a spin-off of the IAVF PP series[0], but has grown
>> (and shrunk) since then a bunch. In fact, it consists of three
>> semi-independent blocks:
>>
>> * #1-2: Compile-time optimization. Split page_pool.h into 2 headers to
>>   not overbloat the consumers not needing complex inline helpers and
>>   then stop including it in skbuff.h at all. The first patch is also
>>   prereq for the whole series.
>> * #3: Improve cacheline locality for users of the Page Pool frag API.
>> * #4-6: Use direct cache recycling more aggressively, when it is safe
>>   obviously. In addition, make sure nobody wants to use Page Pool API
>>   with disabled interrupts.
>>
>> [...]
> 
> Here is the summary with links:
>   - [net-next,v4,1/6] page_pool: split types and declarations from page_pool.h
>     https://git.kernel.org/netdev/net-next/c/a9ca9f9ceff3
>   - [net-next,v4,2/6] net: skbuff: don't include <net/page_pool/types.h> to <linux/skbuff.h>
>     https://git.kernel.org/netdev/net-next/c/75eaf63ea7af
>   - [net-next,v4,3/6] page_pool: place frag_* fields in one cacheline
>     https://git.kernel.org/netdev/net-next/c/06d0fbdad612
>   - [net-next,v4,4/6] net: skbuff: avoid accessing page_pool if !napi_safe when returning page
>     https://git.kernel.org/netdev/net-next/c/5b899c33b3b8
>   - [net-next,v4,5/6] page_pool: add a lockdep check for recycling in hardirq
>     https://git.kernel.org/netdev/net-next/c/ff4e538c8c3e
>   - [net-next,v4,6/6] net: skbuff: always try to recycle PP pages directly when in softirq
>     https://git.kernel.org/netdev/net-next/c/4a36d0180c45
> 
> You are awesome, thank you!

Thanks,
Olek