| Message ID | 20210310080929.641212-1-bjorn.topel@gmail.com |
|---|---|
| Headers | show |
| Series | libbpf/xsk cleanups | expand |
On Wed, Mar 10, 2021 at 12:09 AM Björn Töpel <bjorn.topel@gmail.com> wrote: > > From: Björn Töpel <bjorn.topel@intel.com> > > The only user of libbpf_util.h is xsk.h. Move the barriers to xsk.h, > and remove libbpf_util.h. The barriers are used as an implementation > detail, and should not be considered part of the stable API. > > Signed-off-by: Björn Töpel <bjorn.topel@intel.com> > --- > tools/lib/bpf/Makefile | 1 - > tools/lib/bpf/libbpf_util.h | 82 ------------------------------------- > tools/lib/bpf/xsk.h | 68 +++++++++++++++++++++++++++++- > 3 files changed, 67 insertions(+), 84 deletions(-) > delete mode 100644 tools/lib/bpf/libbpf_util.h > [...] > diff --git a/tools/lib/bpf/xsk.h b/tools/lib/bpf/xsk.h > index a9fdea87b5cd..1d846a419d21 100644 > --- a/tools/lib/bpf/xsk.h > +++ b/tools/lib/bpf/xsk.h > @@ -4,6 +4,7 @@ > * AF_XDP user-space access library. > * > * Copyright(c) 2018 - 2019 Intel Corporation. Couldn't unsee ^this mismatch. Added space there. Also, removing libbpf_util.h caused incremental build failure for the kernel due to cached dependency files. make clean solved the issue. So just FYI for everyone. Applied to bpf-next, thanks. > + * Copyright (c) 2019 Facebook > * > * Author(s): Magnus Karlsson <magnus.karlsson@intel.com> > */ > @@ -13,15 +14,80 @@ > > #include <stdio.h> > #include <stdint.h> > +#include <stdbool.h> > #include <linux/if_xdp.h> > > #include "libbpf.h" > -#include "libbpf_util.h" > > #ifdef __cplusplus > extern "C" { > #endif > [...]
On Wed, Mar 10, 2021 at 09:09:29AM +0100, Björn Töpel wrote: > From: Björn Töpel <bjorn.topel@intel.com> > > The only user of libbpf_util.h is xsk.h. Move the barriers to xsk.h, > and remove libbpf_util.h. The barriers are used as an implementation > detail, and should not be considered part of the stable API. Does that mean that anything else which uses the same type of shared rings (bpf ringbuffer, io_uring, zctap) have to implement the same primitives that xsk.h has?
On 2021-03-11 01:06, Jonathan Lemon wrote: > On Wed, Mar 10, 2021 at 09:09:29AM +0100, Björn Töpel wrote: >> From: Björn Töpel <bjorn.topel@intel.com> >> >> The only user of libbpf_util.h is xsk.h. Move the barriers to xsk.h, >> and remove libbpf_util.h. The barriers are used as an implementation >> detail, and should not be considered part of the stable API. > > Does that mean that anything else which uses the same type of > shared rings (bpf ringbuffer, io_uring, zctap) have to implement > the same primitives that xsk.h has? > Jonathan, there's a longer explanation on back-/forward-compatibility in the commit message [1]. Again, this is for the XDP socket rings, so I wont comment on the other rings. I would not assume compatibility between different rings (e.g. the bpf ringbuffer and XDP sockets rings), not even prior the barrier change. Björn [1] https://lore.kernel.org/bpf/20210305094113.413544-2-bjorn.topel@gmail.com/
On Wed, Mar 10, 2021 at 10:59 PM Björn Töpel <bjorn.topel@intel.com> wrote: > > On 2021-03-11 01:06, Jonathan Lemon wrote: > > On Wed, Mar 10, 2021 at 09:09:29AM +0100, Björn Töpel wrote: > >> From: Björn Töpel <bjorn.topel@intel.com> > >> > >> The only user of libbpf_util.h is xsk.h. Move the barriers to xsk.h, > >> and remove libbpf_util.h. The barriers are used as an implementation > >> detail, and should not be considered part of the stable API. > > > > Does that mean that anything else which uses the same type of > > shared rings (bpf ringbuffer, io_uring, zctap) have to implement > > the same primitives that xsk.h has? > > > > Jonathan, there's a longer explanation on back-/forward-compatibility in > the commit message [1]. Again, this is for the XDP socket rings, so I > wont comment on the other rings. I would not assume compatibility > between different rings (e.g. the bpf ringbuffer and XDP sockets rings), > not even prior the barrier change. > > BPF ringbuf is using smp_store_release()/smp_load_acquire(), which are coming from asm/barrier.h. But libbpf abstracts all the low-level details, so users don't have to use such low-level primitives directly. > Björn > > [1] > https://lore.kernel.org/bpf/20210305094113.413544-2-bjorn.topel@gmail.com/ >