From: sashiko-bot@kernel.org
To: "Puranjay Mohan" <puranjay@kernel.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 2/7] selftests/bpf: Add BPF batch-timing library
Date: Tue, 28 Apr 2026 00:12:53 +0000 [thread overview]
Message-ID: <20260428001253.E5EDCC19425@smtp.kernel.org> (raw)
In-Reply-To: <20260427232313.1582588-3-puranjay@kernel.org>
Sashiko AI review found 4 potential issue(s):
- [Medium] Integer division truncation in `bpf_bench_calibrate()` breaks auto-calibration for very fast BPF programs.
- [Medium] Zero warmup time (`-w 0`) causes the benchmark to silently collect no samples.
- [Medium] BPF `can_loop` (`bpf_may_goto`) can prematurely terminate the timed loop, silently invalidating the userspace `ns/op` calculation.
- [Low] The BPF header includes a non-existent file `<bpf_may_goto.h>`.
--
commit ecbc1ddd2ab895fa706970f55f150bb87ba2790e
Author: Puranjay Mohan <puranjay@kernel.org>
selftests/bpf: Add BPF batch-timing library
This commit adds a reusable timing library for BPF benchmarks that need to
measure BPF program execution time. It provides a BPF macro to record elapsed
time and a userspace library to auto-calibrate batch iterations and compute
statistics.
> diff --git a/tools/testing/selftests/bpf/benchs/bench_bpf_timing.c b/tools/testing/selftests/bpf/benchs/bench_bpf_timing.c
> new file mode 100644
> index 000000000000..75a39da69655
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/benchs/bench_bpf_timing.c
[ ... ]
> +static int collect_samples(struct bpf_bench_timing *t,
> + double *out, int max_out)
> +{
> + unsigned int nr_cpus = bpf_num_possible_cpus();
> + __u32 timed_iters = t->batch_iters;
> + int total = 0;
[ ... ]
> + for (__u32 i = 0; i < count && total < max_out; i++) {
> + __u64 sample = t->samples[cpu][i];
> +
> + if (sample == 0)
> + continue;
> + out[total++] = (double)sample / timed_iters;
If the loop in BENCH_BPF_LOOP is terminated early by the can_loop condition
(e.g., due to instruction limits or yielding), the actual number of completed
iterations will be less than timed_iters.
Since the BPF program only records the elapsed time, will dividing by
timed_iters produce artificially low ns/op calculations?
Should the BPF program explicitly record and export the actual number of
completed iterations for this calculation?
> + }
> + }
> +
> + qsort(out, total, sizeof(double), cmp_double);
> + return total;
> +}
[ ... ]
> +void bpf_bench_timing_measure(struct bpf_bench_timing *t, struct bench_res *res)
> +{
> + unsigned int nr_cpus;
> + __u32 total_samples;
> + int i;
> +
> + t->warmup_ticks++;
> +
> + if (t->warmup_ticks < env.warmup_sec)
> + return;
> +
> + if (t->warmup_ticks == env.warmup_sec) {
> + *t->timing_enabled = 1;
> + return;
> + }
If the benchmark is run with zero warmup (env.warmup_sec == 0),
t->warmup_ticks becomes 1 on the first tick.
Does this mean t->warmup_ticks == env.warmup_sec will never be true, bypassing
the assignment and preventing timing_enabled from ever being set to 1?
[ ... ]
> +void bpf_bench_calibrate(struct bpf_bench_timing *t, bpf_bench_run_fn run_fn, void *run_ctx)
> +{
> + __u64 elapsed, per_op_ns;
> + __u64 time_n, time_2n;
> + double ratio;
> +
> + elapsed = measure_elapsed(t, run_fn, run_ctx, CALIBRATE_SEED_BATCH, CALIBRATE_RUNS);
> + if (elapsed == 0) {
> + fprintf(stderr, "calibration: no timing samples, using default\n");
> + t->batch_iters = 10000;
> + *t->batch_iters_bss = t->batch_iters;
> + reset_timing(t);
> + return;
> + }
> +
> + per_op_ns = elapsed / CALIBRATE_SEED_BATCH;
If the BPF operation executes in less than 1 ns (e.g., an empty loop or
bpf-nop), elapsed could be less than 100 since CALIBRATE_SEED_BATCH is 100.
Will the integer division truncate per_op_ns to 0 here, causing
compute_batch_iters() to incorrectly fall back to CALIBRATE_MIN_BATCH instead
of scaling up the iterations?
> + t->batch_iters = compute_batch_iters(per_op_ns);
[ ... ]
> diff --git a/tools/testing/selftests/bpf/progs/bench_bpf_timing.bpf.h b/tools/testing/selftests/bpf/progs/bench_bpf_timing.bpf.h
> new file mode 100644
> index 000000000000..6a1ad75f1fd7
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/bench_bpf_timing.bpf.h
> @@ -0,0 +1,69 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (c) 2026 Meta Platforms, Inc. and affiliates. */
> +
> +#ifndef __BENCH_BPF_TIMING_BPF_H__
> +#define __BENCH_BPF_TIMING_BPF_H__
> +
> +#include <stdbool.h>
> +#include <linux/bpf.h>
> +#include <bpf/bpf_helpers.h>
> +#include <bpf_may_goto.h>
Does bpf_may_goto.h exist in the kernel source tree?
I noticed that can_loop is typically defined in bpf_experimental.h. Will
including this cause a No such file or directory build error?
> +
> +#ifndef BENCH_NR_SAMPLES
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260427232313.1582588-1-puranjay@kernel.org?part=2
next prev parent reply other threads:[~2026-04-28 0:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 23:22 [PATCH bpf-next 0/7] selftests/bpf: Add XDP load-balancer benchmark Puranjay Mohan
2026-04-27 23:22 ` [PATCH bpf-next 1/7] selftests/bpf: Add bench_force_done() for early benchmark completion Puranjay Mohan
2026-04-27 23:39 ` sashiko-bot
2026-04-28 0:05 ` bot+bpf-ci
2026-04-28 9:15 ` Puranjay Mohan
2026-04-27 23:22 ` [PATCH bpf-next 2/7] selftests/bpf: Add BPF batch-timing library Puranjay Mohan
2026-04-28 0:12 ` sashiko-bot [this message]
2026-04-28 0:18 ` bot+bpf-ci
2026-04-28 9:23 ` Puranjay Mohan
2026-04-27 23:23 ` [PATCH bpf-next 3/7] selftests/bpf: Add bpf-nop benchmark for timing overhead baseline Puranjay Mohan
2026-04-27 23:23 ` [PATCH bpf-next 4/7] selftests/bpf: Add XDP load-balancer common definitions Puranjay Mohan
2026-04-28 0:05 ` bot+bpf-ci
2026-04-28 0:38 ` sashiko-bot
2026-04-28 9:29 ` Puranjay Mohan
2026-04-27 23:23 ` [PATCH bpf-next 5/7] selftests/bpf: Add XDP load-balancer BPF program Puranjay Mohan
2026-04-28 0:18 ` bot+bpf-ci
2026-04-28 1:05 ` sashiko-bot
2026-04-28 9:30 ` Puranjay Mohan
2026-04-27 23:23 ` [PATCH bpf-next 6/7] selftests/bpf: Add XDP load-balancer benchmark driver Puranjay Mohan
2026-04-28 0:05 ` bot+bpf-ci
2026-04-28 1:29 ` sashiko-bot
2026-04-28 9:33 ` Puranjay Mohan
2026-04-27 23:23 ` [PATCH bpf-next 7/7] selftests/bpf: Add XDP load-balancer benchmark run script Puranjay Mohan
2026-04-28 2:03 ` sashiko-bot
2026-05-11 22:58 ` [PATCH bpf-next 0/7] selftests/bpf: Add XDP load-balancer benchmark Alexei Starovoitov
2026-05-12 12:48 ` Puranjay Mohan
2026-05-11 23:00 ` 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=20260428001253.E5EDCC19425@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=puranjay@kernel.org \
--cc=sashiko@lists.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.