diff options
| author | Jakub Sitnicki <jakub@cloudflare.com> | 2025-08-14 11:59:27 +0200 |
|---|---|---|
| committer | Martin KaFai Lau <martin.lau@kernel.org> | 2025-08-18 10:29:42 -0700 |
| commit | 89d912e494f786e79f69ed9d567a8842c71dbb03 (patch) | |
| tree | 28268338451d686c8842efc36e7596ae4d63b4dc /scripts/kernel-doc.py | |
| parent | 8f5ae30d69d7543eee0d70083daf4de8fe15d585 (diff) | |
bpf: Add dynptr type for skb metadata
Add a dynptr type, similar to skb dynptr, but for the skb metadata access.
The dynptr provides an alternative to __sk_buff->data_meta for accessing
the custom metadata area allocated using the bpf_xdp_adjust_meta() helper.
More importantly, it abstracts away the fact where the storage for the
custom metadata lives, which opens up the way to persist the metadata by
relocating it as the skb travels through the network stack layers.
Writes to skb metadata invalidate any existing skb payload and metadata
slices. While this is more restrictive that needed at the moment, it leaves
the door open to reallocating the metadata on writes, and should be only a
minor inconvenience to the users.
Only the program types which can access __sk_buff->data_meta today are
allowed to create a dynptr for skb metadata at the moment. We need to
modify the network stack to persist the metadata across layers before
opening up access to other BPF hooks.
Once more BPF hooks gain access to skb_meta dynptr, we will also need to
add a read-only variant of the helper similar to
bpf_dynptr_from_skb_rdonly.
skb_meta dynptr ops are stubbed out and implemented by subsequent changes.
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Reviewed-by: Jesse Brandeburg <jbrandeburg@cloudflare.com>
Link: https://patch.msgid.link/20250814-skb-metadata-thru-dynptr-v7-1-8a39e636e0fb@cloudflare.com
Diffstat (limited to 'scripts/kernel-doc.py')
0 files changed, 0 insertions, 0 deletions
