From: Jakub Sitnicki <jakub@cloudflare•com>
To: Jesper Dangaard Brouer <hawk@kernel•org>
Cc: bpf@vger•kernel.org, netdev@vger•kernel.org,
Jakub Kicinski <kuba@kernel•org>,
lorenzo@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
Subject: Re: [PATCH bpf-next V2 1/7] net: xdp: Add xdp_rx_meta structure
Date: Fri, 18 Jul 2025 12:33:16 +0200 [thread overview]
Message-ID: <871pqdeqkz.fsf@cloudflare.com> (raw)
In-Reply-To: <d0561121-3d36-4c55-8dbb-fc6b802a0f68@kernel.org> (Jesper Dangaard Brouer's message of "Thu, 17 Jul 2025 16:40:47 +0200")
On Thu, Jul 17, 2025 at 04:40 PM +02, Jesper Dangaard Brouer wrote:
> On 17/07/2025 11.19, Jakub Sitnicki wrote:
>> On Wed, Jul 02, 2025 at 04:58 PM +02, Jesper Dangaard Brouer wrote:
>>> 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 */
>> Idea: Perhaps this could be called *HW*_META_AREA to differentiate from
>> the existing custom metadata area:
>>
>
> I agree, that calling it META_AREA can easily be misunderstood and confused with
> metadata or data_meta.
>
> What do you think about renaming this to "hints" ?
> E.g. XDP_FLAGS_HINTS_AREA
> or XDP_FLAGS_HINTS_AVAIL
>
> And also renaming XDP_FLAGS_META_RX_* to
> e.g XDP_FLAGS_META_RX_HASH -> XDP_FLAGS_HINT_RX_HASH
> or XDP_FLAGS_HW_HINT_RX_HASH
Any name that doesn't lean on the already overloaded "metadata" term is
a better alternative, in my mind :-)
next prev parent reply other threads:[~2025-07-18 10:33 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 ` [PATCH bpf-next V2 1/7] net: xdp: Add xdp_rx_meta structure Jesper Dangaard Brouer
2025-07-17 9:19 ` Jakub Sitnicki
2025-07-17 14:40 ` Jesper Dangaard Brouer
2025-07-18 10:33 ` Jakub Sitnicki [this message]
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=871pqdeqkz.fsf@cloudflare.com \
--to=jakub@cloudflare$(echo .)com \
--cc=arthur@arthurfabre$(echo .)com \
--cc=ast@kernel$(echo .)org \
--cc=borkmann@iogearbox$(echo .)net \
--cc=bpf@vger$(echo .)kernel.org \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=hawk@kernel$(echo .)org \
--cc=kernel-team@cloudflare$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=lorenzo@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=sdf@fomichev$(echo .)me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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