Message-ID: <20201112160437.64c36022@hermes.local>
Date:   Thu, 12 Nov 2020 16:04:37 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        David Ahern <dsahern@...il.com>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Jiri Benc <jbenc@...hat.com>,
        Edward Cree <ecree@...arflare.com>,
        Hangbin Liu <haliu@...hat.com>,
        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>,
        Andrii Nakryiko <andrii@...nel.org>
Subject: Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

On Fri, 13 Nov 2020 00:20:52 +0100
Daniel Borkmann <daniel@...earbox.net> wrote:

> On 11/12/20 11:36 PM, Toke Høiland-Jørgensen wrote:
> > Daniel Borkmann <daniel@...earbox.net> writes:
> >   
> >>> Besides, for the entire history of BPF support in iproute2 so far, the
> >>> benefit has come from all the features that libbpf has just started
> >>> automatically supporting on load (BTF, etc), so users would have
> >>> benefited from automatic library updates had it *not* been vendored in.  
> >>
> >> Not really. What you imply here is that we're living in a perfect
> >> world and that all distros follow suite and i) add libbpf dependency
> >> to their official iproute2 package, ii) upgrade iproute2 package along
> >> with new kernel releases and iii) upgrade libbpf along with it so that
> >> users are able to develop BPF programs against the feature set that
> >> the kernel offers (as intended). These are a lot of moving parts to
> >> get right, and as I pointed out earlier in the conversation, it took
> >> major distros 2 years to get their act together to officially include
> >> bpftool as a package - I'm not making this up, and this sort of pace
> >> is simply not sustainable. It's also not clear whether distros will
> >> get point iii) correct.  
> > 
> > I totally get that you've been frustrated with the distro adoption and
> > packaging of BPF-related tools. And rightfully so. I just don't think
> > that the answer to this is to try to work around distros, but rather to
> > work with them to get things right.
> > 
> > I'm quite happy to take a shot at getting a cross-distro effort going in
> > this space; really, having well-supported BPF tooling ought to be in
> > everyone's interest!  
> 
> Thanks, yes, that is worth a push either way! There is still a long tail
> of distros that are not considered major and until they all catch up with
> points i)-iii) it might take a much longer time until this becomes really
> ubiquitous with iproute2 for users of the libbpf loader. Its that this
> frustrating user experience could be avoided altogether. iproute2 is
> shipped and run also on small / embedded devices hence it tries to have
> external dependencies reduced to a bare minimum (well, except that libmnl
> detour, but it's not a mandatory dependency). If I were a user and would
> rely on the loader for my progs to be installed I'd probably end up
> compiling my own version of iproute2 linked with libbpf to move forward
> instead of being blocked on distro to catch up, but its an additional
> hassle for shipping SW instead of just having it all pre-installed when
> built-in given it otherwise comes with the base distro already. But then
> my question is what is planned here as deprecation process for the built-in
> lib/bpf.c code? I presume we'll remove it eventually to move on?

Perf has a similar problem and it made it into most distributions because it is
a valuable tool. Maybe there is some lessons learned that could apply here.

Powered by blists - more mailing lists