net/af_xdp: workaround custom program loading
authorCiara Loftus <ciara.loftus@intel.com>
Fri, 12 Nov 2021 10:30:02 +0000 (10:30 +0000)
committerFerruh Yigit <ferruh.yigit@intel.com>
Mon, 15 Nov 2021 17:01:09 +0000 (18:01 +0100)
commit01fa83c94d7e147640e146094a06513cb2b107ce
tree2713da257af5bacfc42fae5ee631c2acbb28def2
parent9f394004c35d71025408fdba439d72fea49470d0
net/af_xdp: workaround custom program loading

Since v0.4.0, if the underlying kernel supports it, libbpf uses 'bpf
link' to manage the programs on the interfaces of the XDP sockets (xsks).
This is not compatible with the PMD's custom XDP program loading feature
which uses the netlink-based method for loading custom programs.

The conflict arises when libbpf searches for a custom program on the
interface using bpf link, but doesn't find one because the netlink
method was used. libbpf then proceeds to try to load the default program
on the interface, but fails due to the presence of the custom program.

To work around this, the PMD now uses the
XSK_LIBBPF_FLAGS__INHIBIT_PROG_LOAD flag which prevents libbpf from
attempting to search for or load a program. One repercussion is that
DPDK must now insert the xsk into the xsks_map as this was previously
handled by libbpf during the routines for program loading/probing.

Ideally, the PMD would use bpf link to load the custom program, however
at present there is no convenient and reliable way of detecting whether
the underlying kernel supports bpf link. Perhaps this may become
available in a future libbpf release, at which point we can switch the
PMD over to the new bpf link based method.

Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
drivers/net/af_xdp/rte_eth_af_xdp.c