joy/android_packages_modules_Connectivity
Watch
1
Fork
You've already forked android_packages_modules_Connectivity
 0
Code Issues Pull requests Projects Releases Wiki Activity

BpfMap: lower min allowed batch size

Browse source 
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 <maze@google.com>
Change-Id: I69d53293dd5bb2174af7c814f531a08eba590310
This commit is contained in:
Maciej Żenczykowski 2025-09-11 12:09:12 -07:00
commit 1476ec1141
1 changed files with 2 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

4
bpf/headers/include/bpf/BpfMap.h
View file

@ -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<void> doBulkLookupAndMaybeDelete(bool del, const function<void(const Key &, const Value &)> &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