[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <22c7cad9-72d1-46da-9f69-31b7837b9de8@gmail.com>
Date: Wed, 9 Oct 2024 20:05:37 +0100
From: Pavel Begunkov <asml.silence@...il.com>
To: Jens Axboe <axboe@...nel.dk>, David Wei <dw@...idwei.uk>,
io-uring@...r.kernel.org, netdev@...r.kernel.org
Cc: Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jesper Dangaard Brouer <hawk@...nel.org>, David Ahern <dsahern@...nel.org>,
Mina Almasry <almasrymina@...gle.com>
Subject: Re: [PATCH v1 10/15] io_uring/zcrx: add io_zcrx_area
On 10/9/24 19:02, Jens Axboe wrote:
> On 10/7/24 4:15 PM, David Wei wrote:
...
>> +struct io_zcrx_area {
>> + struct net_iov_area nia;
>> + struct io_zcrx_ifq *ifq;
>> +
>> + u16 area_id;
>> + struct page **pages;
>> +
>> + /* freelist */
>> + spinlock_t freelist_lock ____cacheline_aligned_in_smp;
>> + u32 free_count;
>> + u32 *freelist;
>> +};
>
> I'm wondering if this really needs an aligned lock? Since it's only a
> single structure, probably not a big deal. But unless there's evidence
> to the contrary, might not be a bad idea to just kill that.
napi and IORING_OP_RECV_ZC can run on different CPUs, I wouldn't
want the fields before the lock being contended by the lock
because of cache line sharing, would especially hurt until it's
warmed up well. Not really profiled, but not like we need to
care about space here.
--
Pavel Begunkov
Powered by blists - more mailing lists