Re: [PATCH iwl-next v2 0/2] libeth, idpf: use GFP_KERNEL for the initial Rx ring fill

[Luigi Rizzo]

On Wed, Oct 21, 2026 at 4:57 PM Alexander Lobakin
<aleksander.lobakin@xxxxxxxxx> wrote:
>
> From: Luigi Rizzo <lrizzo@xxxxxxxxxx>
> Date: Mon, 19 Oct 2026 21:06:02 +0000
>
> > libeth_rx_alloc() always allocates with GFP_ATOMIC, including when a
> > driver fills its Rx rings at open or on queue reconfiguration. That
> > fill runs in process context, right after page_pool_create() and before
> > the queues' NAPI is enabled, so it may sleep, and GFP_ATOMIC is
> > needlessly restrictive there: it can neither reclaim nor compact, while
> > the initial fill can allocate tens of thousands of buffers across all
> > queues.
> >
> > Patch 1 adds libeth_rx_alloc_gfp() taking a gfp_t parameter and turns
> > libeth_rx_alloc() into its GFP_ATOMIC wrapper.
> > Patch 2 switches idpf's initial Rx ring fill (both splitq and singleq)
> > to GFP_KERNEL.
>
> This is done for simplicity and performance reasons (although I've just
> realized that this helper is fully inline, so it will inline your new
> GFP argument as well).
>
> But could anyone explain me why the initial fill is bad to do with
> GFP_ATOMIC?

It might not be so bad now, but consider something like DMA-PMD
https://lore.kernel.org/all/20261003212241.3432303-1-lrizzo@xxxxxxxxxx/
that allocates buffers from larger chunks to reduce IOTLB pressure
and iommu-related costs.

An innocent request for one buffer could cause the pagepool provider
to request a higher order page, which in turn may require some
compaction work and sleeping.

Using GFP_ATOMIC could cause unnecessary allocation failures
if pages are not readily available (and in O(100K) allocations
something could easily go wrong).

FWIW other drivers are not very consistent in their use of flags for
initial allocations, but I think this is more to simplify code reuse
(as you pointed out) than for a real requirement.

cheers
luigi