RE: [Intel-wired-lan] [PATCH iwl-next] idpf: add flow-based XDP fallback for FWs without Tx FIFO support

[Loktionov, Aleksandr]

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@xxxxxxxxxx> On Behalf
> Of Alexander Lobakin
> Sent: Wednesday, July 8, 2026 5:13 PM
> To: intel-wired-lan@xxxxxxxxxxxxxxxx
> Cc: Lobakin, Aleksander <aleksander.lobakin@xxxxxxxxx>; Nguyen,
> Anthony L <anthony.l.nguyen@xxxxxxxxx>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@xxxxxxxxx>; Andrew Lunn <andrew+netdev@xxxxxxx>;
> David S. Miller <davem@xxxxxxxxxxxxx>; Eric Dumazet
> <edumazet@xxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx>; Paolo Abeni
> <pabeni@xxxxxxxxxx>; Simon Horman <horms@xxxxxxxxxx>; NXNE CNSE OSDT
> ITP Upstreaming <nxne.cnse.osdt.itp.upstreaming@xxxxxxxxx>;
> netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> Subject: [Intel-wired-lan] [PATCH iwl-next] idpf: add flow-based XDP
> fallback for FWs without Tx FIFO support
> 
> From the first days of XDP implementation in idpf, it relied and
> worked solely on top of the queue-based scheduling Tx mode, which
> basically means simple FIFO. However, turned out not every firmware
> supports this mode and XDP doesn't work there at all.
> 
> Since the flow-based scheduling Tx mode is mandatory and supported by
> every FW, introduce a simple fallback guarded by a static key to not
> hurt the more performant mode. The FB mode generates a completion for
> each Tx descriptor and never guarantees that there won't be any out-
> of-order completions. Serialize that using a bitmap of completed
> descriptors and report contiguous blocks of free bits to match XDP and
> XSk expectations and avoid further code complication.
> 
> The usage of a bitmap on hotpath might sound scary, but this fallback
> is able to reach around 70% of the QB mode's performance, which is
> comparable to what ice gives us. The main bottlenecks are unlikely()s
> and one completion per each descriptor, while in the QB mode we have
> one completion per batch (which might contain 64 or even 128 frames),
> plus the size of the completion descriptor is
> 8 bytes in this mode (4 bytes in the QB mode), which means a lot of
> additional PCI traffic.
> 
> bloat-o-meter shows .text increase in about 2 Kb without adding new
> functions or uninlining any of the existing ones. I played a bunch
> with inlining and uninlining certain pieces or the whole fallback, but
> the compiler collapses and optimizes libeth templates so hardly so
> that each additional external call only makes things worse.
> 
> Signed-off-by: Alexander Lobakin <aleksander.lobakin@xxxxxxxxx>
> ---
>  drivers/net/ethernet/intel/idpf/idpf.h      |   1 +
>  drivers/net/ethernet/intel/idpf/idpf_txrx.h |  11 +-
>  drivers/net/ethernet/intel/idpf/xdp.h       |  60 +++++++++-
>  include/net/libeth/xdp.h                    |  13 +++
>  drivers/net/ethernet/intel/idpf/idpf_txrx.c |  10 +-
>  drivers/net/ethernet/intel/idpf/xdp.c       | 115
> +++++++++++++++++++-
>  6 files changed, 201 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/idpf/idpf.h
> b/drivers/net/ethernet/intel/idpf/idpf.h
> index ec1b75f039bb..5414bbbee07a 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf.h
> +++ b/drivers/net/ethernet/intel/idpf/idpf.h
> @@ -384,6 +384,7 @@ struct idpf_vport {
>  	struct idpf_tx_queue **txqs;
>  	u16 num_txq;
>  	u16 num_xdp_txq;

...


>  	old = cfg->user_config.xdp_prog;
>  	cfg->user_config.xdp_prog = prog;
> 
> --
> 2.55.0

Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@xxxxxxxxx>