Re: [PATCH bpf-next v4 0/2] bpftool: Batch bounded hash map dumps

[Quentin Monnet <qmo@kernel.org>]

2026-09-11 11:47 UTC+0800 ~ Tianyi Chen <diannaaav@gmail.com>
> Use lookup batches for ordinary hash maps whose maximum key/value
> storage fits within 4 MiB, with selftests for complete output around
> batch boundaries, short keys, odd-sized values and BTF formatting.
> 
> Changes in v4:
> - Name MAP_DUMP_BATCH_FALLBACK at both return sites and the caller,
>   replacing the literal 1 while preserving the existing control flow.
> 
> The helper retains three outcomes: zero for completion, -1 for error,
> and the named fallback result. Internal errno values are normalized
> before return, so EPERM does not escape as the fallback result.
> A separate output parameter is unnecessary for this distinction.
> 
> v3: https://lore.kernel.org/r/20260911025130.191011-1-diannaaav@gmail.com
> Review: https://lore.kernel.org/r/7aea07c4220781305b7e972abfa9d2e4776276a64bc4837b80325d177799a371@mail.kernel.org
> 
> Validation:
> - Rebuilt bpftool, its manual pages and the focused selftest runner.
> - All 11 bpftool_map_batch subtests passed. The three revised series
>   were tested together: 52 subtests passed with no skips or failures in
>   an x86-64 KVM guest running Linux 7.3.0-rc2 from bpf/master, with
>   LLVM 20-built BPF test objects.
> - Bash syntax, bpftool synchronization checks and diff checks passed.
> - The generated patches apply cleanly to current bpf-next.
> 
> This was a focused run. Unrelated selftests requiring unavailable kernel
> features were excluded from the build with PERMISSIVE=1.
> 
> 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                       | 117 ++++++++++-
>  .../bpf/prog_tests/bpftool_map_batch.c        | 187 ++++++++++++++++++
>  2 files changed, 296 insertions(+), 8 deletions(-)
>  create mode 100644 tools/testing/selftests/bpf/prog_tests/bpftool_map_batch.c
> 
> 
> base-commit: af0b84a9215d951d16f26b7ee34353b970cf5d4e


Hi, could you rebase this series please? It doesn't apply cleanly any
more - probably due to my response time, apologies for that.

When you do, can you also please add your performance numbers in the
first patch's description? Speaking of: I'm surprised that the syscall
reduction you mentioned (200,004 to 395) results in a 5% perf
improvement, I suppose we spend a lot of time writing to stdout. Could
you please try re-running your performance test, redirecting the output
to /dev/null?

Thanks,
Quentin