Message ID | 20201023033855.3894509-1-haliu@redhat.com |
---|---|
Headers | show |
Series | iproute2: add libbpf support | expand |
On Wed, Oct 28, 2020 at 09:25:24PM +0800, Hangbin Liu wrote: > This series converts iproute2 to use libbpf for loading and attaching > BPF programs when it is available. This means that iproute2 will > correctly process BTF information and support the new-style BTF-defined > maps, while keeping compatibility with the old internal map definition > syntax. > > This is achieved by checking for libbpf at './configure' time, and using > it if available. By default the system libbpf will be used, but static > linking against a custom libbpf version can be achieved by passing > LIBBPF_DIR to configure. FORCE_LIBBPF can be set to force configure to > abort if no suitable libbpf is found (useful for automatic packaging > that wants to enforce the dependency). > > The old iproute2 bpf code is kept and will be used if no suitable libbpf > is available. When using libbpf, wrapper code ensures that iproute2 will > still understand the old map definition format, including populating > map-in-map and tail call maps before load. > > The examples in bpf/examples are kept, and a separate set of examples > are added with BTF-based map definitions for those examples where this > is possible (libbpf doesn't currently support declaratively populating > tail call maps). Awesome to see this work continue! Thank you.
On Fri, 23 Oct 2020 11:38:50 +0800 Hangbin Liu <haliu@redhat.com> wrote: > This series converts iproute2 to use libbpf for loading and attaching > BPF programs when it is available. This means that iproute2 will > correctly process BTF information and support the new-style BTF-defined > maps, while keeping compatibility with the old internal map definition > syntax. > > This is achieved by checking for libbpf at './configure' time, and using > it if available. By default the system libbpf will be used, but static > linking against a custom libbpf version can be achieved by passing > LIBBPF_DIR to configure. FORCE_LIBBPF can be set to force configure to > abort if no suitable libbpf is found (useful for automatic packaging > that wants to enforce the dependency). > > The old iproute2 bpf code is kept and will be used if no suitable libbpf > is available. When using libbpf, wrapper code ensures that iproute2 will > still understand the old map definition format, including populating > map-in-map and tail call maps before load. > > The examples in bpf/examples are kept, and a separate set of examples > are added with BTF-based map definitions for those examples where this > is possible (libbpf doesn't currently support declaratively populating > tail call maps). Luca wants to put this in Debian 11 (good idea), but that means: 1. It has to work with 5.10 release and kernel. 2. Someone has to test it. 3. The 5.10 is a LTS kernel release which means BPF developers have to agree to supporting LTS releases. If someone steps up to doing this then I would be happy to merge it now for 5.10. Otherwise it won't show up until 5.11.
On Sat, Nov 28, 2020 at 10:16:35PM -0800, Stephen Hemminger wrote: > On Fri, 23 Oct 2020 11:38:50 +0800 > Hangbin Liu <haliu@redhat.com> wrote: > > > This series converts iproute2 to use libbpf for loading and attaching > > BPF programs when it is available. This means that iproute2 will > > correctly process BTF information and support the new-style BTF-defined > > maps, while keeping compatibility with the old internal map definition > > syntax. > > > > This is achieved by checking for libbpf at './configure' time, and using > > it if available. By default the system libbpf will be used, but static > > linking against a custom libbpf version can be achieved by passing > > LIBBPF_DIR to configure. FORCE_LIBBPF can be set to force configure to > > abort if no suitable libbpf is found (useful for automatic packaging > > that wants to enforce the dependency). > > > > The old iproute2 bpf code is kept and will be used if no suitable libbpf > > is available. When using libbpf, wrapper code ensures that iproute2 will > > still understand the old map definition format, including populating > > map-in-map and tail call maps before load. > > > > The examples in bpf/examples are kept, and a separate set of examples > > are added with BTF-based map definitions for those examples where this > > is possible (libbpf doesn't currently support declaratively populating > > tail call maps). > > > Luca wants to put this in Debian 11 (good idea), but that means: > > 1. It has to work with 5.10 release and kernel. > 2. Someone has to test it. > 3. The 5.10 is a LTS kernel release which means BPF developers have > to agree to supporting LTS releases. Why would the bpf developers have to support any old releases? That's not their responsibility, that's the developers who want to create stable/lts releases. > If someone steps up to doing this then I would be happy to merge it now > for 5.10. Otherwise it won't show up until 5.11. Don't ever "rush" anything for a LTS/stable release, otherwise I am going to have to go back to the old way of not announcing them until _after_ they are released as people throw stuff that is not ready for a normal merge. This looks like a new feature, and shouldn't go in right now in the development cycle anyway, all features for 5.10 had to be in linux-next before 5.9 was released. thanks, greg k-h
On Sat, Nov 28, 2020 at 10:16 PM Stephen Hemminger <stephen@networkplumber.org> wrote: > > On Fri, 23 Oct 2020 11:38:50 +0800 > Hangbin Liu <haliu@redhat.com> wrote: > > > This series converts iproute2 to use libbpf for loading and attaching > > BPF programs when it is available. This means that iproute2 will > > correctly process BTF information and support the new-style BTF-defined > > maps, while keeping compatibility with the old internal map definition > > syntax. > > > > This is achieved by checking for libbpf at './configure' time, and using > > it if available. By default the system libbpf will be used, but static > > linking against a custom libbpf version can be achieved by passing > > LIBBPF_DIR to configure. FORCE_LIBBPF can be set to force configure to > > abort if no suitable libbpf is found (useful for automatic packaging > > that wants to enforce the dependency). > > > > The old iproute2 bpf code is kept and will be used if no suitable libbpf > > is available. When using libbpf, wrapper code ensures that iproute2 will > > still understand the old map definition format, including populating > > map-in-map and tail call maps before load. > > > > The examples in bpf/examples are kept, and a separate set of examples > > are added with BTF-based map definitions for those examples where this > > is possible (libbpf doesn't currently support declaratively populating > > tail call maps). > > > Luca wants to put this in Debian 11 (good idea), but that means: > > 1. It has to work with 5.10 release and kernel. > 2. Someone has to test it. > 3. The 5.10 is a LTS kernel release which means BPF developers have > to agree to supporting LTS releases. That must be a bad joke. You did the opposite of what we asked. You folks are on your own. 5.10, 5.11 whatever release. When angry users come with questions about random behavior you'll be answering them. Not us.
On 11/28/20 11:16 PM, Stephen Hemminger wrote: > Luca wants to put this in Debian 11 (good idea), but that means: > > 1. It has to work with 5.10 release and kernel. > 2. Someone has to test it. > 3. The 5.10 is a LTS kernel release which means BPF developers have > to agree to supporting LTS releases. > > If someone steps up to doing this then I would be happy to merge it now > for 5.10. Otherwise it won't show up until 5.11. It would be good for Bullseye to have the option to use libbpf with iproute2. If Debian uses the 5.10 kernel then it should use the 5.10 version of iproute2 and 5.10 version libbpf. All the components align with consistent versioning. I have some use cases I can move from bpftool loading to iproute2 as additional testing to what Hangbin has already done. If that goes well, I can re-send the patch series against iproute2-main branch by next weekend. It would be good for others (Jesper, Toke, Jiri) to run their own testing as well.
David Ahern <dsahern@gmail.com> writes: > On 11/28/20 11:16 PM, Stephen Hemminger wrote: >> Luca wants to put this in Debian 11 (good idea), but that means: >> >> 1. It has to work with 5.10 release and kernel. >> 2. Someone has to test it. >> 3. The 5.10 is a LTS kernel release which means BPF developers have >> to agree to supporting LTS releases. >> >> If someone steps up to doing this then I would be happy to merge it now >> for 5.10. Otherwise it won't show up until 5.11. > > It would be good for Bullseye to have the option to use libbpf with > iproute2. If Debian uses the 5.10 kernel then it should use the 5.10 > version of iproute2 and 5.10 version libbpf. All the components align > with consistent versioning. > > I have some use cases I can move from bpftool loading to iproute2 as > additional testing to what Hangbin has already done. If that goes well, > I can re-send the patch series against iproute2-main branch by next weekend. This is fine by me - there's nothing in the iproute2 patches that depends on any particular version of libbpf newer than 0.1.0 (that was the whole point), so it's just a matter of when you guys want to merge it. > It would be good for others (Jesper, Toke, Jiri) to run their own > testing as well. I'll do some manual testing, and once we get this into RHEL it'll be part of automated testing there as well. The latter may take a while, though, so don't count on it for any initial verification... -Toke
On Sun, Nov 29, 2020 at 07:22:54AM +0100, Greg KH wrote: > On Sat, Nov 28, 2020 at 10:16:35PM -0800, Stephen Hemminger wrote: > > > If someone steps up to doing this then I would be happy to merge it now > > for 5.10. Otherwise it won't show up until 5.11. > > Don't ever "rush" anything for a LTS/stable release, otherwise I am > going to have to go back to the old way of not announcing them until > _after_ they are released as people throw stuff that is not ready for > a normal merge. > > This looks like a new feature, and shouldn't go in right now in the > development cycle anyway, all features for 5.10 had to be in linux-next > before 5.9 was released. From the context, I believe Stephen meant merging into iproute2 5.10, not kernel. Michal Kubecek
On Sun, 29 Nov 2020 12:41:49 -0700 David Ahern <dsahern@gmail.com> wrote: > On 11/28/20 11:16 PM, Stephen Hemminger wrote: > > Luca wants to put this in Debian 11 (good idea), but that means: > > > > 1. It has to work with 5.10 release and kernel. > > 2. Someone has to test it. > > 3. The 5.10 is a LTS kernel release which means BPF developers have > > to agree to supporting LTS releases. > > > > If someone steps up to doing this then I would be happy to merge it now > > for 5.10. Otherwise it won't show up until 5.11. > > It would be good for Bullseye to have the option to use libbpf with > iproute2. If Debian uses the 5.10 kernel then it should use the 5.10 > version of iproute2 and 5.10 version libbpf. All the components align > with consistent versioning. > > I have some use cases I can move from bpftool loading to iproute2 as > additional testing to what Hangbin has already done. If that goes well, > I can re-send the patch series against iproute2-main branch by next weekend. > > It would be good for others (Jesper, Toke, Jiri) to run their own > testing as well. I have tested this on a Ubuntu 20.04.1 LTS. I had to compile tc my own "old" version (based it on iproute2 git tree), because Ubuntu vendor tc util version didn't even support loading BPF-ELF objects... weird! Copy-pasted by compile instruction below signature (including one failure, that people can find via Google search). I tested difference combinations old vs. new loader with map pinning and reuse of maps (as instructed by Toke over IRC), all the cases worked. I took it one step further and implemented tc libbpf detection: https://github.com/netoptimizer/bpf-examples/commit/048c960756eb65 So, my EDT-pacing code[1] now support BTF-maps, via configure detection and code gets compiled with support, which allows me to inspect the content really easily (data from production system): $ bpftool map lookup id 1351 key 0x10 0x0 0x0 0x0 { "key": 16, "value": { "rate": 0, "t_last": 3299496947649930, "t_horizon_drop": 0, "t_horizon_ecn": 0, "codel": { "first_above_time": 3299496641781522, "drop_next": 3299497041788432, "count": 9, "dropping": 1 } } } [1] https://github.com/netoptimizer/bpf-examples/tree/master/traffic-pacing-edt - - Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer Very recently iproute2 got support for using libbpf as BPF-ELF loader. Testing this on Ubuntu 20.04.1 LTS. Currently avail is iproute2-next tree: - https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/ - git clone git://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git First get libbpf: git clone https://github.com/libbpf/libbpf.git cd libbpf Build libbpf and install it locally: cd ~/git/libbpf/ mkdir build cd ~/git/libbpf/src DESTDIR=../build make install DESTDIR=../build make install_headers Attempt#1: Try to get iproute2 compiling against: cd ~/git/iproute2-next $ LIBBPF_DIR=../libbpf/build/ ./configure TC schedulers ATM no libc has setns: yes SELinux support: no libbpf support: yes libbpf version 0.3.0 ELF support: yes libmnl support: yes Berkeley DB: no need for strlcpy: no libcap support: no Make fails: $ make lib CC bpf_libbpf.o bpf_libbpf.c:20:10: fatal error: bpf/libbpf.h: No such file or directory 20 | #include <bpf/libbpf.h> | ^~~~~~~~~~~~~~ compilation terminated. The problem is use of "relative path" in LIBBPF_DIR (../libbpf/build/), as the Makefile enter subdir 'lib' and have these include path CFLAGS: CFLAGS += -DHAVE_LIBBPF -I../libbpf/build//usr/include Attempt#2 works: Try to get iproute2 compiling against: cd ~/git/iproute2-next $ LIBBPF_DIR=~/git/libbpf/build/ ./configure make Install as stow version: export STOW=/usr/local/stow/iproute2-libbpf-next-git-c29f65db34 make make PREFIX=$STOW SYSCONFDIR=$STOW CONFDIR=$STOW/etc/iproute2 SBINDIR=$STOW/sbin -n install make PREFIX=$STOW SYSCONFDIR=$STOW CONFDIR=$STOW/etc/iproute2 SBINDIR=$STOW/sbin install Current state: $ tc -V tc utility, iproute2-5.9.0, libbpf 0.3.0