Re: [RFC bpf-next 0/5] Convert iproute2 to use libbpf (WIP)
From: David Ahern <hidden>
Date: 2020-02-04 22:12:34
Also in:
bpf
On 2/4/20 2:56 PM, Toke Høiland-Jørgensen wrote:
quoted
I'm confused, honestly. libbpf is either a dependency and thus can be relied upon to be present in the target system, or it's not and this whole dance with detecting libbpf presence needs to be performed.Yes, and iproute2 is likely to be built in both sorts of environments, so we will have to support both :)quoted
If libbpf is optional, then I don't see how iproute2 BPF-related code and complexity can be reduced at all, given it should still support loading BPF programs even without libbpf. Furthermore, given libbpf supports more features already and will probably be outpacing iproute2's own BPF support in the future, some users will start relying on BPF features supported only by libbpf "backend", so iproute2's own BPF backend will just fail to load such programs, bringing unpleasant surprises, potentially. So I still fail to see how libbpf can be optional and what benefit does that bring.I wasn't saying that libbpf itself should be optional; if we're porting things, we should rip out as much of the old code as we can. I just meant that we should support both modes of building, so distros that *do* build libbpf as a library can link iproute2 against that with as little friction as possible. I'm dead set on a specific auto-detection semantic either; I guess it'll be up to the iproute2 maintainers whether they prefer defaulting to one or the other.
A few concerns from my perspective: 1. Right now ip comes in around 650k unstripped; libbpf.a for 0.0.7 is around 1.2M with the size of libbpf.o > than ip. Most likely, making iproute2 use libbpf statically is going to be challenging and I am not sure it is the right thing to do (unless the user is building a static version of iproute2 commands). 2. git submodules can be a PITA to deal with (e.g., jumping between branches and versions), so there needs to be a good reason for it. 3. iproute2 code needs to build for a wide range of OSes and not lose functionality compared to what it has today.