On 7/23/25 10:36 AM, Jakub Sitnicki wrote:
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?
