Re: [PATCH bpf-next 0/3] move AF_XDP APIs to libxdp

On Wed, Jun 8, 2022 at 9:55 AM Hangbin Liu [off-list ref] wrote:

On Tue, Jun 07, 2022 at 11:31:57AM +0200, Toke Høiland-Jørgensen wrote:

quoted

Hangbin Liu [off-list ref] writes:

quoted

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@kernel.org/ (local)

Thanks
Hangbin