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

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

[Hangbin Liu]

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.

Hangbin Liu (3):
  samples/bpf/xdpsock_user.c: Get rid of bpf_prog_load_xattr()
  samples/bpf: move AF_XDP APIs to libxdp
  selftests/bpf: move AF_XDP APIs to libxdp

 samples/bpf/xdpsock_ctrl_proc.c          |  5 +----
 samples/bpf/xdpsock_user.c               | 22 ++++++++++++----------
 samples/bpf/xsk_fwd.c                    |  5 +----
 tools/testing/selftests/bpf/xdpxceiver.c |  8 +-------
 4 files changed, 15 insertions(+), 25 deletions(-)

-- 
2.35.1

[PATCH bpf-next 1/3] samples/bpf/xdpsock_user.c: Get rid of bpf_prog_load_xattr()

[Hangbin Liu]

Commit 1e4edb6d8c4f ("samples/bpf: Get rid of bpf_prog_load_xattr()
use") tried to remove all the deprecated bpf_prog_load_xattr() API..
But xdpsock_user.c was left as it set GCC diagnostic ignored
"-Wdeprecated-declarations".

Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
 samples/bpf/xdpsock_user.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/samples/bpf/xdpsock_user.c b/samples/bpf/xdpsock_user.c
index be7d2572e3e6..3ea46c300df2 100644
--- a/samples/bpf/xdpsock_user.c
+++ b/samples/bpf/xdpsock_user.c
@@ -1742,17 +1742,22 @@ static void l2fwd_all(void)
 
 static void load_xdp_program(char **argv, struct bpf_object **obj)
 {
-	struct bpf_prog_load_attr prog_load_attr = {
-		.prog_type      = BPF_PROG_TYPE_XDP,
-	};
+	struct bpf_program *prog;
 	char xdp_filename[256];
 	int prog_fd;
 
 	snprintf(xdp_filename, sizeof(xdp_filename), "%s_kern.o", argv[0]);
-	prog_load_attr.file = xdp_filename;
+	*obj = bpf_object__open_file(xdp_filename, NULL);
+	if (libbpf_get_error(*obj))
+		exit(EXIT_FAILURE);
 
-	if (bpf_prog_load_xattr(&prog_load_attr, obj, &prog_fd))
+	prog = bpf_object__next_program(*obj, NULL);
+	bpf_program__set_type(prog, BPF_PROG_TYPE_XDP);
+
+	if (bpf_object__load(*obj))
 		exit(EXIT_FAILURE);
+
+	prog_fd = bpf_program__fd(prog);
 	if (prog_fd < 0) {
 		fprintf(stderr, "ERROR: no program found: %s\n",
 			strerror(prog_fd));
@@ -1885,10 +1890,10 @@ int main(int argc, char **argv)
 {
 	struct __user_cap_header_struct hdr = { _LINUX_CAPABILITY_VERSION_3, 0 };
 	struct __user_cap_data_struct data[2] = { { 0 } };
+	struct bpf_object *obj = NULL;
 	bool rx = false, tx = false;
 	struct sched_param schparam;
 	struct xsk_umem_info *umem;
-	struct bpf_object *obj;
 	int xsks_map_fd = 0;
 	pthread_t pt;
 	int i, ret;
-- 
2.35.1

[PATCH bpf-next 2/3] samples/bpf: move AF_XDP APIs to libxdp

[Hangbin Liu]

libbpf APIs for AF_XDP are deprecated starting from v0.7.
Let's move to libxdp.

Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
 samples/bpf/xdpsock_ctrl_proc.c | 5 +----
 samples/bpf/xdpsock_user.c      | 5 +----
 samples/bpf/xsk_fwd.c           | 5 +----
 3 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/samples/bpf/xdpsock_ctrl_proc.c b/samples/bpf/xdpsock_ctrl_proc.c
index 28b5f2a9fa08..964fb3f9c12b 100644
--- a/samples/bpf/xdpsock_ctrl_proc.c
+++ b/samples/bpf/xdpsock_ctrl_proc.c
@@ -12,12 +12,9 @@
 #include <unistd.h>
 
 #include <bpf/bpf.h>
-#include <bpf/xsk.h>
+#include <xdp/xsk.h>
 #include "xdpsock.h"
 
-/* libbpf APIs for AF_XDP are deprecated starting from v0.7 */
-#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
-
 static const char *opt_if = "";
 
 static struct option long_options[] = {
diff --git a/samples/bpf/xdpsock_user.c b/samples/bpf/xdpsock_user.c
index 3ea46c300df2..9231bfadf419 100644
--- a/samples/bpf/xdpsock_user.c
+++ b/samples/bpf/xdpsock_user.c
@@ -33,13 +33,10 @@
 #include <sched.h>
 
 #include <bpf/libbpf.h>
-#include <bpf/xsk.h>
+#include <xdp/xsk.h>
 #include <bpf/bpf.h>
 #include "xdpsock.h"
 
-/* libbpf APIs for AF_XDP are deprecated starting from v0.7 */
-#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
-
 #ifndef SOL_XDP
 #define SOL_XDP 283
 #endif
diff --git a/samples/bpf/xsk_fwd.c b/samples/bpf/xsk_fwd.c
index 2324e18ccc7e..946d29dd2a9e 100644
--- a/samples/bpf/xsk_fwd.c
+++ b/samples/bpf/xsk_fwd.c
@@ -23,12 +23,9 @@
 #include <linux/if_xdp.h>
 
 #include <bpf/libbpf.h>
-#include <bpf/xsk.h>
+#include <xdp/xsk.h>
 #include <bpf/bpf.h>
 
-/* libbpf APIs for AF_XDP are deprecated starting from v0.7 */
-#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
-
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
 
 typedef __u64 u64;
-- 
2.35.1

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

[Hangbin Liu]

libbpf APIs for AF_XDP are deprecated starting from v0.7.
Let's move to libxdp.

Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
 tools/testing/selftests/bpf/xdpxceiver.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/tools/testing/selftests/bpf/xdpxceiver.c b/tools/testing/selftests/bpf/xdpxceiver.c
index e5992a6b5e09..e4969aa8c463 100644
--- a/tools/testing/selftests/bpf/xdpxceiver.c
+++ b/tools/testing/selftests/bpf/xdpxceiver.c
@@ -97,16 +97,10 @@
 #include <time.h>
 #include <unistd.h>
 #include <stdatomic.h>
-#include <bpf/xsk.h>
+#include <xdp/xsk.h>
 #include "xdpxceiver.h"
 #include "../kselftest.h"
 
-/* AF_XDP APIs were moved into libxdp and marked as deprecated in libbpf.
- * Until xdpxceiver is either moved or re-writed into libxdp, suppress
- * deprecation warnings in this file
- */
-#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
-
 static const char *MAC1 = "\x00\x0A\x56\x9E\xEE\x62";
 static const char *MAC2 = "\x00\x0A\x56\x9E\xEE\x61";
 static const char *IP1 = "192.168.100.162";
-- 
2.35.1

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

[Toke Høiland-Jørgensen]

Hangbin Liu <liuhangbin@gmail.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?

-Toke

[0] https://github.com/xdp-project/xdp-tools/pull/158

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

[Andrii Nakryiko]

On Tue, Jun 7, 2022 at 2:32 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> Hangbin Liu <liuhangbin@gmail.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?
>

Agree. Meanwhile it's probably better to make samples/bpf just compile
and use xsk.{c,h} from selftests/bpf.

> -Toke
>
> [0] https://github.com/xdp-project/xdp-tools/pull/158
>

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

[Hangbin Liu]

On Tue, Jun 07, 2022 at 11:31:57AM +0200, Toke Høiland-Jørgensen wrote:
> Hangbin Liu <liuhangbin@gmail.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?

Thanks
Hangbin

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

[Hangbin Liu]

On Tue, Jun 07, 2022 at 04:28:36PM -0700, Andrii Nakryiko wrote:
> > 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?
> >
> 
> Agree. Meanwhile it's probably better to make samples/bpf just compile
> and use xsk.{c,h} from selftests/bpf.

Hi Andrii,

I didn't find xsk.{c,h} in selftests/bpf. Do you mean xsk.{c,h} in
tools/lib/bpf? Should I add

TPROGS_CFLAGS += -I$(srctree)/tools/lib/

in samples/bpf/Makefile?

Thanks
Hangbin

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

[Magnus Karlsson]

On Wed, Jun 8, 2022 at 9:55 AM Hangbin Liu <liuhangbin@gmail.com> wrote:
>
> On Tue, Jun 07, 2022 at 11:31:57AM +0200, Toke Høiland-Jørgensen wrote:
> > Hangbin Liu <liuhangbin@gmail.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

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

[Hangbin Liu]

On Wed, Jun 08, 2022 at 12:18:14PM +0200, Magnus Karlsson wrote:
> On Wed, Jun 8, 2022 at 9:55 AM Hangbin Liu <liuhangbin@gmail.com> wrote:
> >
> > On Tue, Jun 07, 2022 at 11:31:57AM +0200, Toke Høiland-Jørgensen wrote:
> > > Hangbin Liu <liuhangbin@gmail.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!

Oh, I didn't notice this patch. I think it's a good plan.
Thanks for notify me.

Hangbin

> 
> 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

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

[Andrii Nakryiko]

On Wed, Jun 8, 2022 at 3:18 AM Magnus Karlsson
<magnus.karlsson@gmail.com> wrote:
>
> On Wed, Jun 8, 2022 at 9:55 AM Hangbin Liu <liuhangbin@gmail.com> wrote:
> >
> > On Tue, Jun 07, 2022 at 11:31:57AM +0200, Toke Høiland-Jørgensen wrote:
> > > Hangbin Liu <liuhangbin@gmail.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?
>

I think adding libxdp dependency for samples/bpf is a bad idea. Moving
samples to near libxdp makes more sense to me.


> [1] https://lore.kernel.org/bpf/20220603190155.3924899-2-andrii@kernel.org/
>
> > Thanks
> > Hangbin

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

[Daniel Borkmann]

On 6/9/22 10:29 PM, Andrii Nakryiko wrote:
> On Wed, Jun 8, 2022 at 3:18 AM Magnus Karlsson
> <magnus.karlsson@gmail.com> wrote:
>> On Wed, Jun 8, 2022 at 9:55 AM Hangbin Liu <liuhangbin@gmail.com> wrote:
>>> On Tue, Jun 07, 2022 at 11:31:57AM +0200, Toke Høiland-Jørgensen wrote:
>>>> Hangbin Liu <liuhangbin@gmail.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?
> 
> 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@kernel.org/
>>
>>> Thanks
>>> Hangbin