diff options
author | Jakub Kicinski <kuba@kernel.org> | 2024-04-02 18:13:51 -0700 |
---|---|---|
committer | Jakub Kicinski <kuba@kernel.org> | 2024-04-02 18:13:51 -0700 |
commit | eb05529a106a2803f1360952041e9bf5a94183e2 (patch) | |
tree | 78701c158045e79d05961247fd068dad9fe12d3c /drivers/net/dsa/microchip/ksz_spi.c | |
parent | 8db2509faa331865903a81a92f15c449e821b1d7 (diff) | |
parent | 39806b96c89ae5d52092c8f86393ecbfaae26697 (diff) |
Merge branch 'page_pool-allow-direct-bulk-recycling'
Alexander Lobakin says:
====================
page_pool: allow direct bulk recycling
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.
====================
Link: https://lore.kernel.org/r/20240329165507.3240110-1-aleksander.lobakin@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'drivers/net/dsa/microchip/ksz_spi.c')
0 files changed, 0 insertions, 0 deletions