Re: [PATCH] libbpf: export inline helpers as symbols for xsk

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Mon, Apr 26, 2021 at 11:49 PM Magnus Karlsson
<magnus.karlsson@gmail.com> wrote:
>
> On Tue, Apr 27, 2021 at 1:20 AM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Mon, Apr 26, 2021 at 1:22 PM Kumar Kartikeya Dwivedi
> > <memxor@gmail.com> wrote:
> > >
> > > This helps people writing language bindings to not have to rewrite C
> > > wrappers for inline functions in the headers. We force inline the
> > > definition from the header for C and C++ consumers, but also export a
> > > symbol in the library for others. This keeps the performance
> > > advantages similar to using static inline, while also allowing tools
> > > like Rust's bindgen to generate wrappers for the functions.
> > >
> > > Also see
> > > https://lore.kernel.org/bpf/CAJ8uoz0QqR97qEYYK=VVCE9A=V=k2tKnH6wNM48jeak2RAmL0A@mail.gmail.com/
> > > for some context.
> > >
> > > Also see https://github.com/xdp-project/xdp-tools/pull/97 for more
> > > discussion on the same.
> > >
> > > extern inline is used as it's slightly better since it warns when an
> > > inline definition is missing.
> > >
> > > The fvisibility attribute goes on the inline definition, as essentially
> > > it acts as a declaration for the function, while the extern inline
> > > declaration ends up acting as a definition.
> > >
> > > Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> > > ---
> >
> > xsk is moving into libxdp, why not do this there, instead of exporting
> > a lot of symbols that we'll be deprecating very soon. It will also
> > incentivise customers to make a move more promptly.
> >
> > Bjorn, Magnus, what's the status of libxsk in libxdp?
>
> There is a branch in the repo with the xsk support of libbpf
> integrated into libxdp. But it has not been merged yet. Toke might
> still have some comments on it, do not know, but we have been fixing a
> number of issue during the past months (including one in Linux) so it
> is stable and performs well now. A simple sample and some tests are
> still missing. But the above Rust support is in that branch.
>
> What is your current time plan on the libbpf 1.0 release? Before that
> happens, I need to make the Linux samples and selftests self-contained
> and not reliant on the xsk support in libbpf since it will be
> disappearing. This basically amounts to moving the xsk libbpf
> functionality into a separate file and using that from the samples and
> tests. At this point in time, relying on the user having libxdp
> installed would not be a good idea since if they do not (the majority
> of people at this point I believe) it would break the build of
> samples/bpf and selftests/bpf. Please let me know what you think?

I'm hoping to finish BPF static linker work and then will start doing
libbpf 1.0 work. xsk.c stuff is not going away in at least next few
months. My objection is to keep extending that functionality in libbpf
if we are actively working on having all of that in libxdp.

>
> > >  tools/lib/bpf/libbpf.map | 16 ++++++++++++++
> > >  tools/lib/bpf/xsk.c      | 24 +++++++++++++++++++++
> > >  tools/lib/bpf/xsk.h      | 45 +++++++++++++++++++++++-----------------
> > >  3 files changed, 66 insertions(+), 19 deletions(-)
> > >
> >
> > [...]