On Thu, Jun 24, 2021 at 6:08 AM Magnus Karlsson <magnus.karlsson@xxxxxxxxx> wrote: > > > > and libbpf could do relocations based on the different meta structs, > > even removing the code for the ones that don't exist on the running > > kernel. > > Just wondering how this will carry over to user-space and AF_XDP since > it sees the same metadata area as XDP? AFAIK, dynamic linkers today > cannot relocate structs or remove members, but I am not up-to-date > with the latest here so might be completely wrong. And it would be > good not to have to recompile a user-space binary just because a new > NIC came out with a new BTF ID and layout, but with the same metadata > member name and format as previous NICs/BTF IDs. But I do not know how > to solve these things in user-space at the moment (except to have > fixed locations for a common set of metadata, but that is what we are > trying to avoid), so any hints and suggestions are highly appreciated. CO-RE is not a kernel only feature. The BTF tests in selftest/bpf exercise most of CO-RE purely in user space. The libbpf needs to know the original BTF and the target BTF to match one to another. One option for AF_XDP would be to write a bpf program to be run in user space and let libbpf handle relocations. Another option is to teach llvm x86 backend to support __attribute__((preserve_access_index)). The work done by llvm BPF backend can be copy pasted to x86 backend. Then standard x86 binaries will support dynamic struct layout. imo CO-RE for x86 backend would be great to do regardless of xdp hints. It's a straightforward copy-paste. Only need to convince x86 llvm maintainers.
