Message	SHA1
BpfMap.h: add consume() ... switch some iterate to forAll()/consume() Currently we only use: BPF_MAP_LOOKUP_ELEM BPF_MAP_UPDATE_ELEM BPF_MAP_DELETE_ELEM BPF_MAP_GET_NEXT_KEY Our implementation does: getFirstKey() -> BPF_MAP_GET_NEXT_KEY (with empty key, maybe newer kernels would accept null too) getNextKey(K) -> BPF_MAP_GET_NEXT_KEY readValue(K) -> BPF_MAP_LOOKUP_ELEM iterate(f(K)) -> getFirstKey(), loop { getNextKey(K) } forAll(f(K)) -> iterate(f(K)) iterate(f(K, V)) -> getFirstKey(), loop { getNextKey(K) readValue(K) } forAll(f(K, V)) -> iterate(f(K, V)) isEmpty() -> getFirstKey() writeValue(K, V) -> BPF_MAP_UPDATE_ELEM deleteValue(K) -> BPF_MAP_DELETE_ELEM clear() -> loop { getFirstKey() deleteValue(K) } consume(f(K, V)) -> iterate(f(K, V) + deleteValue(K)) but bpf on newer kernels also supports: BPF_MAP_LOOKUP_AND_DELETE_ELEM and batch operations: BPF_MAP_LOOKUP_BATCH BPF_MAP_LOOKUP_AND_DELETE_BATCH BPF_MAP_UPDATE_BATCH BPF_MAP_DELETE_BATCH that we don't currently use. These can be utilized to lower the number of system calls: - iterate(f(K, V)) might be able to use LOOPUP_BATCH(1) - forAll() can probably use LOOKUP_BATCH(many) - consume() can probably use one of LOOKUP_AND_DELETE_ELEM or LOOKUP_AND_DELETE_BATCH UPDATE_BATCH seems like it could also be useful, though harder to see how to make it useful from a clean API perspective... (and obviously for bpf map ARRAYs [and thus bitmaps], mmap() is simply much better...) Test: TreeHugger Flag: EXEMPT mainline Signed-off-by: Maciej Żenczykowski <maze@google.com> Change-Id: I2c142319c365aa1b9585256e2c604b221ba18c21 Maciej Żenczykowski   commited 2025-08-09 19:02:56 -07:00	d2bb131057
BpfMapTest: delete testGTSbitmapTestOpen ... (we've deleted the GTS test, so no need for this simple demo case) Test: TreeHugger Flag: EXEMPT mainline Signed-off-by: Maciej Żenczykowski <maze@google.com> Change-Id: I7f5a060f53ac97d55f533aea7a8148d3c091856d Maciej Żenczykowski   commited 2025-08-09 16:04:17 -07:00	67eba8ad38
BpfMap.h: introduce BpfMapRW ... which allows writes, but not deletes. This is technically what bpf map arrays are capable of. Test: TreeHugger Flag: EXEMPT mainline Signed-off-by: Maciej Żenczykowski <maze@google.com> Change-Id: I1f73bea5428c190af17442539c296282ce9e0786 Maciej Żenczykowski   commited 2025-08-09 16:03:46 -07:00	8b96286200
BpfMap - iterator rework ... It's so much better to just pass in the map (if needed) as part of the lambda capture... Test: TreeHugger Flag: EXEMPT mainline Signed-off-by: Maciej Żenczykowski <maze@google.com> Change-Id: If16fa9c8d0ade41628dc4f7ac1fa73127001b6b1 Maciej Żenczykowski   commited 2025-08-09 14:25:34 -07:00	70bdbb79ce
bpf: Test bitmap open (duplicates GTS) ... This test opens and closes the map, this makes sure the map exists and can be opened. Test: atest libbpf_android_test Bug: 379821131 Signed-off-by: Maciej Żenczykowski <maze@google.com> Change-Id: Iada96f1ec0961f61d0710cb5ba00c8a86b0aedca Maciej Żenczykowski   commited 2024-12-18 13:49:45 -08:00	b8750c4a0c
bpf: move bpf_headers into /bpf subdirectory ... Generated via: git mv staticlibs/native/bpf_headers bpf/headers cd bpf/headers/include git mv bpf/bpf_helpers.h . git mv bpf/bpf_map_def.h . manually fix up bpf/bpf_map_def.h include path bpf_helpers.h is only used by bpf programs so the 'bpf/' prefix is spurious. bpf_map_def.h is only used by bpf programs and the two bpfloaders, which effectively means the 'bpf/' prefix isn't useful. Test: TreeHugger Signed-off-by: Maciej Żenczykowski <maze@google.com> Change-Id: Ic3fc4e354a15821c27c23b7dbc019daad9f6ad85 Maciej Żenczykowski   commited 2024-08-21 13:18:59 -07:00	d602835b4f

Renamed from staticlibs/native/bpf_headers/BpfMapTest.cpp (Browse further)