From: sashiko-bot@kernel.org
To: "Puranjay Mohan" <puranjay@kernel.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 1/4] selftests/bpf: Fix cold_lru producing zero batch_hash in XDP LB benchmark
Date: Tue, 19 May 2026 16:51:39 +0000 [thread overview]
Message-ID: <20260519165140.12529C2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <20260519163632.2220753-2-puranjay@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The fix for zero `batch_hash` introduces a regression in the `cold_lru` benchmark by destroying the lowest bit of entropy, causing 50% of consecutive batches to generate identical hashes.
--
commit d60966744103a5bacba48698e7e96189a24c69c1
Author: Puranjay Mohan <puranjay@kernel.org>
selftests/bpf: Fix cold_lru producing zero batch_hash in XDP LB benchmark
This commit addresses an issue in the cold_lru benchmark where a batch_hash
of zero causes the benchmark to incorrectly hit warm LRU entries. It attempts
to fix this by bitwise-ORing the input to the hash multiplier with 1.
> diff --git a/tools/testing/selftests/bpf/progs/xdp_lb_bench.c b/tools/testing/selftests/bpf/progs/xdp_lb_bench.c
> --- a/tools/testing/selftests/bpf/progs/xdp_lb_bench.c
> +++ b/tools/testing/selftests/bpf/progs/xdp_lb_bench.c
> @@ -618,7 +618,7 @@ int xdp_lb_bench(struct xdp_md *xdp)
> __u32 *saddr = data + saddr_off;
>
> batch_gen++;
> - batch_hash = (batch_gen ^ bpf_get_smp_processor_id()) * KNUTH_HASH_MULT;
> + batch_hash = ((batch_gen ^ bpf_get_smp_processor_id()) | 1) * KNUTH_HASH_MULT;
[Severity: Medium]
Does this code introduce a regression where using | 1 inadvertently destroys
the lowest bit of entropy from the batch generator?
Since batch_gen increments sequentially by 1 per batch execution, forcing
the least significant bit to 1 maps pairs of adjacent values to the same
number. For example, if the CPU ID evaluates to 0, both batch_gen = 2 and
batch_gen = 3 will yield 3 before the multiplication.
Could this cause 50% of consecutive batches to generate the exact same
batch_hash as the previous batch, causing those iterations to hit the warm
LRU cache entries that were just populated and defeating the purpose of
the cold_lru benchmark?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260519163632.2220753-1-puranjay@kernel.org?part=1
next prev parent reply other threads:[~2026-05-19 16:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 16:36 [PATCH bpf-next 0/4] selftests/bpf: XDP LB benchmark fixes Puranjay Mohan
2026-05-19 16:36 ` [PATCH bpf-next 1/4] selftests/bpf: Fix cold_lru producing zero batch_hash in XDP LB benchmark Puranjay Mohan
2026-05-19 16:51 ` sashiko-bot [this message]
2026-05-19 17:14 ` bot+bpf-ci
2026-05-19 19:25 ` Puranjay Mohan
2026-05-19 16:36 ` [PATCH bpf-next 2/4] selftests/bpf: Fix expired UDP LRU entries " Puranjay Mohan
2026-05-19 16:36 ` [PATCH bpf-next 3/4] selftests/bpf: Cap batch-timing calibration at BPF may_goto loop limit Puranjay Mohan
2026-05-19 17:19 ` sashiko-bot
2026-05-19 19:10 ` Alexei Starovoitov
2026-05-19 19:23 ` Puranjay Mohan
2026-05-19 16:36 ` [PATCH bpf-next 4/4] selftests/bpf: Filter timing outliers with IQR in batch-timing library Puranjay Mohan
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=20260519165140.12529C2BCB3@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=puranjay@kernel.org \
--cc=sashiko-reviews@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.