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

[Daniel Borkmann <daniel@iogearbox.net>]

On 11/11/20 12:02 PM, Toke Høiland-Jørgensen wrote:
> Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
>> On Mon, Nov 09, 2020 at 09:09:44PM -0700, David Ahern wrote:
>>> On 11/8/20 6:45 PM, Alexei Starovoitov wrote:
>>>>
>>>> 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
>>>
>>> I believe you have confused my comments with others. My comments have
>>> focused on one aspect: The insistence by BPF maintainers that all code
>>> bases and users constantly chase latest and greatest versions of
>>> relevant S/W to use BPF
>>
>> yes, because we care about user experience while you're still insisting
>> on make it horrible.
>> With random pick of libbpf.so we would have no choice, but to actively tell
>> users to avoid using tc, because sooner or later they will be pissed. I'd
>> rather warn them ahead of time.
> 
> Could we *please* stop with this "my way or the highway" extortion? It's
> incredibly rude, and it's not helping the discussion.
> 
>>> - though I believe a lot of the tool chasing
>>> stems from BTF. I am fairly certain I have been consistent in that theme
>>> within this thread.
>>
>> Right. A lot of features added in the last couple years depend on BTF:
>> static vs global linking, bpf_spin_lock, function by function verification, etc
>>
>>>> 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
>>>
>>> Your gdb / libbfd analogy misses the mark - by a lot. That analogy is
>>> relevant for bpftool, not iproute2.
>>>
>>> iproute2 can leverage libbpf for 3 or 4 tc modules and a few xdp hooks.
>>> That is it, and it is a tiny percentage of the functionality in the package.
>>
>> cat tools/lib/bpf/*.[hc]|wc -l
>> 23950
>> cat iproute2/tc/*.[hc]|wc -l
>> 29542
>>
>> The point is that for these few tc commands the amount logic in libbpf/tc is 90/10.
>>
>> Let's play it out how libbpf+tc is going to get developed moving forward if
>> libbpf is a random version. Say, there is a patch for libbpf that makes
>> iproute2 experience better. bpf maintainers would have no choice, but to reject
>> it, since we don't add features/apis to libbpf if there is no active user.
>> Adding a new libbpf api that iproute2 few years from now may or may not take
>> advantage makes little sense.
> 
> What? No one has said that iproute2 would never use any new features,
> just that they would be added conditionally on a compatibility check
> with libbpf (like the check for bpf_program__section_name() in the
> current patch series).
> 
> 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. It's not about compatibility,
but rather about __users__ of the loader being able to __benefit__ of the latest
features their distro kernel ships from BPF (& libbpf) side just as they do with
iproute2 extensions. For the integrated lib/bpf.c in iproute2 this was never an
issue and for multiple years in the earlier days it was much further ahead than
libbpf which was only tracing-focused before we decided to put focus on the latter
as a more general loader instead. But if you ever want to start a deprecation process
of the lib/bpf.c then users should not need to worry whether iproute2 was even linked
to libbpf in the first place, they should be able to have a guarantee that it's
__generally available__ as with lib/bpf.c, otherwise they'll always just assume
the latter as the minimal available base when writing code against iproute2 loader.
Hypothetically speaking, if Hangbin would have presented patches here to extend the
existing lib/bpf.c to the point that it's feature complete (compared to libbpf),
we wouldn't even have this whole discussion here.

Thanks,
Daniel