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

[Alexander Lobakin <aleksander.lobakin@intel.com>]

From: Luigi Rizzo <lrizzo@google.com>
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?

> 
> v2:
>   - split into two patches (libeth helper and idpf consumer)
> v1: https://lore.kernel.org/r/20261016151835.2500807-1-lrizzo@google.com/
> 
> Luigi Rizzo (2):
>   libeth: add libeth_rx_alloc_gfp() to specify allocation flags
>   idpf: use GFP_KERNEL for the initial Rx ring fill
> 
>  .../ethernet/intel/idpf/idpf_singleq_txrx.c   |  7 +++---
>  drivers/net/ethernet/intel/idpf/idpf_txrx.c   |  9 +++++---
>  drivers/net/ethernet/intel/idpf/idpf_txrx.h   |  2 +-
>  include/net/libeth/rx.h                       | 23 +++++++++++++++----
>  4 files changed, 30 insertions(+), 11 deletions(-)

Thanks,
Olek