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

-----Original Message-----
From: Intel-wired-lan <redacted> On Behalf
Of Alexander Lobakin
Sent: Wednesday, July 8, 2026 5:13 PM
To: intel-wired-lan@lists.osuosl.org
Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Nguyen,
Anthony L [off-list ref]; Kitszel, Przemyslaw
[off-list ref]; Andrew Lunn [off-list ref];
David S. Miller [off-list ref]; Eric Dumazet
[off-list ref]; Jakub Kicinski [off-list ref]; Paolo Abeni
[off-list ref]; Simon Horman [off-list ref]; NXNE CNSE OSDT
ITP Upstreaming [off-list ref];
netdev@vger.kernel.org; linux-kernel@vger.kernel.org
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@intel.com>
---
 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;