Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Fri, Nov 06, 2020 at 04:38:13PM -0700, David Ahern wrote:
> On 11/6/20 4:25 PM, Stephen Hemminger wrote:
> >>
> >> I think bumping the minimal version of libbpf with every iproute2 release
> >> is necessary as well.
> >> Today iproute2-next should require 0.2.0. The cycle after it should be 0.3.0
> >> and so on.
> >> This way at least some correlation between iproute2 and libbpf will be
> >> established.
> >> Otherwise it's a mess of versions and functionality from user point of view.
> 
> If existing bpf features in iproute2 work fine with version 0.1.0, what
> is the justification for an arbitrary requirement for iproute2 to force
> users to bump libbpf versions just to use iproute2 from v5.11?

I don't understand why on one side you're pointing out existing quirkiness with
bpf usability while at the same time arguing to make it _less_ user friendly
when myself, Daniel, Andrii explained in detail what libbpf does and how it
affects user experience?

The analogy of libbpf in iproute2 and libbfd in gdb is that both libraries
perform large percentage of functionality comparing to the rest of the tool.
When library is dynamic linked it makes user experience unpredictable. My guess
is that libbfd is ~50% of what gdb is doing. What will the users say if gdb
suddenly behaves differently (supports less or more elf files) because
libbfd.so got upgraded in the background? In case of tc+libbpf the break down
of funcionality is heavliy skewed towards libbpf. The amount of logic iproute2
code will do to perform "tc filter ... bpf..." command is 10% iproute2 / 90%
libbpf. Issuing few netlink calls to attach bpf prog to a qdisc is trivial
comparing to what libbpf is doing with an elf file. There is a linker inside
libbpf. It will separate different functions inside elf file. It will relocate
code and adjust instructions before sending it to the kernel. libbpf is not
a wrapper. It's a mini compiler: CO-RE logic, function relocation, dynamic
kernel feature probing, etc. When the users use a command line tool (like
iproute2 or bpftool) they are interfacing with the tool. It's not unix-like to
demand that users should check the version of a shared library and adjust their
expectations. The UI is the command line. Its version is as a promise of
features. iproute2 of certain version in one distro should behave the same as
iproute2 in another distro. By not doing git submodule that promise is broken.
Hence my preference is to use fixed libbpf sha for every iproute2 release. The
other alternative is to lag iproute2/libbpf one release behind. Hence
repeating what I said earlier: Today iproute2-next should require 0.2.0. The
iprtoute2 in the next cycle _must_ bump be the minimum libbpf version to 0.3.0.
Not bumping minimum version brings us to square one and unpredicatable user
experience. The users are jumping through enough hoops when they develop bpf
programs. We have to make it simpler and easier. Using libbpf in iproute2
can improve the user experience, but only if it's predictable.