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.
