[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210806004114.pf77j5a6eb4223wn@kafai-mbp>
Date: Thu, 5 Aug 2021 17:41:14 -0700
From: Martin KaFai Lau <kafai@...com>
To: Kuniyuki Iwashima <kuniyu@...zon.co.jp>
CC: "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>,
Benjamin Herrenschmidt <benh@...zon.com>,
Kuniyuki Iwashima <kuni1840@...il.com>, <bpf@...r.kernel.org>,
<netdev@...r.kernel.org>
Subject: Re: [PATCH v3 bpf-next 1/2] bpf: af_unix: Implement BPF iterator for
UNIX domain socket.
On Wed, Aug 04, 2021 at 04:08:50PM +0900, Kuniyuki Iwashima wrote:
> Currently, the batch optimization introduced for the TCP iterator in the
> commit 04c7820b776f ("bpf: tcp: Bpf iter batching and lock_sock") is not
> applied. It will require replacing the big lock for the hash table with
may be s/applied/used/. I thought it meant the commit is not landed.
> small locks for each hash list not to block other processes.
Right, I don't think it can be directly reused. Not necessary
related to the big lock though. Actually, a big lock will still
work for batching but just less ideal.
Batching is needed for supporting bpf_setsockopt. It can be added later
together with the bpf_setsockopt support.
Powered by blists - more mailing lists