From: Yunsheng Lin <yunshenglin0825@gmail.com>
To: Paolo Abeni <pabeni@redhat.com>,
Yunsheng Lin <linyunsheng@huawei.com>,
davem@davemloft.net, kuba@kernel.org
Cc: liuyonglong@huawei.com, fanghaiqing@huawei.com,
zhangkun09@huawei.com,
Alexander Lobakin <aleksander.lobakin@intel.com>,
Jesper Dangaard Brouer <hawk@kernel.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2 1/2] page_pool: fix timing for checking and disabling napi_local
Date: Wed, 2 Oct 2024 09:52:51 +0800 [thread overview]
Message-ID: <b071b158-6569-4bda-8886-6058897a7e28@gmail.com> (raw)
In-Reply-To: <d123d288-4215-4a8c-9689-bbfe24c24b08@redhat.com>
On 10/1/2024 7:30 PM, Paolo Abeni wrote:
...
>> @@ -828,6 +837,9 @@ void page_pool_put_unrefed_netmem(struct page_pool
>> *pool, netmem_ref netmem,
>> recycle_stat_inc(pool, ring_full);
>> page_pool_return_page(pool, netmem);
>> }
>> +
>> + if (!allow_direct_orig)
>> + rcu_read_unlock();
>
> What about always acquiring the rcu lock? would that impact performances
> negatively?
>
> If not, I think it's preferable, as it would make static checker happy.
As mentioned in cover letter, the overhead is about ~2ns
I guess it is the 'if' checking before rcu_read_unlock that static
checker is not happy about, there is also a 'if' checking before
the 'destroy_lock' introduced in patch 2, maybe '__cond_acquires'
can be used to make static checker happy?
>
>> }
>> EXPORT_SYMBOL(page_pool_put_unrefed_netmem);
>
> [...]
>
>> @@ -1121,6 +1140,12 @@ void page_pool_destroy(struct page_pool *pool)
>> return;
>> page_pool_disable_direct_recycling(pool);
>> +
>> + /* Wait for the freeing side see the disabling direct recycling
>> setting
>> + * to avoid the concurrent access to the pool->alloc cache.
>> + */
>> + synchronize_rcu();
>
> When turning on/off a device with a lot of queues, the above could
> introduce a lot of long waits under the RTNL lock, right?
>
> What about moving the trailing of this function in a separate helper and
> use call_rcu() instead?
For this patch, yes, it can be done.
But patch 2 also rely on the rcu lock in this patch to ensure that free
side is synchronized with the destroy path, and the dma mapping done for
the inflight pages in page_pool_item_uninit() can not be done in
call_rcu(), as the driver might have unbound when RCU callback is
called, which might defeat the purpose of patch 2.
Maybe an optimization here is to only call synchronize_rcu() when there
are some inflight pages and pool->dma_map is set.
next prev parent reply other threads:[~2024-10-02 1:52 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-25 7:57 [PATCH net v2 0/2] fix two bugs related to page_pool Yunsheng Lin
2024-09-25 7:57 ` [PATCH net v2 1/2] page_pool: fix timing for checking and disabling napi_local Yunsheng Lin
2024-09-26 20:06 ` Joe Damato
2024-09-27 3:58 ` Yunsheng Lin
2024-10-01 11:30 ` Paolo Abeni
2024-10-02 1:52 ` Yunsheng Lin [this message]
2024-10-09 0:40 ` Jakub Kicinski
2024-10-09 3:33 ` Yunsheng Lin
2024-10-09 15:13 ` Jakub Kicinski
2024-10-10 9:14 ` Yunsheng Lin
2024-09-25 7:57 ` [PATCH net v2 2/2] page_pool: fix IOMMU crash when driver has already unbound Yunsheng Lin
2024-09-26 18:15 ` Mina Almasry
2024-09-27 3:57 ` Yunsheng Lin
2024-09-27 5:54 ` Mina Almasry
2024-09-27 7:25 ` Yunsheng Lin
2024-09-27 9:21 ` Ilias Apalodimas
2024-09-27 9:49 ` Yunsheng Lin
2024-09-27 9:58 ` Ilias Apalodimas
2024-09-27 11:29 ` Yunsheng Lin
2024-09-28 7:34 ` Ilias Apalodimas
2024-09-29 2:44 ` Yunsheng Lin
2024-09-30 8:09 ` Ilias Apalodimas
2024-09-30 8:38 ` Yunsheng Lin
2024-10-01 13:32 ` Paolo Abeni
2024-10-02 2:34 ` Yunsheng Lin
2024-10-02 7:37 ` Paolo Abeni
2024-10-02 8:23 ` Ilias Apalodimas
2024-10-05 12:38 ` Yunsheng Lin
2024-10-02 6:46 ` Ilias Apalodimas
2024-10-02 6:51 ` Ilias Apalodimas
2024-09-25 13:31 ` [PATCH net v2 0/2] fix two bugs related to page_pool Yonglong Liu
2024-10-12 12:05 ` Yunsheng Lin
2024-10-15 0:14 ` Jakub Kicinski
2024-10-15 10:52 ` Yunsheng Lin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b071b158-6569-4bda-8886-6058897a7e28@gmail.com \
--to=yunshenglin0825@gmail.com \
--cc=aleksander.lobakin@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fanghaiqing@huawei.com \
--cc=hawk@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linyunsheng@huawei.com \
--cc=liuyonglong@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=zhangkun09@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®