Support needed for newer libbpf versions.

[leearoberts]

In internal/bpf/bpfWrapper.c, there is a call to bpf_set_link_xdp_fd() at line 153. This function has been replaced in newer versions of libbpf.

A change to DPDK code (net/af_xdp) for this same issue can be seen at:
https://patchwork.dpdk.org/project/dpdk/patch/[email protected]/

RHEL 9.2 includes libbpf v1.0.0, causing this code to break when moving to a newer OS.

[garyloug]

Thanks @leearoberts - just acknowledging your issue. We're looking into it.

[garyloug]

Update on this:

• Our main problem is libbpf api changes a bit over time, this time impacting us. CNI uses libbpf on the host and we can’t guarantee what’s installed there. (device plugin runs in a daemonset, so is packaged up with its dependencies).
• The distros are also all over the place in terms of what version of libbpf the package managers install, compounding the problem above.
• Spent a while looking at different ways around this, but ultimately decided we need to break this dependency on host libraries.
• Looked at using ip link set dev eth0 xdp off and the corresponding vishvananda/netlink function as a more generic way of removing bpf from the netdev. Unfortunately found that ip link only removes bpf programs that it loaded itself. It cannot unload an app loaded by libbpf.
• Ultimately, we were able to statically compile the cni to include libbpf, so this is the solution we’re currently going with to break the host dependencies. Static compiling with our current (really old) version of libbpf works fine. Tested on a host with no libbpf installed. Binary size increase is not too bad.
• Next step was to move to a more recent version of libbpf, and again we hit more problems.
• xsk_setup_xdp_prog and bpf_set_link_xdp_fd, the functions we use to add and remove the bpf app, have been deprecated in favour of bpf_prog_attach and bpf_prog_detach.
• “detach” works fine, however the new “attach” function is different from xsk_setup_xdp_prog. It doesn’t give us the xsks_map_fd that we ultimately pass over the UDS to the containerised workload, allowing it to create an AF_XDP socket.
• xsk_setup_xdp_prog comes from <bpf/xsk.h> and from libbpf v1.0.0 onward, this file was moved to libxdp to become <xdp/xsk.h>
• In summary, if we move to a newer version of libbpf, we have a new dependency on libxdp.
• Briefly attempted installing and importing both, but I don’t like this idea and they appeared to conflict anyway. Didn’t spend long on it.
• We want to move to libxdp in the long term anyway, and actually attempted this previously. We never merged it because we found libxdp difficult to install on anything but the latest OSs at the time. We didn’t want to pass this burden onto users.
• However, static compilation fixes this problem, user no longer needs to install libs on the host. @phansGithub has tested libxdp with static compilation and it appears to be working ok.
• So, this is the direction I’m going to suggest. Drop libbpf in favour of libxdp.

Thanks @maryamtahhan for advice and suggestions. Thanks @phansGithub for trialing and testing all the above. FYI @davecremins.