XDP-hints as BTF early design discussion phase

[Jesper Dangaard Brouer <jbrouer@redhat.com>]

Trying to get started with XDP-hints again.

The fundamental idea is that XDP-hints metadata struct's are defined by 
the kernel, preferably by the kernel module, and described via BTF. As 
BTF layout is defined by kernel, this means userspace (AF_XDP) and 
BPF-progs must adapt to layout (used by running kernel). This imply that 
kernel is free to change layout.

The BTF ID is exposed (to BPF-prog and AF_XDP) on per packet basis, to 
give kernel more freedom to change layout runtime. This push 
responsibility to userspace/BPF-prog of handling different layouts, 
which seems natural. For the kernel this solves many issues around 
concurrency and NIC config changes that affects BTF info available (e.g. 
when BTF layout is allowed to change).

End-goal is to make it easier for kernel drivers can invent new layouts 
to suite new hardware features. Thus, we prefer a solution where 
XDP-hints metadata struct's are defined in the kernel module code.


(Idea below ... please let us know what you think, wrong direction?)

Exploring kernel module code defining the XDP-hints metadata struct.

Kernel module BTFs are now[1][2] exposed through sysfs as 
/sys/kernel/btf/<module-name>. Thus, userspace can use libbpf 
btf__load_module_btf() and others BTF APIs. Started playing here[3].

Credit to Toke, who had an idea that drivers could "say" what struct's 
are available, by defining a union with a known name e.g. 
metadata_hints_avail' and have supported metadata struct's included in 
that union. Then we don't need new APIs for exporting these BTF-metadata 
struct's. To find struct names, we BTF walk this union.


-Jesper

  [1] 
https://lore.kernel.org/bpf/20201110011932.3201430-5-andrii@kernel.org/
  [2] 36e68442d1af ("bpf: Load and verify kernel module BTFs") (Author: 
Andrii Nakryiko)
  [3] 
https://github.com/xdp-project/bpf-examples/blob/master/BTF-playground/