Re: [PATCH RFC bpf-next v2 03/18] bpf: Implement lookup, delete, update for resizable hashtab

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

On 4/13/26 5:27 PM, Daniel Borkmann wrote:
> On 4/13/26 6:24 PM, Alexei Starovoitov wrote:
>> On Mon, Apr 13, 2026 at 3:52 AM Mykyta Yatsenko
>> <mykyta.yatsenko5@gmail.com> wrote:
>>> On 4/13/26 12:10 AM, Alexei Starovoitov wrote:
>>>> On Wed, Apr 8, 2026 at 8:10 AM Mykyta Yatsenko
>>>> <mykyta.yatsenko5@gmail.com> wrote:
>>>>>
>>>>>
>>>>> +static void *rhtab_lookup_elem(struct bpf_map *map, void *key)
>>>>> +{
>>>>> +       struct bpf_rhtab *rhtab = container_of(map, struct 
>>>>> bpf_rhtab, map);
>>>>> +       /* Using constant zeroed params to force rhashtable use 
>>>>> inlined hashfunc */
>>>>> +       static const struct rhashtable_params params = { 0 };
>>>>> +
>>>>> +       return rhashtable_lookup_likely(&rhtab->ht, key, params);
>>>>
>>>> How does the asm look like?
>>>
>>> You can see how asm looks like below. An interesting thing is that gcc
>>> inlines jhash2, but not clang, which costs a lot of performance.
>>>
>>> gcc:
>>> lookup 20.675M ± 0.090M events/sec (approximated from 32 samples of 
>>> ~48ms)
>>>
>>> clang:
>>> cpu00: lookup 15.882M ± 0.530M events/sec (approximated from 32 samples
>>> of ~62ms)
>>>
>>> I think inlining is also consistent for htab and rhtab (either both
>>> inline or both do not inline).
>>
>> Try other hashes. I recall somebody from isovalent experimented
>> replacing jhash with xxhash and/or siphash in hash map and had nice
>> improvements for certain key sizes.
> 
> [ +Anton ]
> 
> page 26+: https://bpfconf.ebpf.io/bpfconf2023/bpfconf2023_material/ 
> anton-protopopov-lsf-mm-bpf-2023.pdf

Thanks for sharing that presentation, looking at the graphs on page 27, 
jhash2 is actually a better choice for the key size below 10 bytes 
(correct me if I'm wrong). And for rhashtable it's going to make even 
bigger difference, because jhash2 is inlined, because it's used by 
default by rhashtable, while other hash fns we'll have to provide via 
function pointer -> no inlining, which is a huge difference (see above).
Looking at the profiling data, hash fn (when inlined) does not look like 
a bottleneck memcmp is, though.
Anyways, I'll run benchmarks with other hash functions.