From: "Mauricio Vásquez" <mauricio@kinvolk.io> To: netdev@vger.kernel.org, bpf@vger.kernel.org Cc: Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>, Quentin Monnet <quentin@isovalent.com>, Rafael David Tinoco <rafaeldtinoco@gmail.com>, Lorenzo Fontana <lorenzo.fontana@elastic.co>, Leonardo Di Donato <leonardo.didonato@elastic.co> Subject: [PATCH bpf-next v3 0/3] libbpf: Implement BTFGen Date: Fri, 17 Dec 2021 13:56:51 -0500 [thread overview] Message-ID: <20211217185654.311609-1-mauricio@kinvolk.io> (raw) CO-RE requires to have BTF information describing the types of the kernel in order to perform the relocations. This is usually provided by the kernel itself when it's configured with CONFIG_DEBUG_INFO_BTF. However, this configuration is not enabled in all the distributions and it's not available on kernels before 5.12. It's possible to use CO-RE in kernels without CONFIG_DEBUG_INFO_BTF support by providing the BTF information from an external source. BTFHub[0] contains BTF files to each released kernel not supporting BTF, for the most popular distributions. Providing this BTF file for a given kernel has some challenges: 1. Each BTF file is a few MBs big, then it's not possible to ship the eBPF program with all the BTF files needed to run in different kernels. (The BTF files will be in the order of GBs if you want to support a high number of kernels) 2. Downloading the BTF file for the current kernel at runtime delays the start of the program and it's not always possible to reach an external host to download such a file. Providing the BTF file with the information about all the data types of the kernel for running an eBPF program is an overkill in many of the cases. Usually the eBPF programs access only some kernel fields. This series implements BTFGen support in bpftool by exposing some of the internal libbpf's APIs to it. This idea was discussed during the "Towards truly portable eBPF"[1] presentation at Linux Plumbers 2021. There is a good example[2] on how to use BTFGen and BTFHub together to generate multiple BTF files, to each existing/supported kernel, tailored to one application. For example: a complex bpf object might support nearly 400 kernels by having BTF files summing only 1.5 MB. [0]: https://github.com/aquasecurity/btfhub/ [1]: https://www.youtube.com/watch?v=igJLKyP1lFk&t=2418s [2]: https://github.com/aquasecurity/btfhub/tree/main/tools Changelog: v2 > v3: - expose internal libbpf APIs to bpftool instead - implement btfgen in bpftool - drop btf__raw_data() from libbpf v1 > v2: - introduce bpf_object__prepare() and ‘record_core_relos’ to expose CO-RE relocations instead of bpf_object__reloc_info_gen() - rename btf__save_to_file() to btf__raw_data() v1: https://lore.kernel.org/bpf/20211027203727.208847-1-mauricio@kinvolk.io/ v2: https://lore.kernel.org/bpf/20211116164208.164245-1-mauricio@kinvolk.io/ Mauricio Vásquez (3): libbpf: split bpf_core_apply_relo() libbpf: Implement changes needed for BTFGen in bpftool bpftool: Implement btfgen kernel/bpf/btf.c | 11 +- tools/bpf/bpftool/gen.c | 892 ++++++++++++++++++++++++++++++++ tools/lib/bpf/Makefile | 2 +- tools/lib/bpf/libbpf.c | 124 +++-- tools/lib/bpf/libbpf.h | 3 + tools/lib/bpf/libbpf.map | 2 + tools/lib/bpf/libbpf_internal.h | 22 + tools/lib/bpf/relo_core.c | 83 +-- tools/lib/bpf/relo_core.h | 46 +- 9 files changed, 1086 insertions(+), 99 deletions(-) -- 2.25.1
next reply other threads:[~2021-12-17 18:57 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-17 18:56 Mauricio Vásquez [this message] 2021-12-17 18:56 ` [PATCH bpf-next v3 1/3] libbpf: split bpf_core_apply_relo() Mauricio Vásquez 2021-12-23 0:33 ` Andrii Nakryiko 2022-01-12 14:26 ` Mauricio Vásquez Bernal 2021-12-17 18:56 ` [PATCH bpf-next v3 2/3] libbpf: Implement changes needed for BTFGen in bpftool Mauricio Vásquez 2021-12-23 0:33 ` Andrii Nakryiko 2022-01-12 14:26 ` Mauricio Vásquez Bernal 2021-12-17 18:56 ` [PATCH bpf-next v3 3/3] bpftool: Implement btfgen Mauricio Vásquez 2021-12-23 0:33 ` Andrii Nakryiko 2022-01-12 14:26 ` Mauricio Vásquez Bernal 2021-12-17 23:11 ` [PATCH bpf-next v3 0/3] libbpf: Implement BTFGen Daniel Borkmann 2021-12-20 22:43 ` Mauricio Vásquez Bernal
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20211217185654.311609-1-mauricio@kinvolk.io \ --to=mauricio@kinvolk.io \ --cc=andrii@kernel.org \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=daniel@iogearbox.net \ --cc=leonardo.didonato@elastic.co \ --cc=lorenzo.fontana@elastic.co \ --cc=netdev@vger.kernel.org \ --cc=quentin@isovalent.com \ --cc=rafaeldtinoco@gmail.com \ --subject='Re: [PATCH bpf-next v3 0/3] libbpf: Implement BTFGen' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).