netdev - Re: [net-next v1 09/16] page_pool: device memory support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <17adf1c0-e4ad-4baf-4d01-32d6544cc13e@huawei.com>
Date: Wed, 13 Dec 2023 19:48:56 +0800
From: Yunsheng Lin <linyunsheng@...wei.com>
To: Mina Almasry <almasrymina@...gle.com>
CC: Shailend Chand <shailend@...gle.com>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>,
	<linux-arch@...r.kernel.org>, <linux-kselftest@...r.kernel.org>,
	<bpf@...r.kernel.org>, <linux-media@...r.kernel.org>,
	<dri-devel@...ts.freedesktop.org>, "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo
 Abeni <pabeni@...hat.com>, Jonathan Corbet <corbet@....net>, Jeroen de Borst
	<jeroendb@...gle.com>, Praveen Kaligineedi <pkaligineedi@...gle.com>, Jesper
 Dangaard Brouer <hawk@...nel.org>, Ilias Apalodimas
	<ilias.apalodimas@...aro.org>, Arnd Bergmann <arnd@...db.de>, David Ahern
	<dsahern@...nel.org>, Willem de Bruijn <willemdebruijn.kernel@...il.com>,
	Shuah Khan <shuah@...nel.org>, Sumit Semwal <sumit.semwal@...aro.org>,
	Christian König <christian.koenig@....com>, Harshitha
 Ramamurthy <hramamurthy@...gle.com>, Shakeel Butt <shakeelb@...gle.com>
Subject: Re: [net-next v1 09/16] page_pool: device memory support

On 2023/12/12 22:28, Mina Almasry wrote:

...

>>
>> the page_ref_*() API may be avoided using the below patch:
>> https://patchwork.kernel.org/project/netdevbpf/patch/20231113130041.58124-7-linyunsheng@huawei.com/
>>
> 
> Even after the patch above, you're still calling page_ref_count() in
> the page_pool to check for recycling, so after that patch you're still
> using page->_refcount.

Yes, we still need page_ref_count(), which seems be a similar problem
like the one for page_is_pfmemalloc(), can we deal with it like most
of other fields?

> 
>> But I am not sure how to do that for tx part if devmem for tx is not
>> intergating into page_pool, that is why I suggest having a tx implementation
>> for the next version, so that we can have a whole picture of devmem.
>>
> 
> I strongly prefer to keep the TX implementation in a separate series.
> This series is complicated to implement and review as it is, and is
> hitting the 15 patch limit anyway.

I am not sure how complicated the TX implementation for devmem will be
for the latest version, but from the RFCv1, it seems it is simple enough
to keep it in one patchset.

Anyway, it would be good to sort out the basic idea what is the tx API
for devmem when designing/implementing the rx API for devmem.

>