From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Daniel Borkmann <daniel@iogearbox.net>,
Stephen Hemminger <stephen@networkplumber.org>,
Alexei Starovoitov <ast@kernel.org>
Cc: Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>, David Miller <davem@davemloft.net>,
Jesper Dangaard Brouer <brouer@redhat.com>,
netdev@vger.kernel.org, bpf@vger.kernel.org,
andrii.nakryiko@gmail.com
Subject: Re: [RFC bpf-next 4/5] iproute2: Allow compiling against libbpf
Date: Thu, 22 Aug 2019 14:04:00 +0200 [thread overview]
Message-ID: <877e75pftb.fsf@toke.dk> (raw)
In-Reply-To: <0c3d78eb-d305-9266-b505-c2f9181d5c89@iogearbox.net>
Daniel Borkmann <daniel@iogearbox.net> writes:
> On 8/22/19 12:43 PM, Toke Høiland-Jørgensen wrote:
>> Daniel Borkmann <daniel@iogearbox.net> writes:
>>> On 8/20/19 1:47 PM, Toke Høiland-Jørgensen wrote:
>>>> This adds a configure check for libbpf and renames functions to allow
>>>> lib/bpf.c to be compiled with it present. This makes it possible to
>>>> port functionality piecemeal to use libbpf.
>>>>
>>>> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
>>>> ---
>>>> configure | 16 ++++++++++++++++
>>>> include/bpf_util.h | 6 +++---
>>>> ip/ipvrf.c | 4 ++--
>>>> lib/bpf.c | 33 +++++++++++++++++++--------------
>>>> 4 files changed, 40 insertions(+), 19 deletions(-)
>>>>
>>>> diff --git a/configure b/configure
>>>> index 45fcffb6..5a89ee9f 100755
>>>> --- a/configure
>>>> +++ b/configure
>>>> @@ -238,6 +238,19 @@ check_elf()
>>>> fi
>>>> }
>>>>
>>>> +check_libbpf()
>>>> +{
>>>> + if ${PKG_CONFIG} libbpf --exists; then
>>>> + echo "HAVE_LIBBPF:=y" >>$CONFIG
>>>> + echo "yes"
>>>> +
>>>> + echo 'CFLAGS += -DHAVE_LIBBPF' `${PKG_CONFIG} libbpf --cflags` >> $CONFIG
>>>> + echo 'LDLIBS += ' `${PKG_CONFIG} libbpf --libs` >>$CONFIG
>>>> + else
>>>> + echo "no"
>>>> + fi
>>>> +}
>>>> +
>>>> check_selinux()
>>>
>>> More of an implementation detail at this point in time, but want to
>>> make sure this doesn't get missed along the way: as discussed at
>>> bpfconf [0] best for iproute2 to handle libbpf support would be the
>>> same way of integration as pahole does, that is, to integrate it via
>>> submodule [1] to allow kernel and libbpf features to be in sync with
>>> iproute2 releases and therefore easily consume extensions we're adding
>>> to libbpf to aide iproute2 integration.
>>
>> I can sorta see the point wrt keeping in sync with kernel features. But
>> how will this work with distros that package libbpf as a regular
>> library? Have you guys given up on regular library symbol versioning for
>> libbpf?
>
> Not at all, and I hope you know that. ;-)
Good! Didn't really expect you had, just checking ;)
> The reason I added lib/bpf.c integration into iproute2 directly back
> then was exactly such that users can start consuming BPF for tc and
> XDP via iproute2 /everywhere/ with only a simple libelf dependency
> which is also available on all distros since pretty much forever. If
> it was an external library, we could have waited till hell freezes
> over and initial distro adoption would have pretty much taken forever:
> to pick one random example here wrt the pace of some downstream
> distros [0]. The main rationale is pretty much the same as with added
> kernel features that land complementary iproute2 patches for that
> kernel release and as libbpf is developed alongside it is reasonable
> to guarantee user expectations that iproute2 released for kernel
> version x can make use of BPF features added to kernel x with same
> loader support from x.
Well, for iproute2 I would expect this to be solved by version
dependencies. I.e. iproute2 version X would depend on libbpf version Y+
(like, I dunno, the version of libbpf included in the same kernel source
tree as the kernel version iproute2 is targeting? :)).
If we vendor libbpf into every project using it, we'll end up with
dozens of different versions statically linked into each binary, kinda
defeating the purpose of having it as a shared library in the first
place...
-Toke
next prev parent reply other threads:[~2019-08-22 12:04 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-20 11:47 [RFC bpf-next 0/5] Convert iproute2 to use libbpf (WIP) Toke Høiland-Jørgensen
2019-08-20 11:47 ` [RFC bpf-next 1/5] libbpf: Add map definition struct fields from iproute2 Toke Høiland-Jørgensen
2019-08-20 11:47 ` [RFC bpf-next 2/5] libbpf: Add support for auto-pinning of maps with reuse on program load Toke Høiland-Jørgensen
2019-08-20 11:47 ` [RFC bpf-next 3/5] libbpf: Add support for specifying map pinning path via callback Toke Høiland-Jørgensen
2019-08-20 11:47 ` [RFC bpf-next 4/5] iproute2: Allow compiling against libbpf Toke Høiland-Jørgensen
2019-08-22 8:58 ` Daniel Borkmann
2019-08-22 10:43 ` Toke Høiland-Jørgensen
2019-08-22 11:45 ` Daniel Borkmann
2019-08-22 12:04 ` Toke Høiland-Jørgensen [this message]
2019-08-22 12:33 ` Daniel Borkmann
2019-08-22 13:38 ` Toke Høiland-Jørgensen
2019-08-22 13:45 ` Daniel Borkmann
2019-08-22 15:28 ` Toke Høiland-Jørgensen
2019-08-20 11:47 ` [RFC bpf-next 5/5] iproute2: Support loading XDP programs with libbpf Toke Høiland-Jørgensen
2019-08-21 19:26 ` [RFC bpf-next 0/5] Convert iproute2 to use libbpf (WIP) Alexei Starovoitov
2019-08-21 21:00 ` Toke Høiland-Jørgensen
2019-08-22 7:52 ` Andrii Nakryiko
2019-08-22 10:38 ` Toke Høiland-Jørgensen
2019-08-21 20:30 ` Andrii Nakryiko
2019-08-21 21:07 ` Toke Høiland-Jørgensen
2019-08-22 7:49 ` Andrii Nakryiko
2019-08-22 8:33 ` Daniel Borkmann
2019-08-22 11:48 ` Toke Høiland-Jørgensen
2019-08-22 11:49 ` Toke Høiland-Jørgensen
2019-08-23 6:31 ` Andrii Nakryiko
2019-08-23 11:29 ` Toke Høiland-Jørgensen
2019-08-28 20:40 ` Andrii Nakryiko
2020-02-03 7:29 ` Andrii Nakryiko
2020-02-03 19:34 ` Toke Høiland-Jørgensen
2020-02-04 0:56 ` Andrii Nakryiko
2020-02-04 1:46 ` David Ahern
2020-02-04 3:41 ` Andrii Nakryiko
2020-02-04 4:52 ` David Ahern
2020-02-04 5:00 ` Andrii Nakryiko
2020-02-04 8:25 ` Toke Høiland-Jørgensen
2020-02-04 18:47 ` Andrii Nakryiko
2020-02-04 19:19 ` Toke Høiland-Jørgensen
2020-02-04 19:29 ` Andrii Nakryiko
2020-02-04 21:56 ` Toke Høiland-Jørgensen
2020-02-04 22:12 ` David Ahern
2020-02-04 22:35 ` Toke Høiland-Jørgensen
2020-02-04 23:13 ` David Ahern
2020-02-05 10:37 ` Toke Høiland-Jørgensen
2020-02-04 8:27 ` Toke Høiland-Jørgensen
2019-08-23 10:27 ` Jesper Dangaard Brouer
2019-08-28 20:23 ` Andrii Nakryiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877e75pftb.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=kafai@fb.com \
--cc=netdev@vger.kernel.org \
--cc=songliubraving@fb.com \
--cc=stephen@networkplumber.org \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).