diff options
| author | Jakub Kicinski <[email protected]> | 2024-04-03 01:13:51 +0000 |
|---|---|---|
| committer | Jakub Kicinski <[email protected]> | 2024-04-03 01:13:51 +0000 |
| commit | eb05529a106a2803f1360952041e9bf5a94183e2 (patch) | |
| tree | 78701c158045e79d05961247fd068dad9fe12d3c /drivers/net/dsa/microchip/ksz_spi.c | |
| parent | rhashtable: Improve grammar (diff) | |
| parent | page_pool: try direct bulk recycling (diff) | |
| download | kernel-eb05529a106a2803f1360952041e9bf5a94183e2.tar.gz kernel-eb05529a106a2803f1360952041e9bf5a94183e2.zip | |
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/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Diffstat (limited to 'drivers/net/dsa/microchip/ksz_spi.c')
0 files changed, 0 insertions, 0 deletions
