On Wed, Jul 23, 2025 at 06:54 PM -07, Martin KaFai Lau wrote: > 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? 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.
