[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210806010508.16709-1-kuniyu@amazon.co.jp>
Date: Fri, 6 Aug 2021 10:05:08 +0900
From: Kuniyuki Iwashima <kuniyu@...zon.co.jp>
To: <kafai@...com>
CC: <andrii@...nel.org>, <ast@...nel.org>, <benh@...zon.com>,
<bpf@...r.kernel.org>, <daniel@...earbox.net>,
<davem@...emloft.net>, <john.fastabend@...il.com>,
<kpsingh@...nel.org>, <kuba@...nel.org>, <kuni1840@...il.com>,
<kuniyu@...zon.co.jp>, <netdev@...r.kernel.org>,
<songliubraving@...com>, <yhs@...com>
Subject: Re: [PATCH v3 bpf-next 1/2] bpf: af_unix: Implement BPF iterator for UNIX domain socket.
From: Martin KaFai Lau <kafai@...com>
Date: Thu, 5 Aug 2021 17:41:14 -0700
> 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.
Ah sorry, I meant the same optimisation logic is not used for now.
I'll change the word.
> > 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.
Yes, batching can be done with a big lock.
> Batching is needed for supporting bpf_setsockopt. It can be added later
> together with the bpf_setsockopt support.
I'm trying to replace the big lock, so I'll submit another set for batching
and bpf_setsockopt support.
Thank you!
Powered by blists - more mailing lists