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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux