netdev - Re: [PATCH iwl-next v3 0/3] ice: convert Rx path to Page Pool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <182d8f19-aca7-482e-8983-3806ebb837ba@intel.com>
Date: Thu, 25 Sep 2025 10:22:16 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Jakub Sitnicki <jakub@...udflare.com>, Michal Kubiak
	<michal.kubiak@...el.com>
CC: <intel-wired-lan@...ts.osuosl.org>, <maciej.fijalkowski@...el.com>,
	<aleksander.lobakin@...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 9/25/2025 2:56 AM, Jakub Sitnicki wrote:
> 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

We should. The queues are configured through libeth, and set the xdp
field if its enabled on that ring:

> @@ -622,8 +589,14 @@ static unsigned int ice_get_frame_sz(struct ice_rx_ring *rx_ring)
>   */
>  static int ice_vsi_cfg_rxq(struct ice_rx_ring *ring)
>  {
> +	struct libeth_fq fq = {
> +		.count		= ring->count,
> +		.nid		= NUMA_NO_NODE,
> +		.xdp		= ice_is_xdp_ena_vsi(ring->vsi),
> +		.buf_len	= LIBIE_MAX_RX_BUF_LEN,
> +	};


If .xdp is set, then the libeth Rx configuration reserves
LIBETH_XDP_HEADROOM, which is XDP_PACKET_HEADROOM aligned to
NET_SKB_PAD, + an extra NET_IP_ALIGN, which results in 258 bytes of
headroom reserved.

Thanks,
Jake


Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)