[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id:
<171210843482.14193.13072464299514068706.git-patchwork-notify@kernel.org>
Date: Wed, 03 Apr 2024 01:40:34 +0000
From: patchwork-bot+netdevbpf@...nel.org
To: Alexander Lobakin <aleksander.lobakin@...el.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, lorenzo@...nel.org, toke@...hat.com,
nex.sw.ncis.osdt.itp.upstreaming@...el.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 0/2] page_pool: allow direct bulk recycling
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@...nel.org>:
On Fri, 29 Mar 2024 17:55:05 +0100 you wrote:
> Previously, there was no reliable way to check whether it's safe to use
> direct PP cache. The drivers were passing @allow_direct to the PP
> recycling functions and that was it. Bulk recycling is used by
> xdp_return_frame_bulk() on .ndo_xdp_xmit() frames completion where
> the page origin is unknown, thus the direct recycling has never been
> tried.
> Now that we have at least 2 ways of checking if we're allowed to perform
> direct recycling -- pool->p.napi (Jakub) and pool->cpuid (Lorenzo), we
> can use them when doing bulk recycling as well. Just move that logic
> from the skb core to the PP core and call it before
> __page_pool_put_page() every time @allow_direct is false.
> Under high .ndo_xdp_xmit() traffic load, the win is 2-3% Pps assuming
> the sending driver uses xdp_return_frame_bulk() on Tx completion.
>
> [...]
Here is the summary with links:
- [net-next,1/2] page_pool: check for PP direct cache locality later
https://git.kernel.org/netdev/net-next/c/4a96a4e807c3
- [net-next,2/2] page_pool: try direct bulk recycling
https://git.kernel.org/netdev/net-next/c/39806b96c89a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Powered by blists - more mailing lists