John Fastabend <john.fastabend@xxxxxxxxx> writes: > 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 veth it's pretty clear; i.e., when redirecting into containers. > 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. Hardware RSS works fine if your hardware supports the hashing you want; many do not. As an example, Jesper wrote this application that uses cpumap to divide out ISP customer traffic among different CPUs (solving an HTB scaling problem): https://github.com/xdp-project/xdp-cpumap-tc > And then for specific devices on cpumap (maybe realtime or ptp > things?) could we just throw it through the xdp_frame? Not sure what you mean here? Throw what 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. See my other reply to Martin: Yeah, for AF_XDP users that write their own kernel XDP programs, they can just do whatever they want. But many users just rely on the default program in libxdp, so having a standard format to include with that is useful. >> - 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. If you modify the packet before calling XDP_PASS you may want to update the metadata as well (for instance the RX hash, or in the future the metadata could also carry transport header offsets). -Toke
