Re: [PATCH bpf-next 3/4] selftests/bpf: Cap batch-timing calibration at BPF may_goto loop limit

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The new CALIBRATE_MAX_BATCH cap of 8,000,000 is mathematically incorrect and fails the patch's stated goal of keeping the benchmark within the BPF may_goto limit.
--

commit d9779455687fa035b58a0d4ba0d495256b32ed13
Author: Puranjay Mohan <puranjay@kernel.org>

selftests/bpf: Cap batch-timing calibration at BPF may_goto loop limit

This commit lowers CALIBRATE_MAX_BATCH from 10000000 to 8000000. This
is intended to keep the benchmark iterations within the BPF_MAX_LOOPS
limit of 8388608, avoiding early loop exits that cause underestimated
costs.

> diff --git a/tools/testing/selftests/bpf/benchs/bench_bpf_timing.c b/tools/testing/selftests/bpf/benchs/bench_bpf_timing.c
> index 75a39da696552..081e2e860cb49 100644
> --- a/tools/testing/selftests/bpf/benchs/bench_bpf_timing.c
> +++ b/tools/testing/selftests/bpf/benchs/bench_bpf_timing.c
> @@ -166,7 +166,7 @@ void bpf_bench_timing_report(struct bpf_bench_timing *t, const char *name, const
>  
>  #define CALIBRATE_SEED_BATCH	100
>  #define CALIBRATE_MIN_BATCH	100
> -#define CALIBRATE_MAX_BATCH	10000000
> +#define CALIBRATE_MAX_BATCH	8000000

[Severity: Medium]
Will this new cap of 8000000 still cause the benchmark to hit the BPF
may_goto limit during calibration?

Looking at bpf_bench_calibrate(), the proportionality check explicitly
requests a measurement of t->batch_iters * 2:

	time_n = measure_elapsed(t, run_fn, run_ctx, t->batch_iters, CALIBRATE_RUNS);
	time_2n = measure_elapsed(t, run_fn, run_ctx, t->batch_iters * 2, CALIBRATE_RUNS);

With a cap of 8000000, t->batch_iters * 2 can reach up to 16000000
iterations. Since this exceeds the BPF_MAX_LOOPS limit of 8388608,
won't the BPF program's can_loop condition return false early during the
time_2n measurement?

This would cause time_2n to record the time for only ~8.38M iterations
instead of 16M. When compared to time_n (8M iterations), the ratio would
be ~1.05 instead of the expected 2.0. This completely violates the 5%
PROPORTIONALITY_TOL and triggers a bogus proportionality check warning
for fast benchmarks.

To safely avoid the limit across all phases of calibration, shouldn't the
cap be no more than BPF_MAX_LOOPS / 2 (e.g., 4000000)?

>  #define CALIBRATE_TARGET_MS	10
>  #define CALIBRATE_RUNS		5
>  #define PROPORTIONALITY_TOL	0.05	/* 5% */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519163632.2220753-1-puranjay@kernel.org?part=3