On 9/14/20 2:28 PM, Song Liu wrote:
On Mon, Sep 14, 2020 at 11:47 AM Yonghong Song <yhs@xxxxxx> wrote:
Currently, we use bucket_lock when traversing bpf_sk_storage_map
elements. Since bpf_iter programs cannot use bpf_sk_storage_get()
and bpf_sk_storage_delete() helpers which may also grab bucket lock,
we do not have a deadlock issue which exists for hashmap when
using bucket_lock ([1]).
The paragraph above describes why we can use bucket_lock, which is more
or less irrelevant to this change. Also, I am not sure why we refer to [1] here.
What I try to clarify here is unlike [1], we do not have bugs
with the current code.
But I guess no bugs is implicit so I probably do not need to say
anything. Will skip the above paragraph in the next revision.
If a bucket contains a lot of sockets, during bpf_iter traversing
a bucket, concurrent bpf_sk_storage_{get,delete}() may experience
some undesirable delays. Using rcu_read_lock() is a reasonable
It will be great to include some performance comparison.
Sure. Let me give some try to collect some statistics.
compromise here. Although it may lose some precision, e.g.,
access stale sockets, but it will not hurt performance of other
bpf programs.
[1] https://lore.kernel.org/bpf/20200902235341.2001534-1-yhs@xxxxxx
Cc: Martin KaFai Lau <kafai@xxxxxx>
Signed-off-by: Yonghong Song <yhs@xxxxxx>
Other than these,
Acked-by: Song Liu <songliubraving@xxxxxx>
[...]
