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

[Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>]

On 9/22/26 7:08 PM, sashiko-bot@kernel.org wrote:
> 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?

yes, I think this is a good idea.> 
>>  	*insn++ = BPF_JMP_IMM(BPF_JEQ, ret, 0, 1);
>>  	*insn++ = BPF_ALU64_IMM(BPF_ADD, ret,
>>  				offsetof(struct htab_elem, key) +
>