On Mon, 14 Nov 2022 19:02:05 -0800 Stanislav Fomichev wrote: > Implement new bpf_xdp_metadata_export_to_skb kfunc which > prepares compatible xdp metadata for kernel consumption. > This kfunc should be called prior to bpf_redirect > or when XDP_PASS'ing the frame into the kernel (note, the drivers > have to be updated to enable consuming XDP_PASS'ed metadata). > > veth driver is amended to consume this metadata when converting to skb. > > Internally, XDP_FLAGS_HAS_SKB_METADATA flag is used to indicate > whether the frame has skb metadata. The metadata is currently > stored prior to xdp->data_meta. bpf_xdp_adjust_meta refuses > to work after a call to bpf_xdp_metadata_export_to_skb (can lift > this requirement later on if needed, we'd have to memmove > xdp_skb_metadata). IMO we should split the xdp -> skb work from the pure HW data access in XDP. We have a proof point here that there is a way of building on top of the first 5 patches to achieve the objective, and that's sufficient to let the prior work going in. ..because some of us may not agree that we should be pushing in a fixed-format structure that's also listed in uAPI. And prefer to, say, let the user define their format and add a call point for a BPF prog to populate the skb from whatever data they decided to stash... That's how I interpreted some of John's comments as well, but I may be wrong. Either way, there is no technical reason for the xdp -> skb field propagation to hold up the HW descriptor access, right? If anything we may be able to make quicker progress if prior work is in tree and multiple people can hack...
