bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: "Mauricio Vásquez" <mauricio@kinvolk.io>
Cc: Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	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: Re: [PATCH bpf-next v7 0/7] libbpf: Implement BTFGen
Date: Wed, 16 Feb 2022 10:20:27 -0800	[thread overview]
Message-ID: <CAEf4BzbxcoP8hoHM_1+QX4Nx=F0NPkc-CXDq=H_JkQfc9PAzLQ@mail.gmail.com> (raw)
In-Reply-To: <20220215225856.671072-1-mauricio@kinvolk.io>

On Tue, Feb 15, 2022 at 2:59 PM Mauricio Vásquez <mauricio@kinvolk.io> wrote:
>
> CO-RE requires to have BTF information describing the kernel types 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. 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:
> v6 > v7:
> - use array instead of hashmap to store ids
> - use btf__add_{struct,union}() instead of memcpy()
> - don't use fixed path for testing BTF file
> - update example to use DECLARE_LIBBPF_OPTS()
>
> v5 > v6:
> - use BTF structure to store used member/types instead of hashmaps
> - remove support for input/output folders
> - remove bpf_core_{created,free}_cand_cache()
> - reorganize commits to avoid having unused static functions
> - remove usage of libbpf_get_error()
> - fix some errno propagation issues
> - do not record full types for type-based relocations
> - add support for BTF_KIND_FUNC_PROTO
> - implement tests based on core_reloc ones
>
> v4 > v5:
> - move some checks before invoking prog->obj->gen_loader
> - use p_info() instead of printf()
> - improve command output
> - fix issue with record_relo_core()
> - implement bash completion
> - write man page
> - implement some tests
>
> v3 > v4:
> - parse BTF and BTF.ext sections in bpftool and use
>   bpf_core_calc_relo_insn() directly
> - expose less internal details from libbpf to bpftool
> - implement support for enum-based relocations
> - split commits in a more granular way
>
> 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/
> v3: https://lore.kernel.org/bpf/20211217185654.311609-1-mauricio@kinvolk.io/
> v4: https://lore.kernel.org/bpf/20220112142709.102423-1-mauricio@kinvolk.io/
> v5: https://lore.kernel.org/bpf/20220128223312.1253169-1-mauricio@kinvolk.io/
> v6: https://lore.kernel.org/bpf/20220209222646.348365-1-mauricio@kinvolk.io/
>
> Mauricio Vásquez (6):
>   libbpf: split bpf_core_apply_relo()
>   libbpf: Expose bpf_core_{add,free}_cands() to bpftool
>   bpftool: Add gen min_core_btf command
>   bpftool: Implement "gen min_core_btf" logic
>   bpftool: Implement btfgen_get_btf()
>   selftests/bpf: Test "bpftool gen min_core_btf"
>
> Rafael David Tinoco (1):
>   bpftool: gen min_core_btf explanation and examples
>
>  kernel/bpf/btf.c                              |  13 +-
>  .../bpf/bpftool/Documentation/bpftool-gen.rst |  91 +++
>  tools/bpf/bpftool/Makefile                    |   8 +-
>  tools/bpf/bpftool/bash-completion/bpftool     |   6 +-
>  tools/bpf/bpftool/gen.c                       | 591 +++++++++++++++++-
>  tools/lib/bpf/libbpf.c                        |  88 +--
>  tools/lib/bpf/libbpf_internal.h               |   9 +
>  tools/lib/bpf/relo_core.c                     |  79 +--
>  tools/lib/bpf/relo_core.h                     |  42 +-
>  .../selftests/bpf/prog_tests/core_reloc.c     |  50 +-
>  10 files changed, 864 insertions(+), 113 deletions(-)
>
> --
> 2.25.1
>

Fixed up few things I pointed out in respective patches. Applied to
bpf-next. Great work, congrats!

It would be great as a next step to add this as (probably optional at
first) step for libbpf-tools in BCC repo, so that those CO-RE-based
tools can be used much more widely than today. How much work that
would be, do you think? And how slow would it be to download all those
BTFs and run min_core_btf on all of them?

  parent reply	other threads:[~2022-02-16 18:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15 22:58 Mauricio Vásquez
2022-02-15 22:58 ` [PATCH bpf-next v7 1/7] libbpf: split bpf_core_apply_relo() Mauricio Vásquez
2022-02-16  1:52   ` Alexei Starovoitov
2022-02-15 22:58 ` [PATCH bpf-next v7 2/7] libbpf: Expose bpf_core_{add,free}_cands() to bpftool Mauricio Vásquez
2022-02-15 22:58 ` [PATCH bpf-next v7 3/7] bpftool: Add gen min_core_btf command Mauricio Vásquez
2022-02-15 22:58 ` [PATCH bpf-next v7 4/7] bpftool: Implement "gen min_core_btf" logic Mauricio Vásquez
2022-02-18 16:20   ` Quentin Monnet
2022-02-18 19:43     ` Mauricio Vásquez Bernal
2022-02-18 19:48       ` Andrii Nakryiko
2022-02-18 19:52         ` Quentin Monnet
2022-02-15 22:58 ` [PATCH bpf-next v7 5/7] bpftool: Implement btfgen_get_btf() Mauricio Vásquez
2022-02-16 18:20   ` Andrii Nakryiko
2022-02-15 22:58 ` [PATCH bpf-next v7 6/7] bpftool: gen min_core_btf explanation and examples Mauricio Vásquez
2022-02-16 18:20   ` Andrii Nakryiko
2022-02-15 22:58 ` [PATCH bpf-next v7 7/7] selftests/bpf: Test "bpftool gen min_core_btf" Mauricio Vásquez
2022-02-16 18:20   ` Andrii Nakryiko
2022-02-16 18:20 ` Andrii Nakryiko [this message]
2022-02-17 22:07   ` [PATCH bpf-next v7 0/7] libbpf: Implement BTFGen Mauricio Vásquez Bernal
2022-02-17 22:12     ` Andrii Nakryiko
2022-02-16 18:30 ` patchwork-bot+netdevbpf

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='CAEf4BzbxcoP8hoHM_1+QX4Nx=F0NPkc-CXDq=H_JkQfc9PAzLQ@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --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=mauricio@kinvolk.io \
    --cc=netdev@vger.kernel.org \
    --cc=quentin@isovalent.com \
    --cc=rafaeldtinoco@gmail.com \
    --subject='Re: [PATCH bpf-next v7 0/7] 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).