[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877bxm4zzk.fsf@cloudflare.com>
Date: Thu, 25 Sep 2025 11:56:31 +0200
From: Jakub Sitnicki <jakub@...udflare.com>
To: Michal Kubiak <michal.kubiak@...el.com>
Cc: intel-wired-lan@...ts.osuosl.org, maciej.fijalkowski@...el.com,
aleksander.lobakin@...el.com, jacob.e.keller@...el.com,
larysa.zaremba@...el.com, netdev@...r.kernel.org,
przemyslaw.kitszel@...el.com, pmenzel@...gen.mpg.de,
anthony.l.nguyen@...el.com
Subject: Re: [PATCH iwl-next v3 0/3] ice: convert Rx path to Page Pool
On Thu, Sep 25, 2025 at 11:22 AM +02, Michal Kubiak wrote:
> This series modernizes the Rx path in the ice driver by removing legacy
> code and switching to the Page Pool API. The changes follow the same
> direction as previously done for the iavf driver, and aim to simplify
> buffer management, improve maintainability, and prepare for future
> infrastructure reuse.
>
> An important motivation for this work was addressing reports of poor
> performance in XDP_TX mode when IOMMU is enabled. The legacy Rx model
> incurred significant overhead due to per-frame DMA mapping, which
> limited throughput in virtualized environments. This series eliminates
> those bottlenecks by adopting Page Pool and bi-directional DMA mapping.
>
> The first patch removes the legacy Rx path, which relied on manual skb
> allocation and header copying. This path has become obsolete due to the
> availability of build_skb() and the increasing complexity of supporting
> features like XDP and multi-buffer.
>
> The second patch drops the page splitting and recycling logic. While
> once used to optimize memory usage, this logic introduced significant
> complexity and hotpath overhead. Removing it simplifies the Rx flow and
> sets the stage for Page Pool adoption.
>
> The final patch switches the driver to use the Page Pool and libeth
> APIs. It also updates the XDP implementation to use libeth_xdp helpers
> and optimizes XDP_TX by avoiding per-frame DMA mapping. This results in
> a significant performance improvement in virtualized environments with
> IOMMU enabled (over 5x gain in XDP_TX throughput). In other scenarios,
> performance remains on par with the previous implementation.
>
> This conversion also aligns with the broader effort to modularize and
> unify XDP support across Intel Ethernet drivers.
>
> Tested on various workloads including netperf and XDP modes (PASS, DROP,
> TX) with and without IOMMU. No regressions observed.
Will we be able to have 256 B of XDP headroom after this conversion?
Thanks,
-jkbs
Powered by blists - more mailing lists