Alexei Starovoitov wrote: > On Wed, May 26, 2021 at 8:57 AM Alexander Lobakin > <alexandr.lobakin@xxxxxxxxx> wrote: > > > > > >Well likely libbpf would do the rewrite I think. > > > > So your proposal is to not compose metadata according to the prog's > > request, but rather reprogram the prog itself to access metadata > > accordingly? Sounds very nice. > > > > If follow this path, is it something like this? > > > > 1. Driver exposes the fields layout (e.g. Rx/Tx descriptor fields) > > via BTF to the BPF layer. > > 2. When an XDP prog is attached, BPF reprograms it to look for the > > required fields at the right offset. > > The driver doesn't need to expose it directly via ndo. +1 > There is already generic support for BTF in modules > and support for encoding btf_id for further use inside verifier > and other components. > I think the driver can simply do: > BTF_ID_LIST(known_packet_fields) > and the bpf core will pick it from there. > While libbpf will do a CO-RE style re-write when driver layout changes. > Ideally bpf core doesn't need to be involved and it's done completely in libbpf. Agree, I don't see any reason bpf core is needed for any of the above. The only downside of BTF_ID_LIST is its not dynamic, a ucode update might move the parser and fields around. But that can be handled in userspace, by publishing a supplemental BTF file, to start with. Once we have known value and understand the use case we can discuss the dynamic case exposed from kernel side. Even the static case with BTF_ID_LIST would be a first step.
