From: Tianyi Chen <hi@tychen.cc>
To: bpf@vger.kernel.org
Cc: Tianyi Chen <hi@tychen.cc>, Quentin Monnet <qmo@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
Jiri Olsa <jolsa@kernel.org>,
Emil Tsalapatis <emil@etsalapatis.com>,
Ihor Solodrai <ihor.solodrai@linux.dev>,
Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: [PATCH bpf-next 0/2] bpftool: Batch bounded hash map dumps
Date: Mon, 7 Sep 2026 01:08:17 +0800 [thread overview]
Message-ID: <20260906170819.1212661-1-hi@tychen.cc> (raw)
This series uses lookup batches for ordinary hash maps whose maximum
key/value storage fits within a 4 MiB budget. It retains the existing
formatting and falls back to individual lookups if the initial batch
operation is unsupported. Other map types keep individual lookups.
Hash batch lookups need room for a complete bucket, so ENOSPC grows the
buffer without advancing the cursor. The memory eligibility check makes
that growth bounded even after output has begun. Non-ENOENT errors do
not expose untrusted counts or trigger a duplicate dump restart.
Related request:
https://github.com/libbpf/bpftool/issues/63
The series is based on bpf-next and does not depend on my recursive
map-dump series or the flags/ring-buffer series sent alongside it.
Validation on x86-64, Linux 7.3.0-rc1 in KVM, LLVM 20:
- Full bpftool build and focused BPF selftests build.
- All 11 bpftool_map_batch subtests passed against a bpftool built with
only this series: complete unordered plain, JSON and pretty JSON
contents, batch boundaries, short keys, odd-sized values and BTF.
- strace fault injection checked initial EINVAL/EOPNOTSUPP/ENOTSUPP
fallback; ENOSPC growth initially and after progress; fatal EFAULT,
ENOMEM and post-progress EIO/EINVAL; no duplicates and valid JSON.
- A map exceeding the memory eligibility budget used individual lookups.
- On the same static 100,000-entry hash map, BPF syscall counts dropped
from 200,004 to 395. Five untraced runs had median elapsed times of
0.774 s before and 0.734 s after; text formatting still dominates.
Fault injection simulates error returns; it is not a real collision
stress test. Only focused selftests were run. Strict checkpatch has no
errors or checks; the new test file is covered by existing MAINTAINERS
patterns.
Integration check: these three independent series also applied and built
together with my previously posted recursive map-dump v2 series. The
combined 64 subtests passed with no skips or failures in the same guest.
Tianyi Chen (2):
bpftool: Use batch lookups for bounded hash map dumps
selftests/bpf: Check bpftool batch map dump contents
tools/bpf/bpftool/map.c | 113 ++++++++++-
.../bpf/prog_tests/bpftool_map_batch.c | 186 ++++++++++++++++++
2 files changed, 291 insertions(+), 8 deletions(-)
create mode 100644 tools/testing/selftests/bpf/prog_tests/bpftool_map_batch.c
--
2.55.0
next reply other threads:[~2026-09-06 17:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-06 17:08 Tianyi Chen [this message]
2026-09-06 17:08 ` [PATCH bpf-next 1/2] bpftool: Use batch lookups for bounded hash map dumps Tianyi Chen
2026-09-06 17:20 ` sashiko-bot
2026-09-06 18:17 ` bot+bpf-ci
2026-09-06 17:08 ` [PATCH bpf-next 2/2] selftests/bpf: Check bpftool batch map dump contents Tianyi Chen
2026-09-06 17:16 ` sashiko-bot
2026-09-06 18:01 ` bot+bpf-ci
2026-09-07 1:21 ` Tianyi Chen
2026-09-07 1:21 ` [PATCH bpf-next v2 0/2] bpftool: Batch bounded hash map dumps Tianyi Chen
2026-09-07 1:21 ` [PATCH bpf-next v2 1/2] bpftool: Use batch lookups for " Tianyi Chen
2026-09-07 2:21 ` bot+bpf-ci
2026-09-07 5:15 ` Tianyi Chen
2026-09-07 1:21 ` [PATCH bpf-next v2 2/2] selftests/bpf: Check bpftool batch map dump contents Tianyi Chen
2026-09-07 2:21 ` bot+bpf-ci
2026-09-07 5:15 ` Tianyi Chen
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=20260906170819.1212661-1-hi@tychen.cc \
--to=hi@tychen.cc \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=qmo@kernel.org \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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