[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ8uoz2g99N6HESyX1cGUWahSJRYQjXDG3m3f4_8APAvJNMHXw@mail.gmail.com>
Date: Wed, 8 Jun 2022 12:18:14 +0200
From: Magnus Karlsson <magnus.karlsson@...il.com>
To: Hangbin Liu <liuhangbin@...il.com>
Cc: Toke Høiland-Jørgensen <toke@...hat.com>,
Network Development <netdev@...r.kernel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Jesper Dangaard Brouer <hawk@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
Björn Töpel <bjorn@...nel.org>,
Magnus Karlsson <magnus.karlsson@...el.com>,
Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
Jonathan Lemon <jonathan.lemon@...il.com>,
Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
KP Singh <kpsingh@...nel.org>, bpf <bpf@...r.kernel.org>,
Kumar Kartikeya Dwivedi <memxor@...il.com>
Subject: Re: [PATCH bpf-next 0/3] move AF_XDP APIs to libxdp
On Wed, Jun 8, 2022 at 9:55 AM Hangbin Liu <liuhangbin@...il.com> wrote:
>
> On Tue, Jun 07, 2022 at 11:31:57AM +0200, Toke Høiland-Jørgensen wrote:
> > Hangbin Liu <liuhangbin@...il.com> 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@kernel.org/
> Thanks
> Hangbin
Powered by blists - more mailing lists