On Thu, Nov 30, 2023 at 2:35 PM Jesper Dangaard Brouer <hawk@xxxxxxxxxx> wrote: > > We are exploring more options than only XDP metadata area to store > information. I have suggested that once an SKB have a socket > associated, then we can switch into using BPF local socket storage > tricks. (The lifetime of XDP metadata is not 100% clear as e.g. > pskb_expand_head clears it via skb_metadata_clear). > All ideas are welcome, e.g. I'm also looking at ability to store > auxiliary/metadata data associated with a dst_entry. And SKB->mark is > already used for other use-cases and isn't big enough. (and then there > is fun crossing a netns boundry). > sk local storage might not work for the cases if packets are purely forwarded or end up with a tun/tap device. Can we make XDP metadata life time clear then? It would also be really interesting if we can sendmsg with metadata, too. We often have a hard time distinguishing if a kernel event like packet drop/retransmission correlates to a reported customer problem. It's hard because when the event happens, there isn't customer specific information in the context to correlate, usually only multiplexed sockets and the packet triggering such an event. Allowing carrying some extra information on the packet would definitely improve this a lot with BPF tracing. Yan
