Toke Høiland-Jørgensen wrote: > Snipping a bit of context to reply to this bit: > > >>>> Can the xdp prog still change the metadata through xdp->data_meta? tbh, I am not > >>>> sure it is solid enough by asking the xdp prog not to use the same random number > >>>> in its own metadata + not to change the metadata through xdp->data_meta after > >>>> calling bpf_xdp_metadata_export_to_skb(). > >>> > >>> What do you think the usecase here might be? Or are you suggesting we > >>> reject further access to data_meta after > >>> bpf_xdp_metadata_export_to_skb somehow? > >>> > >>> If we want to let the programs override some of this > >>> bpf_xdp_metadata_export_to_skb() metadata, it feels like we can add > >>> more kfuncs instead of exposing the layout? > >>> > >>> bpf_xdp_metadata_export_to_skb(ctx); > >>> bpf_xdp_metadata_export_skb_hash(ctx, 1234); > Hi Toke, Trying not to bifurcate your thread. Can I start a new one here to elaborate on these use cases. I'm still a bit lost on any use case for this that makes sense to actually deploy on a network. > There are several use cases for needing to access the metadata after > calling bpf_xdp_metdata_export_to_skb(): > > - Accessing the metadata after redirect (in a cpumap or devmap program, > or on a veth device) I think for devmap there are still lots of opens how/where the skb is even built. For cpumap I'm a bit unsure what the use case is. For ice, mlx and such you should use the hardware RSS if performance is top of mind. And then for specific devices on cpumap (maybe realtime or ptp things?) could we just throw it through the xdp_frame? > - Transferring the packet+metadata to AF_XDP In this case we have the metadata and AF_XDP program and XDP program simply need to agree on metadata format. No need to have some magic numbers and driver specific kfuncs. > - Returning XDP_PASS, but accessing some of the metadata first (whether > to read or change it) > I don't get this case? XDP_PASS should go to stack normally through drivers build_skb routines. These will populate timestamp normally. My guess is simply descriptor->skb load/store is cheaper than carrying around this metadata and doing the call in BPF side. Anyways you just built an entire skb and hit the stack I don't think you will notice this noise in any benchmark.
