Re: Does skb_metadata_differs really need to stop GRO aggregation?

[Yan Zhai <yan@cloudflare.com>]

On Thu, Nov 30, 2023 at 2:35 PM Jesper Dangaard Brouer <hawk@kernel.org> 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