Message-ID: <5de7eb11-010b-e66e-c72d-07ece638c25e@iogearbox.net>
Date:   Wed, 4 Nov 2020 14:12:47 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Toke Høiland-Jørgensen <toke@...hat.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Hangbin Liu <haliu@...hat.com>
Cc:     David Ahern <dsahern@...il.com>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        David Miller <davem@...emloft.net>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Jiri Benc <jbenc@...hat.com>,
        Andrii Nakryiko <andrii@...nel.org>
Subject: Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

On 11/4/20 12:20 PM, Toke Høiland-Jørgensen wrote:
> Daniel Borkmann <daniel@...earbox.net> writes:
> 
>> Back in the days when developing lib/bpf.c, it was explicitly done as
>> built-in for iproute2 so that it doesn't take years for users to
>> actually get to the point where they can realistically make use of it.
>> If we were to extend the internal lib/bpf.c to similar feature state
>> as libbpf today, how is that different in the bigger picture compared
>> to sync or submodule... so far noone complained about lib/bpf.c.
> 
> Except that this whole effort started because lib/bpf.c is slowly
> bitrotting into oblivion? If all the tools are dynamically linked
> against libbpf, that's only one package the distros have to keep
> up-to-date instead of a whole list of tools. How does that make things
> *worse*?

It sounds good in theory if that would all work out as expected, but reality
differs unfortunately. Today on vast majority of distros you are able to use
iproute2's BPF loader via lib/bpf.c given it's a fixed built-in, even if
it's bitrotting for a while now in terms of features^BTF, but the base functionality
that is in there can be used, and it is used in the wild today. If libbpf is
dynamically linked to iproute2, then I - as a user - am left with continuing
to assume that the current lib/bpf.c is the /only/ base that is really /guaranteed/
to be available as a loader across distros, but iproute2 + libbpf may not be
(it may be the case for RHEL but potentially not others). So from user PoV
I might be sticking to the current lib/bpf.c that iproute2 ships instead of
converting code over until even major distros catch up in maybe 2 years from now
(that is in fact how long it took Canonical to get bpftool included, not kidding).
If we would have done lib/bpf.c as a dynamic library back then, we wouldn't be
where we are today since users might be able to start consuming BPF functionality
just now, don't you agree? This was an explicit design choice back then for exactly
this reason. If we extend lib/bpf.c or import libbpf one way or another then there
is consistency across distros and users would be able to consume it in a predictable
way starting from next major releases. And you could start making this assumption
on all major distros in say, 3 months from now. The discussion is somehow focused
on the PoV of /a/ distro which is all nice and good, but the ones consuming the
loader shipping software /across/ distros are users writing BPF progs, all I'm
trying to say is that the _user experience_ should be the focus of this discussion
and right now we're trying hard making it rather painful for them to consume it.

Cheers,
Daniel

Powered by blists - more mailing lists