Message-ID: <CAJ8uoz2s9ieED4hs_2weHCRkcW5M8JgOdj1ORntqJzxTdCHa9w@mail.gmail.com>
Date:   Tue, 27 Apr 2021 08:49:42 +0200
From:   Magnus Karlsson <magnus.karlsson@...il.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     Kumar Kartikeya Dwivedi <memxor@...il.com>,
        bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Björn Töpel <bjorn@...nel.org>,
        Magnus Karlsson <magnus.karlsson@...el.com>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Networking <netdev@...r.kernel.org>
Subject: Re: [PATCH] libbpf: export inline helpers as symbols for xsk

On Tue, Apr 27, 2021 at 1:20 AM Andrii Nakryiko
<andrii.nakryiko@...il.com> wrote:
>
> On Mon, Apr 26, 2021 at 1:22 PM Kumar Kartikeya Dwivedi
> <memxor@...il.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@...il.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?

> >  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(-)
> >
>
> [...]

Powered by blists - more mailing lists