Message-ID: <1118ef27-3302-d077-021a-43aa8d8f3ebb@mojatatu.com>
Date:   Thu, 5 Nov 2020 09:05:48 -0500
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     David Ahern <dsahern@...il.com>,
        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 2020-11-04 10:19 p.m., David Ahern wrote:

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


2cents feedback from a dabbler in ebpf on user experience:

What David described above *has held me back*.
Over time it seems things have gotten better with libbpf
(although a few times i find myself copying includes from the
latest iproute into libbpf). I ended up just doing static links.
The idea of upgrading clang/llvm every 2 months i revisit ebpf is
the most painful. At times code that used to compile just fine
earlier doesnt anymore. There's a minor issue of requiring i install
kernel headers every time i want to run something in samples, etc
but i am probably lacking knowledge on how to ease the pain in that
regard.

I find the loader and associated tooling in iproute2/tc to be quiet
stable (not shiny but works everytime).
And for that reason i often find myself sticking to just tc instead
of toying with other areas.
Slight tangent:
One thing that would help libbpf adoption is to include an examples/
directory. Put a bunch of sample apps for tc, probes, xdp etc.
And have them compile outside of the kernel. Maybe useful Makefiles
that people can cutnpaste from. Every time you add a new feature
put some sample code in the examples.

cheers,
jamal

Powered by blists - more mailing lists