Re: [PATCH iwl-next v2 1/2] libeth: add libeth_rx_alloc_gfp() to specify allocation flags

[Luigi Rizzo]

On Fri, Oct 23, 2026 at 3:35 PM Alexander Lobakin
<aleksander.lobakin@xxxxxxxxx> wrote:
>
> From: Luigi Rizzo <lrizzo@xxxxxxxxxx>
> Date: Mon, 19 Oct 2026 21:06:03 +0000
>
> > libeth_rx_alloc() calls page_pool_dev_alloc_netmem(), which always
> > allocates with GFP_ATOMIC | __GFP_NOWARN. Drivers also use it to fill
> > their Rx rings at open or on queue reconfiguration, which runs in
> > process context before the queues' NAPI is enabled. There, the caller
> > may sleep and GFP_ATOMIC is needlessly restrictive: it can neither
> > reclaim nor compact, while the initial fill can allocate tens of
> > thousands of buffers across all queues.
> >
> > Add libeth_rx_alloc_gfp(), which takes a gfp_t parameter and passes
> > gfp | __GFP_NOWARN to page_pool_alloc_netmem(), and make
> > libeth_rx_alloc() its GFP_ATOMIC wrapper.
>
> If you'd really like to go ahead (I'm still not really convinced, even

To be clear, GFP_ATOMIC is not a problem right now, but it becomes
a problem if we try to back the buffers with 2MB pages as in DMA_PMD,
and those 2MB pages may not be available without sleeping.

> with "O(100k)" which is not that realistic),

On a large system, which is definitely the target for a 200G NIC that uses idpf,
we can easily get there and above.
The system I am testing now uses 4096 slots per queue, 32 queues,
meaning 128K entries at initialization. Under load, the pool has grown
to 197K entries.

Ok for the style changes, will resend an updated version

cheers
luigi