Message-ID: <ec50328d-61ab-71fb-f266-5e49e9dbf98e@gmail.com>
Date:   Wed, 4 Nov 2020 20:19:25 -0700
From:   David Ahern <dsahern@...il.com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Hangbin Liu <haliu@...hat.com>
Cc:     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>,
        Toke Høiland-Jørgensen <toke@...hat.com>
Subject: Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

On 11/4/20 3:21 AM, Daniel Borkmann wrote:
> 
>> Then libbpf release process can incorporate proper testing of libbpf
>> and iproute2 combination.
>> Or iproute2 should stay as-is with obsolete bpf support.
>>
>> Few years from now the situation could be different and shared libbpf
>> would
>> be the most appropriate choice. But that day is not today.
> 
> Yep, for libbpf to be in same situation as libelf or libmnl basically
> feature
> development would have to pretty much come to a stop so that even minor
> or exotic
> distros get to a point where they ship same libbpf version as major
> distros where
> then users can start to rely on the base feature set for developing
> programs
> against it.

User experience keeps getting brought up, but I also keep reading the
stance that BPF users can not expect a consistent experience unless they
are constantly chasing latest greatest versions of *ALL* S/W related to
BPF. That is not a realistic expectation for users. Distributions exist
for a reason. They solve real packaging problems.

As libbpf and bpf in general reach a broader audience, the requirements
to use, deploy and even tryout BPF features needs to be more user
friendly and that starts with maintainers of the BPF code and how they
approach extensions and features. Telling libbpf consumers to make
libbpf a submodule of their project and update the reference point every
time a new release comes out is not user friendly.

Similarly, it is not realistic or user friendly to *require* general
Linux users to constantly chase latest versions of llvm, clang, dwarves,
bcc, bpftool, libbpf, (I am sure I am missing more), and, by extension
of what you want here, iproute2 just to upgrade their production kernel
to say v5.10, the next LTS, or to see what relevant new ebpf features
exists in the new kernel. As a specific example BTF extensions are added
in a way that is all or nothing. Meaning, you want to compile kernel
version X with CONFIG_DEBUG_INFO_BTF enabled, update your toolchain.
Sure, you are using the latest LTS of $distro, and it worked fine with
kernel version X-1 last week, but now compile fails completely unless
the pahole version is updated. Horrible user experience. Again, just an
example and one I brought up in July. I am sure there more.

Linux APIs are about stability and consistency. Commands and libraries
that work on v5.9 should work exactly the same on v5.10, 5.11, 5.12, ...
*IF* I want a new feature (kernel, bpf or libbpf), then the requirement
to upgrade is justified. But if I am just updating my kernel, or
updating my compiler, or updating iproute2 because I want to try out
some new nexthop feature, I should not be cornered into an all or
nothing scheme.

Powered by blists - more mailing lists