On Tue, Aug 20, 2019 at 01:47:01PM +0200, Toke Høiland-Jørgensen wrote: > iproute2 uses its own bpf loader to load eBPF programs, which has > evolved separately from libbpf. Since we are now standardising on > libbpf, this becomes a problem as iproute2 is slowly accumulating > feature incompatibilities with libbpf-based loaders. In particular, > iproute2 has its own (expanded) version of the map definition struct, > which makes it difficult to write programs that can be loaded with both > custom loaders and iproute2. > > This series seeks to address this by converting iproute2 to using libbpf > for all its bpf needs. This version is an early proof-of-concept RFC, to > get some feedback on whether people think this is the right direction. > > What this series does is the following: > > - Updates the libbpf map definition struct to match that of iproute2 > (patch 1). > - Adds functionality to libbpf to support automatic pinning of maps when > loading an eBPF program, while re-using pinned maps if they already > exist (patches 2-3). > - Modifies iproute2 to make it possible to compile it against libbpf > without affecting any existing functionality (patch 4). > - Changes the iproute2 eBPF loader to use libbpf for loading XDP > programs (patch 5). > > > As this is an early PoC, there are still a few missing pieces before > this can be merged. Including (but probably not limited to): > > - Consolidate the map definition struct in the bpf_helpers.h file in the > kernel tree. This contains a different, and incompatible, update to > the struct. Since the iproute2 version has actually been released for > use outside the kernel tree (and thus is subject to API stability > constraints), I think it makes the most sense to keep that, and port > the selftests to use it. It sounds like you're implying that existing libbpf format is not uapi. It is and we cannot break it. If patch 1 means breakage for existing pre-compiled .o that won't load with new libbpf then we cannot use this method. Recompiling .o with new libbpf definition of bpf_map_def isn't an option. libbpf has to be smart before/after and recognize both old and iproute2 format.
