Re: [PATCH bpf-next 5/7] selftests/bpf: Add XDP load-balancer BPF program

bot+bpf-ci
2026-04-28T00:18:19Z

[-- Attachment #1: Type: text/plain, Size: 2786 bytes --]

> diff --git a/tools/testing/selftests/bpf/progs/xdp_lb_bench.c b/tools/testing/selftests/bpf/progs/xdp_lb_bench.c
> new file mode 100644
> index 000000000000..b9fd848c035d
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/xdp_lb_bench.c
> @@ -0,0 +1,647 @@

[ ... ]

> +SEC("xdp")
> +int xdp_lb_bench(struct xdp_md *xdp)
> +{
> + void *data = (void *)(long)xdp->data;
> + void *data_end = (void *)(long)xdp->data_end;
> + struct ethhdr *eth = data;
> + struct ethhdr saved_eth;
> + __u32 rand_state = 0;
> + __u32 batch_hash = 0;
> + int saddr_off = 0;
> + bool is_v6;
> +
> + if (eth + 1 > data_end)
> + return XDP_DROP;
> +
> + __builtin_memcpy(&saved_eth, eth, sizeof(saved_eth));
> +
> + is_v6 = (saved_eth.h_proto == bpf_htons(ETH_P_IPV6));
> +
> + saddr_off = sizeof(struct ethhdr) + (is_v6 ? offsetof(struct ipv6hdr, saddr) :
> + offsetof(struct iphdr, saddr));
> +
> + if (flow_mask)
> + rand_state = bpf_get_prandom_u32() | 1;
> +
> + if (cold_lru) {
> + __u32 *saddr = data + saddr_off;
> +
> + batch_gen++;
> + batch_hash = (batch_gen ^ bpf_get_smp_processor_id()) * KNUTH_HASH_MULT;
> + if ((void *)(saddr + 1) <= data_end)
> + *saddr ^= batch_hash;
> + }
> +
> + return BENCH_BPF_LOOP(
> + process_packet(xdp),
> + ({
> + if (__bench_result == XDP_TX) {
> + if (strip_encap(xdp, &saved_eth))
> + return XDP_DROP;
> + if (rand_state)
> + randomize_src(xdp, saddr_off, &rand_state);
> + }
> + if (cold_lru) {
> + void *d = (void *)(long)xdp->data;
> + void *de = (void *)(long)xdp->data_end;
> + __u32 *__sa = d + saddr_off;
> +
> + if ((void *)(__sa + 1) <= de)
> + *__sa ^= batch_hash;
^^^^

Does the cold_lru simulation actually generate the intended cache misses?

Inside BENCH_BPF_LOOP, the source IP address is XORed with the constant
batch_hash value on every iteration. Since batch_hash does not change
within the loop, this XOR operation will toggle the IP address between
only two unique values.

If the LRU cache is sized to hold both IP addresses, after the first two
iterations the system will continuously hit cached entries rather than
experiencing the cache misses that the cold_lru simulation is intended to
produce.

Would using a different random or incrementing value for each iteration
ensure a continuous stream of unique addresses?

This concern was raised by sashiko-bot in the RFC v1 patch series but
remains unaddressed in v2.

> + }
> + })
> + );
> +}
> +
> +char _license[] SEC("license") = "GPL";

---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25025533577