On 6/9/22 10:29 PM, Andrii Nakryiko wrote:
On Wed, Jun 8, 2022 at 3:18 AM Magnus Karlsson
<magnus.karlsson@xxxxxxxxx> wrote:
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?
I think adding libxdp dependency for samples/bpf is a bad idea. Moving
samples to near libxdp makes more sense to me.
+1 on moving them out from samples/bpf/ to somewhere near libxdp repo given
it'll be usage example of libxdp.
More generally, the useful XDP-related things could migrate from samples/bpf/
over to either https://github.com/xdp-project/bpf-examples/ or
https://github.com/xdp-project/xdp-tools and then we could potentially toss
the samples/bpf/ dir from the kernel tree.
These days there are tons of howtos and example progs out in the wild and
better tooling/framework available for users to get started. Taking XDP
aside for a bit, a lot of stuff in samples/bpf/ is just outdated.
Brendan recently also started drafting guidelines (wip) for newbies getting
into development with pointers where to look [0]. So really, there's less and
less good reason for samples/bpf/ these days.
[0] http://vger.kernel.org/bpfconf2022_material/lsfmmbpf2022-bpf-wip-guidelines.pdf
[1] https://lore.kernel.org/bpf/20220603190155.3924899-2-andrii@xxxxxxxxxx/
Thanks
Hangbin
