netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andriin@fb.com>
To: <bpf@vger.kernel.org>, <netdev@vger.kernel.org>, <ast@fb.com>,
	<daniel@iogearbox.net>
Cc: <andrii.nakryiko@gmail.com>, <kernel-team@fb.com>,
	Andrii Nakryiko <andriin@fb.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: [PATCH bpf-next 0/9] libbpf: BTF writer APIs
Date: Wed, 23 Sep 2020 08:54:27 -0700	[thread overview]
Message-ID: <20200923155436.2117661-1-andriin@fb.com> (raw)

This patch set introduces a new set of BTF APIs to libbpf that allow to
conveniently produce BTF types and strings. Internals of struct btf were
changed such that it can transparently and automatically switch to writable
mode, which allows appending BTF types and strings. This will allow for libbpf
itself to do more intrusive modifications of program's BTF (by rewriting it,
at least as of right now), which is necessary for the upcoming libbpf static
linking. But they are complete and generic, so can be adopted by anyone who
has a need to produce BTF type information.

One such example outside of libbpf is pahole, which was actually converted to
these APIs (locally, pending landing of these changes in libbpf) completely
and shows reduction in amount of custom pahole code necessary and brings nice
savings in memory usage (about 370MB reduction at peak for my kernel
configuration) and even BTF deduplication times (one second reduction,
23.7s -> 22.7s). Memory savings are due to avoiding pahole's own copy of
"uncompressed" raw BTF data. Time reduction comes from faster string
search and deduplication by relying on hashmap instead of BST used by pahole's
own code. Consequently, these APIs are already tested on real-world
complicated kernel BTF, but there is also pretty extensive selftest doing
extra validations.

Selftests in patch #9 add a set of generic ASSERT_{EQ,STREQ,ERR,OK} macros
that are useful for writing shorter and less repretitive selftests. I decided
to keep them local to that selftest for now, but if they prove to be useful in
more contexts we should move them to test_progs.h. And few more (e.g.,
inequality tests) macros are probably necessary to have a more complete set.

Cc: Arnaldo Carvalho de Melo <acme@redhat.com>

Andrii Nakryiko (9):
  libbpf: refactor internals of BTF type index
  libbpf: remove assumption of single contiguous memory for BTF data
  libbpf: generalize common logic for managing dynamically-sized arrays
  libbpf: extract generic string hashing function for reuse
  libbpf: allow modification of BTF and add btf__add_str API
  libbpf: add btf__new_empty() to create an empty BTF object
  libbpf: add BTF writing APIs
  libbpf: add btf__str_by_offset() as a more generic variant of
    name_by_offset
  selftests/bpf: test BTF writing APIs

 tools/lib/bpf/bpf.c                           |    2 +-
 tools/lib/bpf/bpf.h                           |    2 +-
 tools/lib/bpf/btf.c                           | 1311 +++++++++++++++--
 tools/lib/bpf/btf.h                           |   41 +
 tools/lib/bpf/btf_dump.c                      |    9 +-
 tools/lib/bpf/hashmap.h                       |   12 +
 tools/lib/bpf/libbpf.map                      |   22 +
 tools/lib/bpf/libbpf_internal.h               |    3 +
 .../selftests/bpf/prog_tests/btf_write.c      |  271 ++++
 9 files changed, 1553 insertions(+), 120 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/btf_write.c

-- 
2.24.1


             reply	other threads:[~2020-09-23 15:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-23 15:54 Andrii Nakryiko [this message]
2020-09-23 15:54 ` [PATCH bpf-next 1/9] libbpf: refactor internals of BTF type index Andrii Nakryiko
2020-09-23 15:54 ` [PATCH bpf-next 2/9] libbpf: remove assumption of single contiguous memory for BTF data Andrii Nakryiko
2020-09-24 15:21   ` John Fastabend
2020-09-24 20:25     ` Andrii Nakryiko
2020-09-23 15:54 ` [PATCH bpf-next 3/9] libbpf: generalize common logic for managing dynamically-sized arrays Andrii Nakryiko
2020-09-23 15:54 ` [PATCH bpf-next 4/9] libbpf: extract generic string hashing function for reuse Andrii Nakryiko
2020-09-23 15:54 ` [PATCH bpf-next 5/9] libbpf: allow modification of BTF and add btf__add_str API Andrii Nakryiko
2020-09-24 15:56   ` John Fastabend
2020-09-24 20:27     ` Andrii Nakryiko
2020-09-23 15:54 ` [PATCH bpf-next 6/9] libbpf: add btf__new_empty() to create an empty BTF object Andrii Nakryiko
2020-09-23 15:54 ` [PATCH bpf-next 7/9] libbpf: add BTF writing APIs Andrii Nakryiko
2020-09-24 15:59   ` John Fastabend
2020-09-25  3:55   ` Alexei Starovoitov
2020-09-25  6:21     ` Andrii Nakryiko
2020-09-25 15:37       ` Alexei Starovoitov
2020-09-25 16:53         ` Andrii Nakryiko
2020-09-23 15:54 ` [PATCH bpf-next 8/9] libbpf: add btf__str_by_offset() as a more generic variant of name_by_offset Andrii Nakryiko
2020-09-23 15:54 ` [PATCH bpf-next 9/9] selftests/bpf: test BTF writing APIs Andrii Nakryiko
2020-09-24 15:16 ` [PATCH bpf-next 0/9] libbpf: BTF writer APIs John Fastabend

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=20200923155436.2117661-1-andriin@fb.com \
    --to=andriin@fb.com \
    --cc=acme@redhat.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).