From 1476ec114145e7610184c7e27d5eb7c42ac3e62f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maciej=20=C5=BBenczykowski?= Date: Thu, 11 Sep 2025 12:09:12 -0700 Subject: [PATCH] BpfMap: lower min allowed batch size MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Vendor/OEM reports of some of their code failing to build due to larger key/value sizes. I'd make this check mainline only, but I can't seem to find a way to actually make that (reliably) work. So let's just lower the minimum from 256 to 64 - this should I think still be enough for significant performance benefits from using bulk operations. Indeed probably even 10 would be enough for that. Bug: 442996907 Test: TreeHugger Flag: EXEMPT mainline/trivial Signed-off-by: Maciej Żenczykowski Change-Id: I69d53293dd5bb2174af7c814f531a08eba590310 --- bpf/headers/include/bpf/BpfMap.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bpf/headers/include/bpf/BpfMap.h b/bpf/headers/include/bpf/BpfMap.h index c247ba23a3..c6cce434a8 100644 --- a/bpf/headers/include/bpf/BpfMap.h +++ b/bpf/headers/include/bpf/BpfMap.h @@ -156,7 +156,7 @@ class BpfMapRO { // ~16KiB initial stack usage seems reasonable static constexpr int BATCHSIZE = 16384 / (sizeof(Key) + sizeof(Value)); - static_assert(BATCHSIZE >= 256, "consider Key/Value size, whether incr mem limit, decr batch req"); + static_assert(BATCHSIZE >= 64, "consider Key/Value size, whether incr mem limit, decr batch req"); static_assert(BATCHSIZE * sizeof(Key) + BATCHSIZE * sizeof(Value) <= 16384); Result doBulkLookupAndMaybeDelete(bool del, const function &f) const { @@ -169,7 +169,7 @@ class BpfMapRO { // is almost always enough for a bucket (which is what you'd expect, it's not a good // hashtable if there's lots of items in a single bucket) // - // Since we start with 256+ we shouldn't ever actually need to increase N... + // Since we start with 64+ we shouldn't ever actually need to increase N... // Also note that the 'true' condition is not really an infinite loop, // as we'll blow up the stack and crash instead of looping infinitely. // But that also shouldn't happen cause it would imply/require a ridiculously