Re: [PATCH net-next v1 07/11] xsk: Deliver provider chunks without copying

["Björn Töpel" <bjorn@kernel.org>]

Maciej Fijalkowski <maciej.fijalkowski@intel.com> writes:

> On Tue, Nov 10, 2026 at 11:20:28AM +0100, Björn Töpel wrote:
>> A provider socket still receives through the copy path, which takes
>> FILL entries without the provider's ownership checks: a chunk that a
>> page pool holds could be handed out twice. No driver opts in yet.
>> 
>> Put packets whose buffers all belong to the socket's provider on the
>> RX ring as they are, and copy others into chunks the provider claims.
>> Only the queue NAPI may produce to such a socket, so generic XDP and
>> CPUMAP redirects to it are dropped.
>> 
>> A device may place payload at chunk offset 0, as fbnic does, so only
>> the first buffer of a packet keeps the UMEM headroom. Such buffers may
>> be sent back as they are, so only descriptors with XDP_TX_METADATA
>> need room for TX metadata in front.
>> 
>> Signed-off-by: Björn Töpel <bjorn@kernel.org>
>> ---
>>  Documentation/networking/af_xdp.rst          |   6 +-
>>  Documentation/networking/xsk-tx-metadata.rst |   3 +-
>>  include/net/page_pool/memory_provider.h      |   2 +
>>  net/core/page_pool.c                         |  34 +++-
>>  net/xdp/xsk.c                                |  82 ++++++++-
>>  net/xdp/xsk.h                                |   5 +
>>  net/xdp/xsk_pp.c                             | 165 +++++++++++++++++++
>>  net/xdp/xsk_queue.h                          |  18 +-
>>  8 files changed, 304 insertions(+), 11 deletions(-)
>> 
>
> (...)
>
>> +
>>  static int xsk_pp_nl_fill(void *mp_priv, struct sk_buff *rsp,
>>  			  struct netdev_rx_queue *rxq)
>>  {
>> diff --git a/net/xdp/xsk_queue.h b/net/xdp/xsk_queue.h
>> index 1bc42c8902f4..b9464b917a88 100644
>> --- a/net/xdp/xsk_queue.h
>> +++ b/net/xdp/xsk_queue.h
>> @@ -156,17 +156,24 @@ static inline bool xp_unused_options_set(u32 options)
>>  	return options & ~(XDP_PKT_CONTD | XDP_TX_METADATA);
>>  }
>>  
>> +static inline u32 xp_desc_meta_len(struct xsk_buff_pool *pool,
>> +				   struct xdp_desc *desc)
>> +{
>> +	return desc->options & XDP_TX_METADATA ? pool->tx_metadata_len : 0;
>
> How is it related to this patch? I know I trimmed, but I didn't see any
> references above to tx_metadata_len, only some documentation bump.

Provider frags start at chunk offset 0, and an application may send them
back as they are. TX validation wants tx_metadata_len in front of every
descriptor once the UMEM has it, so such a descriptor fails, though only
XDP_TX_METADATA descriptors use that room. Driver ZC never puts RX data
below offset 256, so it never came up. It stands on its own; I'll make
it a separate patch.

> Besides, the amount of branches introduced to existing hot path is
> worrying. On next revision, could you provide numbers from xdpsock before
> and after this set run on existing zc driver?

(FWIW, I've left a all my performance patches out, to keep the size of
set down.)

Will do, but the only one I got is mlx5. Would be awesome if you or
Magnus could take it for a spin on Intel NICs.

Single-buffer RX on driver ZC gets no new per-packet branch: xsk_rcv()
leaves through xsk_rcv_zc() first. The rest is one test per flush, one
XDP_TX_METADATA test per TX descriptor, and a flag test in the
multi-buffer and XDP_PASS/redirect helpers. v2 also moves pool->pp next
to fq, which the flush reads anyway, and drops the frag walk in
xdp_buff_needs_copy(), as agreed with Stan.

Anything specific, or just in general?


Björn