Maciej Fijalkowski <maciej.fijalkowski@xxxxxxxxx> writes: > Currently, if there are multiple xdpsock instances running on a single > interface and in case one of the instances is terminated, the rest of > them are left in an inoperable state due to the fact of unloaded XDP > prog from interface. > > Consider the scenario below: > > // load xdp prog and xskmap and add entry to xskmap at idx 10 > $ sudo ./xdpsock -i ens801f0 -t -q 10 > > // add entry to xskmap at idx 11 > $ sudo ./xdpsock -i ens801f0 -t -q 11 > > terminate one of the processes and another one is unable to work due to > the fact that the XDP prog was unloaded from interface. > > To address that, step away from setting bpf prog in favour of bpf_link. > This means that refcounting of BPF resources will be done automatically > by bpf_link itself. > > Provide backward compatibility by checking if underlying system is > bpf_link capable. Do this by looking up/creating bpf_link on loopback > device. If it failed in any way, stick with netlink-based XDP prog. > therwise, use bpf_link-based logic. > > When setting up BPF resources during xsk socket creation, check whether > bpf_link for a given ifindex already exists via set of calls to > bpf_link_get_next_id -> bpf_link_get_fd_by_id -> bpf_obj_get_info_by_fd > and comparing the ifindexes from bpf_link and xsk socket. > > For case where resources exist but they are not AF_XDP related, bail out > and ask user to remove existing prog and then retry. > > Lastly, do a bit of refactoring within __xsk_setup_xdp_prog and pull out > existing code branches based on prog_id value onto separate functions > that are responsible for resource initialization if prog_id was 0 and > for lookup existing resources for non-zero prog_id as that implies that > XDP program is present on the underlying net device. This in turn makes > it easier to follow, especially the teardown part of both branches. > > Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@xxxxxxxxx> Acked-by: Toke Høiland-Jørgensen <toke@xxxxxxxxxx>
