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

Daniel Borkmann
2026-04-13T16:28:12Z

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