On Wed, Jun 8, 2022 at 9:55 AM Hangbin Liu <liuhangbin@xxxxxxxxx> wrote: > > On Tue, Jun 07, 2022 at 11:31:57AM +0200, Toke Høiland-Jørgensen wrote: > > Hangbin Liu <liuhangbin@xxxxxxxxx> writes: > > > > > libbpf APIs for AF_XDP are deprecated starting from v0.7. > > > Let's move to libxdp. > > > > > > The first patch removed the usage of bpf_prog_load_xattr(). As we > > > will remove the GCC diagnostic declaration in later patches. > > > > Kartikeya started working on moving some of the XDP-related samples into > > the xdp-tools repo[0]; maybe it's better to just include these AF_XDP > > programs into that instead of adding a build-dep on libxdp to the kernel > > samples? > > OK, makes sense to me. Should we remove these samples after the xdp-tools PR > merged? What about xdpxceiver.c in selftests/bpf? Should that also be moved to > xdp-tools? Andrii has submitted a patch [1] for moving xsk.[ch] from libbpf to the xsk selftests so it can be used by xdpxceiver. This is a good idea since xdpxceiver tests the low level kernel interfaces and should not be in libxdp. I can also use those files as a start for implementing control interface tests which are in the planning stages. But the xdpsock sample shows how to use libxdp to write an AF_XDP program and belongs more naturally with libxdp. So good that Kartikeya is moving it over. Thanks! Another option would be to keep the xdpsock sample and require libxdp as in your patch set, but you would have to make sure that everything else in samples/bpf compiles neatly even if you do not have libxdp. Test for the presence of libxdp in the Makefile and degrade gracefully if you do not. But we would then have to freeze the xdpsock app as all new development of samples should be in libxdp. Or we just turn xdpsock into a README file and direct people to the samples in libxdp? What do you think? [1] https://lore.kernel.org/bpf/20220603190155.3924899-2-andrii@xxxxxxxxxx/ > Thanks > Hangbin
