On Tue, 10 Mar 2026 21:00:49 -0700 Dipayaan Roy wrote: > On certain systems configured with 4K PAGE_SIZE, utilizing page_pool > fragments for RX buffers results in a significant throughput regression. > Profiling reveals that this regression correlates with high overhead in the > fragment allocation and reference counting paths on these specific > platforms, rendering the multi-buffer-per-page strategy counterproductive.
Can you say more ? We could technically take two references on the page right away if MTU is small and avoid some of the cost. The driver doesn't seem to set skb->truesize accordingly after this change. So you're lying to the stack about how much memory each packet consumes. This is a blocker for the change. > To mitigate this, bypass the page_pool fragment path and force a single RX > packet per page allocation when all the following conditions are met: > 1. The system is configured with a 4K PAGE_SIZE. > 2. A processor-specific quirk is detected via SMBIOS Type 4 data. I don't think we want the kernel to be in the business of carrying matching on platform names and providing optimal config by default. This sort of logic needs to live in user space or the hypervisor (which can then pass a single bit to the driver to enable the behavior) > This approach restores expected line-rate performance by ensuring > predictable RX refill behavior on affected hardware. > > There is no behavioral change for systems using larger page sizes > (16K/64K), or platforms where this processor-specific quirk do not > apply. -- pw-bot: cr
