[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dd743d1e-d8a1-58d5-5b1f-8583d0f23b9f@huawei.com>
Date: Fri, 14 Apr 2023 08:57:03 +0800
From: Yunsheng Lin <linyunsheng@...wei.com>
To: Eric Dumazet <edumazet@...gle.com>
CC: Jakub Kicinski <kuba@...nel.org>, <davem@...emloft.net>,
<netdev@...r.kernel.org>, <pabeni@...hat.com>, <hawk@...nel.org>,
<ilias.apalodimas@...aro.org>, <alexander.duyck@...il.com>,
Tariq Toukan <tariqt@...dia.com>
Subject: Re: [PATCH net-next v2 1/3] net: skb: plumb napi state thru skb
freeing paths
On 2023/4/13 16:51, Eric Dumazet wrote:
> On Thu, Apr 13, 2023 at 9:49 AM Yunsheng Lin <linyunsheng@...wei.com> wrote:
>>
>> Maybe I missed something obvious about netpoll here.
>> Does that mean the "normal NAPI context" and "not normal NAPI context"
>> will call napi->poll() concurrently with different budget? Doesn't
>> that mean two different contexts may do the tx completion concurrently?
>
> Please take a look at netpoll code:
> netpoll_poll_lock, poll_napi() and poll_one_napi()
>
>> Does it break the single-producer single-consumer assumption of tx queue?
>
> We do not think so.
Then I guess it is ok to do direct recycling for page pool case as it is
per napi?
It is per cpu cache case we are using !!bugget to protect it from preemption
while netpoll_poll_dev() is running?
> .
>
Powered by blists - more mailing lists