Re: [PATCH bpf-next v3] bpf: Speed up htab lookups for u32/u64 keys

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpf: missed u32/u64 lookup optimization for LRU/per-CPU/of_map variants
--

commit 88a648ce718a5816a7cc1175a104d2f26afc58c0
Author: Mykyta Yatsenko <yatsenko@meta.com>

bpf: Speed up htab lookups for u32/u64 keys

This commit introduces specialized hashing and specific lookup entry points
for 4-byte and 8-byte keys in BPF hash maps. It achieves significant
throughput improvements for standard BPF_MAP_TYPE_HASH lookups.

> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index 6f331c80130d7..f744a42bb8139 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c

[ ... ]

> @@ -783,7 +805,16 @@ static int htab_map_gen_lookup(struct bpf_map *map, struct bpf_insn *insn_buf)
>  
>  	BUILD_BUG_ON(!__same_type(&__htab_map_lookup_elem,
>  		     (void *(*)(struct bpf_map *map, void *key))NULL));
> -	*insn++ = BPF_EMIT_CALL(__htab_map_lookup_elem);
> +	BUILD_BUG_ON(!__same_type(&__htab_map_lookup_elem_u32,
> +				  (void *(*)(struct bpf_map *map, void *key))NULL));
> +	BUILD_BUG_ON(!__same_type(&__htab_map_lookup_elem_u64,
> +				  (void *(*)(struct bpf_map *map, void *key))NULL));
> +	if (map->key_size == sizeof(u32))
> +		*insn++ = BPF_EMIT_CALL(__htab_map_lookup_elem_u32);
> +	else if (map->key_size == sizeof(u64))
> +		*insn++ = BPF_EMIT_CALL(__htab_map_lookup_elem_u64);
> +	else
> +		*insn++ = BPF_EMIT_CALL(__htab_map_lookup_elem);

[Severity: Medium]
Does this miss an opportunity to apply the identical u32/u64 lookup
optimization to the LRU, per-CPU, and hash-of-maps variants?

It looks like specialized JIT lookup generators were added here for
standard hash maps in htab_map_gen_lookup(), but identically structured
functions in the same file such as htab_lru_map_gen_lookup(),
htab_percpu_map_gen_lookup(), and htab_of_map_gen_lookup() still
unconditionally emit a call to the unspecialized __htab_map_lookup_elem.

Would it make sense to update those generators as well, so these heavily
utilized map variants do not miss out on the same performance gains?

>  	*insn++ = BPF_JMP_IMM(BPF_JEQ, ret, 0, 1);
>  	*insn++ = BPF_ALU64_IMM(BPF_ADD, ret,
>  				offsetof(struct htab_elem, key) +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922-hashtab_fast_hashfn-v3-1-b7b0e9bc33ac@meta.com?part=1