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@xxxxxxxxxx/
[2] 36e68442d1af ("bpf: Load and verify kernel module BTFs") (Author:
Andrii Nakryiko)
[3]
https://github.com/xdp-project/bpf-examples/blob/master/BTF-playground/
