From: Jesper Dangaard Brouer <hawk@kernel.org>
To: bpf@vger.kernel.org, netdev@vger.kernel.org,
Jakub Kicinski <kuba@kernel.org>,
lorenzo@kernel.org
Cc: Jesper Dangaard Brouer <hawk@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <borkmann@iogearbox.net>,
Eric Dumazet <eric.dumazet@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>,
sdf@fomichev.me, kernel-team@cloudflare.com,
arthur@arthurfabre.com, jakub@cloudflare.com
Subject: [PATCH bpf-next V2 1/7] net: xdp: Add xdp_rx_meta structure
Date: Wed, 02 Jul 2025 16:58:19 +0200 [thread overview]
Message-ID: <175146829944.1421237.13943404585579626611.stgit@firesoul> (raw)
In-Reply-To: <175146824674.1421237.18351246421763677468.stgit@firesoul>
From: Lorenzo Bianconi <lorenzo@kernel.org>
Introduce the `xdp_rx_meta` structure to serve as a container for XDP RX
hardware hints within XDP packet buffers. Initially, this structure will
accommodate `rx_hash` and `rx_vlan` metadata. (The `rx_timestamp` hint will
get stored in `skb_shared_info`).
A key design aspect is making this metadata accessible both during BPF
program execution (via `struct xdp_buff`) and later if an `struct
xdp_frame` is materialized (e.g., for XDP_REDIRECT).
To achieve this:
- The `struct xdp_frame` embeds an `xdp_rx_meta` field directly for
storage.
- The `struct xdp_buff` includes an `xdp_rx_meta` pointer. This pointer
is initialized (in `xdp_prepare_buff`) to point to the memory location
within the packet buffer's headroom where the `xdp_frame`'s embedded
`rx_meta` field would reside.
This setup allows BPF kfuncs, operating on `xdp_buff`, to populate the
metadata in the precise location where it will be found if an `xdp_frame`
is subsequently created.
The availability of this metadata storage area within the buffer is
indicated by the `XDP_FLAGS_META_AREA` flag in `xdp_buff->flags` (and
propagated to `xdp_frame->flags`). This flag is only set if sufficient
headroom (at least `XDP_MIN_HEADROOM`, currently 192 bytes) is present.
Specific hints like `XDP_FLAGS_META_RX_HASH` and `XDP_FLAGS_META_RX_VLAN`
will then denote which types of metadata have been populated into the
`xdp_rx_meta` structure.
This patch is a step for enabling the preservation and use of XDP RX
hints across operations like XDP_REDIRECT.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jesper Dangaard Brouer <hawk@kernel.org>
---
include/net/xdp.h | 57 +++++++++++++++++++++++++++++++++++------------
net/core/xdp.c | 1 +
net/xdp/xsk_buff_pool.c | 4 ++-
3 files changed, 47 insertions(+), 15 deletions(-)
diff --git a/include/net/xdp.h b/include/net/xdp.h
index b40f1f96cb11..f52742a25212 100644
--- a/include/net/xdp.h
+++ b/include/net/xdp.h
@@ -71,11 +71,31 @@ struct xdp_txq_info {
struct net_device *dev;
};
+struct xdp_rx_meta {
+ struct xdp_rx_meta_hash {
+ u32 val;
+ u32 type; /* enum xdp_rss_hash_type */
+ } hash;
+ struct xdp_rx_meta_vlan {
+ __be16 proto;
+ u16 tci;
+ } vlan;
+};
+
+/* Storage area for HW RX metadata only available with reasonable headroom
+ * available. Less than XDP_PACKET_HEADROOM due to Intel drivers.
+ */
+#define XDP_MIN_HEADROOM 192
+
enum xdp_buff_flags {
XDP_FLAGS_HAS_FRAGS = BIT(0), /* non-linear xdp buff */
XDP_FLAGS_FRAGS_PF_MEMALLOC = BIT(1), /* xdp paged memory is under
* pressure
*/
+ XDP_FLAGS_META_AREA = BIT(2), /* storage area available */
+ XDP_FLAGS_META_RX_HASH = BIT(3), /* hw rx hash */
+ XDP_FLAGS_META_RX_VLAN = BIT(4), /* hw rx vlan */
+ XDP_FLAGS_META_RX_TS = BIT(5), /* hw rx timestamp */
};
struct xdp_buff {
@@ -87,6 +107,24 @@ struct xdp_buff {
struct xdp_txq_info *txq;
u32 frame_sz; /* frame size to deduce data_hard_end/reserved tailroom*/
u32 flags; /* supported values defined in xdp_buff_flags */
+ struct xdp_rx_meta *rx_meta; /* rx hw metadata pointer in the
+ * buffer headroom
+ */
+};
+
+struct xdp_frame {
+ void *data;
+ u32 len;
+ u32 headroom;
+ u32 metasize; /* uses lower 8-bits */
+ /* Lifetime of xdp_rxq_info is limited to NAPI/enqueue time,
+ * while mem_type is valid on remote CPU.
+ */
+ enum xdp_mem_type mem_type:32;
+ struct net_device *dev_rx; /* used by cpumap */
+ u32 frame_sz;
+ u32 flags; /* supported values defined in xdp_buff_flags */
+ struct xdp_rx_meta rx_meta; /* rx hw metadata */
};
static __always_inline bool xdp_buff_has_frags(const struct xdp_buff *xdp)
@@ -133,6 +171,9 @@ xdp_prepare_buff(struct xdp_buff *xdp, unsigned char *hard_start,
xdp->data = data;
xdp->data_end = data + data_len;
xdp->data_meta = meta_valid ? data : data + 1;
+ xdp->flags = (headroom < XDP_MIN_HEADROOM) ? 0 : XDP_FLAGS_META_AREA;
+ xdp->rx_meta = (void *)(hard_start +
+ offsetof(struct xdp_frame, rx_meta));
}
/* Reserve memory area at end-of data area.
@@ -253,20 +294,6 @@ static inline bool xdp_buff_add_frag(struct xdp_buff *xdp, netmem_ref netmem,
return true;
}
-struct xdp_frame {
- void *data;
- u32 len;
- u32 headroom;
- u32 metasize; /* uses lower 8-bits */
- /* Lifetime of xdp_rxq_info is limited to NAPI/enqueue time,
- * while mem_type is valid on remote CPU.
- */
- enum xdp_mem_type mem_type:32;
- struct net_device *dev_rx; /* used by cpumap */
- u32 frame_sz;
- u32 flags; /* supported values defined in xdp_buff_flags */
-};
-
static __always_inline bool xdp_frame_has_frags(const struct xdp_frame *frame)
{
return !!(frame->flags & XDP_FLAGS_HAS_FRAGS);
@@ -355,6 +382,8 @@ void xdp_convert_frame_to_buff(const struct xdp_frame *frame,
xdp->data_meta = frame->data - frame->metasize;
xdp->frame_sz = frame->frame_sz;
xdp->flags = frame->flags;
+ xdp->rx_meta = xdp->data_hard_start +
+ offsetof(struct xdp_frame, rx_meta);
}
static inline
diff --git a/net/core/xdp.c b/net/core/xdp.c
index 491334b9b8be..bd3110fc7ef8 100644
--- a/net/core/xdp.c
+++ b/net/core/xdp.c
@@ -606,6 +606,7 @@ struct xdp_frame *xdp_convert_zc_to_xdp_frame(struct xdp_buff *xdp)
xdpf->metasize = metasize;
xdpf->frame_sz = PAGE_SIZE;
xdpf->mem_type = MEM_TYPE_PAGE_ORDER0;
+ memcpy(&xdpf->rx_meta, xdp->rx_meta, sizeof(*xdp->rx_meta));
xsk_buff_free(xdp);
return xdpf;
diff --git a/net/xdp/xsk_buff_pool.c b/net/xdp/xsk_buff_pool.c
index aa9788f20d0d..de42dacdcb25 100644
--- a/net/xdp/xsk_buff_pool.c
+++ b/net/xdp/xsk_buff_pool.c
@@ -574,7 +574,9 @@ struct xdp_buff *xp_alloc(struct xsk_buff_pool *pool)
xskb->xdp.data = xskb->xdp.data_hard_start + XDP_PACKET_HEADROOM;
xskb->xdp.data_meta = xskb->xdp.data;
- xskb->xdp.flags = 0;
+ xskb->xdp.flags = XDP_FLAGS_META_AREA;
+ xskb->xdp.rx_meta = (void *)(xskb->xdp.data_hard_start +
+ offsetof(struct xdp_frame, rx_meta));
if (pool->dev)
xp_dma_sync_for_device(pool, xskb->dma, pool->frame_len);
next prev parent reply other threads:[~2025-07-02 14:58 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-02 14:58 [PATCH bpf-next V2 0/7] xdp: Allow BPF to set RX hints for XDP_REDIRECTed packets Jesper Dangaard Brouer
2025-07-02 14:58 ` Jesper Dangaard Brouer [this message]
2025-07-17 9:19 ` [PATCH bpf-next V2 1/7] net: xdp: Add xdp_rx_meta structure Jakub Sitnicki
2025-07-17 14:40 ` Jesper Dangaard Brouer
2025-07-18 10:33 ` Jakub Sitnicki
2025-07-02 14:58 ` [PATCH bpf-next V2 2/7] selftests/bpf: Adjust test for maximum packet size in xdp_do_redirect Jesper Dangaard Brouer
2025-07-02 14:58 ` [PATCH bpf-next V2 3/7] net: xdp: Add kfuncs to store hw metadata in xdp_buff Jesper Dangaard Brouer
2025-07-03 11:41 ` Jesper Dangaard Brouer
2025-07-03 12:26 ` Lorenzo Bianconi
2025-07-02 14:58 ` [PATCH bpf-next V2 4/7] net: xdp: Set skb hw metadata from xdp_frame Jesper Dangaard Brouer
2025-07-02 14:58 ` [PATCH bpf-next V2 5/7] net: veth: Read xdp metadata from rx_meta struct if available Jesper Dangaard Brouer
2025-07-17 12:11 ` Jakub Sitnicki
2025-07-02 14:58 ` [PATCH bpf-next V2 6/7] bpf: selftests: Add rx_meta store kfuncs selftest Jesper Dangaard Brouer
2025-07-23 9:24 ` Bouska, Zdenek
2025-07-02 14:58 ` [PATCH bpf-next V2 7/7] net: xdp: update documentation for xdp-rx-metadata.rst Jesper Dangaard Brouer
2025-07-02 16:05 ` [PATCH bpf-next V2 0/7] xdp: Allow BPF to set RX hints for XDP_REDIRECTed packets Stanislav Fomichev
2025-07-03 11:17 ` Jesper Dangaard Brouer
2025-07-07 14:40 ` Stanislav Fomichev
2025-07-09 9:31 ` Lorenzo Bianconi
2025-07-11 16:04 ` Stanislav Fomichev
2025-07-16 11:17 ` Lorenzo Bianconi
2025-07-16 21:20 ` Jakub Kicinski
2025-07-17 13:08 ` Jesper Dangaard Brouer
2025-07-18 1:25 ` Jakub Kicinski
2025-07-18 10:56 ` Jesper Dangaard Brouer
2025-07-22 1:13 ` Jakub Kicinski
2025-07-28 10:53 ` Lorenzo Bianconi
2025-07-28 16:29 ` Jakub Kicinski
2025-07-29 11:15 ` Jesper Dangaard Brouer
2025-07-29 19:47 ` Martin KaFai Lau
2025-07-31 16:27 ` Jesper Dangaard Brouer
2025-08-01 20:38 ` Jakub Kicinski
2025-08-04 13:18 ` Jesper Dangaard Brouer
2025-08-06 0:28 ` Jakub Kicinski
2025-08-07 18:26 ` Jesper Dangaard Brouer
2025-08-06 1:24 ` Martin KaFai Lau
2025-08-07 19:07 ` Jesper Dangaard Brouer
2025-08-13 2:59 ` Martin KaFai Lau
2025-07-31 21:18 ` Lorenzo Bianconi
2025-08-01 20:40 ` Jakub Kicinski
2025-08-05 13:18 ` Lorenzo Bianconi
2025-08-05 23:54 ` Jakub Kicinski
2025-07-18 9:55 ` Lorenzo Bianconi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=175146829944.1421237.13943404585579626611.stgit@firesoul \
--to=hawk@kernel.org \
--cc=arthur@arthurfabre.com \
--cc=ast@kernel.org \
--cc=borkmann@iogearbox.net \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jakub@cloudflare.com \
--cc=kernel-team@cloudflare.com \
--cc=kuba@kernel.org \
--cc=lorenzo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox