On Wed, Jul 23, 2025 at 06:54 PM -07, Martin KaFai Lau wrote:
On 7/23/25 10:36 AM, Jakub Sitnicki wrote:
quoted
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.
A notable difference between the skb and the skb_meta dynptr is that writes
to the skb_meta dynptr don't invalidate either skb or skb_meta dynptr
slices, since they cannot lead to a skb->head reallocation.
There is not much visibility on how the metadata will be relocated, so trying to
think out loud. The "no invalidation after bpf_dynptr_write(&meta_dynptr, ..."
behavior will be hard to change in the future. Will this still hold in the
future when the metadata can be preserved?
Also, following up on Kuba's point about clone skb, what if the bpf prog wants
to write metadata to a clone skb in the future by using bpf_dynptr_write?
Good point. If we decide to implement a copy-on-write in the future,
then this will be a problem. Why tie our hands if it's not a huge
nuissance for the user? Let me restrict it.