From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Herbert Xu" <herbert@gondor.apana.org.au>
Cc: "Mykyta Yatsenko" <mykyta.yatsenko5@gmail.com>,
"bpf" <bpf@vger.kernel.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Martin Lau" <kafai@meta.com>,
"Kernel Team" <kernel-team@meta.com>,
"Eduard" <eddyz87@gmail.com>,
"Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
"Mykyta Yatsenko" <yatsenko@meta.com>
Subject: Re: [PATCH RFC bpf-next v2 00/18] bpf: Introduce resizable hash map
Date: Thu, 16 Apr 2026 07:11:12 -0700 [thread overview]
Message-ID: <DHUN1UJ0DLBC.3UC7SXBAV2FOW@gmail.com> (raw)
In-Reply-To: <aeBxQn8ATaNuEF4X@gondor.apana.org.au>
On Wed Apr 15, 2026 at 10:18 PM PDT, Herbert Xu wrote:
> On Tue, Apr 14, 2026 at 10:13:21PM -0700, Alexei Starovoitov wrote:
>>
>> No need for such guarantees. It's best-effort only.
>> If the walk skips entries it's fine.
>> As long as it terminates eventually it's good.
>
> There is no guarantee that this walk will terminate (unless you
> finish it in one go). In a pathological scenario, after each
> walk attempt, the hash table could be rehashed such that the
> entry that you're resuming from gets moved back to bucket 0.
>
> More practically, the walk is essentially useless if you encounter
> a rehash/resize event before calling rhashtable_walk_enter_from,
> because half of the hash table could be missed because the entry
> got moved near the end.
>
> I think a better interface is to detect such a rehash/resize event
> and then fail the rhashtable_walk_enter_from call.
that's certainly a cleaner interface. the user can retry
if resize occurs.
next prev parent reply other threads:[~2026-04-16 14:11 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 15:10 [PATCH RFC bpf-next v2 00/18] bpf: Introduce resizable hash map Mykyta Yatsenko
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 01/18] bpf: Register rhash map Mykyta Yatsenko
2026-04-10 22:31 ` Emil Tsalapatis
2026-04-13 8:10 ` Mykyta Yatsenko
2026-04-14 17:50 ` Emil Tsalapatis
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 02/18] bpf: Add resizable hashtab skeleton Mykyta Yatsenko
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 03/18] bpf: Implement lookup, delete, update for resizable hashtab Mykyta Yatsenko
2026-04-12 23:10 ` Alexei Starovoitov
2026-04-13 10:52 ` Mykyta Yatsenko
2026-04-13 16:24 ` Alexei Starovoitov
2026-04-13 16:27 ` Daniel Borkmann
2026-04-13 19:43 ` Mykyta Yatsenko
2026-04-13 20:37 ` Emil Tsalapatis
2026-04-14 8:34 ` Mykyta Yatsenko
2026-04-14 10:25 ` Leon Hwang
2026-04-14 10:28 ` Mykyta Yatsenko
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 04/18] rhashtable: Add rhashtable_walk_enter_from() Mykyta Yatsenko
2026-04-12 23:13 ` Alexei Starovoitov
2026-04-13 12:22 ` Mykyta Yatsenko
2026-04-13 22:22 ` Emil Tsalapatis
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 05/18] bpf: Implement get_next_key and free_internal_structs for resizable hashtab Mykyta Yatsenko
2026-04-13 22:44 ` Emil Tsalapatis
2026-04-14 8:11 ` Mykyta Yatsenko
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 06/18] bpf: Implement bpf_each_rhash_elem() using walk API Mykyta Yatsenko
2026-04-13 23:02 ` Emil Tsalapatis
2026-04-24 15:16 ` Mykyta Yatsenko
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 07/18] bpf: Implement batch ops for resizable hashtab Mykyta Yatsenko
2026-04-13 23:25 ` Emil Tsalapatis
2026-04-14 8:08 ` Mykyta Yatsenko
2026-04-14 17:47 ` Emil Tsalapatis
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 08/18] bpf: Implement iterator APIs " Mykyta Yatsenko
2026-04-14 17:49 ` Emil Tsalapatis
2026-04-15 11:15 ` Mykyta Yatsenko
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 09/18] bpf: Implement alloc and free " Mykyta Yatsenko
2026-04-12 23:15 ` Alexei Starovoitov
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 10/18] bpf: Allow timers, workqueues and task_work in " Mykyta Yatsenko
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 11/18] libbpf: Support resizable hashtable Mykyta Yatsenko
2026-04-14 17:46 ` Emil Tsalapatis
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 12/18] selftests/bpf: Add basic tests for resizable hash map Mykyta Yatsenko
2026-04-12 23:16 ` Alexei Starovoitov
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 13/18] selftests/bpf: Support resizable hashtab in test_maps Mykyta Yatsenko
2026-04-12 23:17 ` Alexei Starovoitov
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 14/18] selftests/bpf: Resizable hashtab BPF_F_LOCK tests Mykyta Yatsenko
2026-04-12 23:18 ` Alexei Starovoitov
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 15/18] selftests/bpf: Add stress tests for resizable hash get_next_key Mykyta Yatsenko
2026-04-12 23:19 ` Alexei Starovoitov
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 16/18] selftests/bpf: Add BPF iterator tests for resizable hash map Mykyta Yatsenko
2026-04-12 23:20 ` Alexei Starovoitov
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 17/18] bpftool: Add rhash map documentation Mykyta Yatsenko
2026-04-14 17:51 ` Emil Tsalapatis
2026-04-08 15:10 ` [PATCH RFC bpf-next v2 18/18] selftests/bpf: Add resizable hashmap to benchmarks Mykyta Yatsenko
2026-04-12 23:25 ` Alexei Starovoitov
2026-04-12 23:11 ` [PATCH RFC bpf-next v2 00/18] bpf: Introduce resizable hash map Alexei Starovoitov
2026-04-13 8:28 ` Mykyta Yatsenko
2026-04-15 3:27 ` Herbert Xu
2026-04-15 5:13 ` Alexei Starovoitov
2026-04-16 5:18 ` Herbert Xu
2026-04-16 14:11 ` Alexei Starovoitov [this message]
2026-04-16 15:10 ` Mykyta Yatsenko
2026-04-16 15:36 ` Alexei Starovoitov
2026-04-16 16:30 ` Mykyta Yatsenko
2026-04-17 6:54 ` Herbert Xu
2026-04-17 15:16 ` Mykyta Yatsenko
2026-04-18 0:43 ` Herbert Xu
2026-04-20 11:45 ` Mykyta Yatsenko
2026-04-20 15:41 ` Alexei Starovoitov
2026-04-20 15:50 ` Mykyta Yatsenko
2026-04-20 16:06 ` Alexei Starovoitov
2026-04-20 16:37 ` Mykyta Yatsenko
2026-04-20 18:00 ` Alexei Starovoitov
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=DHUN1UJ0DLBC.3UC7SXBAV2FOW@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=kafai@meta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.