John Fastabend <john.fastabend@xxxxxxxxx> writes: >> > However, in libxdp we can solve the original problem in a different way, >> > and in fact I already suggested to Magnus that we should do this (see >> > [1]); so one way forward could be to address it during the merge in >> > libxdp? It should be possible to address the original issue (two >> > instances of xdpsock breaking each other when they exit), but >> > applications will still need to do an explicit unload operation before >> > exiting (i.e., the automatic detach on bpf_link fd closure will take >> > more work, and likely require extending the bpf_link kernel support)... >> > >> >> I'd say it's depending on the libbpf 1.0/libxdp merge timeframe. If >> we're months ahead, then I'd really like to see this in libbpf until the >> merge. However, I'll leave that for Magnus/you to decide! > > Did I miss some thread? What does this mean libbpf 1.0/libxdp merge? The idea is to keep libbpf focused on bpf, and move the AF_XDP stuff to libxdp (so the socket stuff in xsk.h). We're adding the existing code wholesale, and keeping API compatibility during the move, so all that's needed is adding -lxdp when compiling. And obviously the existing libbpf code isn't going anywhere until such a time as there's a general backwards compatibility-breaking deprecation in libbpf (which I believe Andrii is planning to do in an upcoming and as-of-yet unannounced v1.0 release). While integrating the XSK code into libxdp we're trying to make it compatible with the rest of the library (i.e., multi-prog). Hence my preference to avoid introducing something that makes this harder :) -Toke
