From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Anton Protopopov" <a.s.protopopov@gmail.com>,
"Mykyta Yatsenko" <mykyta.yatsenko5@gmail.com>
Cc: <bpf@vger.kernel.org>, <ast@kernel.org>, <andrii@kernel.org>,
<daniel@iogearbox.net>, <kernel-team@meta.com>,
<eddyz87@gmail.com>, <memxor@gmail.com>,
"Mykyta Yatsenko" <yatsenko@meta.com>
Subject: Re: [PATCH bpf-next v2] bpf: Speed up htab lookups for u32/u64 keys
Date: Tue, 22 Sep 2026 16:29:31 +0000 [thread overview]
Message-ID: <DLLZKD6BIZBS.1IZRLU3IEGEE5@gmail.com> (raw)
In-Reply-To: <arKqk5QsR6Fq1hFe@mail.gmail.com>
On Tue Sep 22, 2026 at 4:19 PM UTC, Anton Protopopov wrote:
>> I don't think we have a lot of maps with 64+ bytes keys on the
>> hot paths, but generally looks like a useful addition.
>>
>> We'll need to bring xxh3 into the kernel (it's not small),
>> do we want to limit it to bpf only or not.
Let's not rush with xxh. Sure, it's faster, but cost to maintain
a new hash function is not trivial.
>> Either way sounds like a good direction, but maybe for another
>> patch series.
>> Anton, Alexei, any thoughts, on xxh3 direction? Do we need it
>> at all, where to put hash implementation, should it go into this patch series
>> or new.
>
> I think this patch is great as is, no reason to block it by xxh3.
+1.
Proceed without xxh3 for now.
prev parent reply other threads:[~2026-09-22 16:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 21:28 [PATCH bpf-next v2] bpf: Speed up htab lookups for u32/u64 keys Mykyta Yatsenko
2026-09-21 21:38 ` Alexei Starovoitov
2026-09-21 22:34 ` bot+bpf-ci
2026-09-22 1:40 ` Alexei Starovoitov
2026-09-22 11:49 ` Mykyta Yatsenko
2026-09-22 7:31 ` Anton Protopopov
2026-09-22 11:45 ` Mykyta Yatsenko
2026-09-22 13:03 ` Anton Protopopov
2026-09-22 15:57 ` Mykyta Yatsenko
2026-09-22 16:19 ` Anton Protopopov
2026-09-22 16:29 ` Alexei Starovoitov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DLLZKD6BIZBS.1IZRLU3IEGEE5@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=a.s.protopopov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@meta.com \
--cc=memxor@gmail.com \
--cc=mykyta.yatsenko5@gmail.com \
--cc=yatsenko@meta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox