* [PATCH bpf-next 1/3] samples/bpf/xdpsock_user.c: Get rid of bpf_prog_load_xattr()
2022-06-07 8:40 [PATCH bpf-next 0/3] move AF_XDP APIs to libxdp Hangbin Liu
@ 2022-06-07 8:40 ` Hangbin Liu
2022-06-07 8:40 ` [PATCH bpf-next 2/3] samples/bpf: move AF_XDP APIs to libxdp Hangbin Liu
` (2 subsequent siblings)
3 siblings, 0 replies; 12+ messages in thread
From: Hangbin Liu @ 2022-06-07 8:40 UTC (permalink / raw)
To: netdev
Cc: Alexei Starovoitov, Daniel Borkmann, David S. Miller,
Jakub Kicinski, Jesper Dangaard Brouer,
Toke Høiland-Jørgensen, John Fastabend,
Björn Töpel, Magnus Karlsson, Maciej Fijalkowski,
Jonathan Lemon, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, KP Singh, bpf, 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
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH bpf-next 2/3] samples/bpf: move AF_XDP APIs to libxdp
2022-06-07 8:40 [PATCH bpf-next 0/3] move AF_XDP APIs to libxdp Hangbin Liu
2022-06-07 8:40 ` [PATCH bpf-next 1/3] samples/bpf/xdpsock_user.c: Get rid of bpf_prog_load_xattr() Hangbin Liu
@ 2022-06-07 8:40 ` Hangbin Liu
2022-06-07 8:40 ` [PATCH bpf-next 3/3] selftests/bpf: " Hangbin Liu
2022-06-07 9:31 ` [PATCH bpf-next 0/3] " Toke Høiland-Jørgensen
3 siblings, 0 replies; 12+ messages in thread
From: Hangbin Liu @ 2022-06-07 8:40 UTC (permalink / raw)
To: netdev
Cc: Alexei Starovoitov, Daniel Borkmann, David S. Miller,
Jakub Kicinski, Jesper Dangaard Brouer,
Toke Høiland-Jørgensen, John Fastabend,
Björn Töpel, Magnus Karlsson, Maciej Fijalkowski,
Jonathan Lemon, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, KP Singh, bpf, 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
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH bpf-next 3/3] selftests/bpf: move AF_XDP APIs to libxdp
2022-06-07 8:40 [PATCH bpf-next 0/3] move AF_XDP APIs to libxdp Hangbin Liu
2022-06-07 8:40 ` [PATCH bpf-next 1/3] samples/bpf/xdpsock_user.c: Get rid of bpf_prog_load_xattr() Hangbin Liu
2022-06-07 8:40 ` [PATCH bpf-next 2/3] samples/bpf: move AF_XDP APIs to libxdp Hangbin Liu
@ 2022-06-07 8:40 ` Hangbin Liu
2022-06-07 9:31 ` [PATCH bpf-next 0/3] " Toke Høiland-Jørgensen
3 siblings, 0 replies; 12+ messages in thread
From: Hangbin Liu @ 2022-06-07 8:40 UTC (permalink / raw)
To: netdev
Cc: Alexei Starovoitov, Daniel Borkmann, David S. Miller,
Jakub Kicinski, Jesper Dangaard Brouer,
Toke Høiland-Jørgensen, John Fastabend,
Björn Töpel, Magnus Karlsson, Maciej Fijalkowski,
Jonathan Lemon, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, KP Singh, bpf, 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
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next 0/3] move AF_XDP APIs to libxdp
2022-06-07 8:40 [PATCH bpf-next 0/3] move AF_XDP APIs to libxdp Hangbin Liu
` (2 preceding siblings ...)
2022-06-07 8:40 ` [PATCH bpf-next 3/3] selftests/bpf: " Hangbin Liu
@ 2022-06-07 9:31 ` Toke Høiland-Jørgensen
2022-06-07 23:28 ` Andrii Nakryiko
2022-06-08 2:29 ` Hangbin Liu
3 siblings, 2 replies; 12+ messages in thread
From: Toke Høiland-Jørgensen @ 2022-06-07 9:31 UTC (permalink / raw)
To: Hangbin Liu, netdev
Cc: Alexei Starovoitov, Daniel Borkmann, David S. Miller,
Jakub Kicinski, Jesper Dangaard Brouer, John Fastabend,
Björn Töpel, Magnus Karlsson, Maciej Fijalkowski,
Jonathan Lemon, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, KP Singh, bpf, Hangbin Liu,
Kumar Kartikeya Dwivedi
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next 0/3] move AF_XDP APIs to libxdp
2022-06-07 9:31 ` [PATCH bpf-next 0/3] " Toke Høiland-Jørgensen
@ 2022-06-07 23:28 ` Andrii Nakryiko
2022-06-08 2:31 ` Hangbin Liu
2022-06-08 2:29 ` Hangbin Liu
1 sibling, 1 reply; 12+ messages in thread
From: Andrii Nakryiko @ 2022-06-07 23:28 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Hangbin Liu, Networking, Alexei Starovoitov, Daniel Borkmann,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
John Fastabend, Björn Töpel, Magnus Karlsson,
Maciej Fijalkowski, Jonathan Lemon, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, KP Singh, bpf,
Kumar Kartikeya Dwivedi
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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next 0/3] move AF_XDP APIs to libxdp
2022-06-07 23:28 ` Andrii Nakryiko
@ 2022-06-08 2:31 ` Hangbin Liu
0 siblings, 0 replies; 12+ messages in thread
From: Hangbin Liu @ 2022-06-08 2:31 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Toke Høiland-Jørgensen, Networking, Alexei Starovoitov,
Daniel Borkmann, David S. Miller, Jakub Kicinski,
Jesper Dangaard Brouer, John Fastabend, Björn Töpel,
Magnus Karlsson, Maciej Fijalkowski, Jonathan Lemon,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
KP Singh, bpf, Kumar Kartikeya Dwivedi
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next 0/3] move AF_XDP APIs to libxdp
2022-06-07 9:31 ` [PATCH bpf-next 0/3] " Toke Høiland-Jørgensen
2022-06-07 23:28 ` Andrii Nakryiko
@ 2022-06-08 2:29 ` Hangbin Liu
2022-06-08 10:18 ` Magnus Karlsson
1 sibling, 1 reply; 12+ messages in thread
From: Hangbin Liu @ 2022-06-08 2:29 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: netdev, Alexei Starovoitov, Daniel Borkmann, David S. Miller,
Jakub Kicinski, Jesper Dangaard Brouer, John Fastabend,
Björn Töpel, Magnus Karlsson, Maciej Fijalkowski,
Jonathan Lemon, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, KP Singh, bpf, Kumar Kartikeya Dwivedi
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next 0/3] move AF_XDP APIs to libxdp
2022-06-08 2:29 ` Hangbin Liu
@ 2022-06-08 10:18 ` Magnus Karlsson
2022-06-09 1:26 ` Hangbin Liu
2022-06-09 20:29 ` Andrii Nakryiko
0 siblings, 2 replies; 12+ messages in thread
From: Magnus Karlsson @ 2022-06-08 10:18 UTC (permalink / raw)
To: Hangbin Liu
Cc: Toke Høiland-Jørgensen, Network Development,
Alexei Starovoitov, Daniel Borkmann, David S. Miller,
Jakub Kicinski, Jesper Dangaard Brouer, John Fastabend,
Björn Töpel, Magnus Karlsson, Maciej Fijalkowski,
Jonathan Lemon, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, KP Singh, bpf, Kumar Kartikeya Dwivedi
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next 0/3] move AF_XDP APIs to libxdp
2022-06-08 10:18 ` Magnus Karlsson
@ 2022-06-09 1:26 ` Hangbin Liu
2022-06-09 20:29 ` Andrii Nakryiko
1 sibling, 0 replies; 12+ messages in thread
From: Hangbin Liu @ 2022-06-09 1:26 UTC (permalink / raw)
To: Magnus Karlsson
Cc: Toke Høiland-Jørgensen, Network Development,
Alexei Starovoitov, Daniel Borkmann, David S. Miller,
Jakub Kicinski, Jesper Dangaard Brouer, John Fastabend,
Björn Töpel, Magnus Karlsson, Maciej Fijalkowski,
Jonathan Lemon, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, KP Singh, bpf, Kumar Kartikeya Dwivedi
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next 0/3] move AF_XDP APIs to libxdp
2022-06-08 10:18 ` Magnus Karlsson
2022-06-09 1:26 ` Hangbin Liu
@ 2022-06-09 20:29 ` Andrii Nakryiko
2022-06-09 20:52 ` Daniel Borkmann
1 sibling, 1 reply; 12+ messages in thread
From: Andrii Nakryiko @ 2022-06-09 20:29 UTC (permalink / raw)
To: Magnus Karlsson
Cc: Hangbin Liu, Toke Høiland-Jørgensen,
Network Development, Alexei Starovoitov, Daniel Borkmann,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
John Fastabend, Björn Töpel, Magnus Karlsson,
Maciej Fijalkowski, Jonathan Lemon, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, KP Singh, bpf,
Kumar Kartikeya Dwivedi
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH bpf-next 0/3] move AF_XDP APIs to libxdp
2022-06-09 20:29 ` Andrii Nakryiko
@ 2022-06-09 20:52 ` Daniel Borkmann
0 siblings, 0 replies; 12+ messages in thread
From: Daniel Borkmann @ 2022-06-09 20:52 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Magnus Karlsson, Hangbin Liu, Toke Høiland-Jørgensen,
Network Development, Alexei Starovoitov, David S. Miller,
Jakub Kicinski, Jesper Dangaard Brouer, John Fastabend,
Björn Töpel, Magnus Karlsson, Maciej Fijalkowski,
Jonathan Lemon, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, KP Singh, bpf, Kumar Kartikeya Dwivedi
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
^ permalink raw reply [flat|nested] 12+ messages in thread