linux-kernel - Re: [PATCH net-next v1] net: page_pool: add page_pool_put_page

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] [day] [month] [year] [list]

Message-ID: <ad553453-eb3b-4c1e-9342-e1ae74e6ff81@intel.com>
Date: Fri, 20 Dec 2024 16:49:59 +0100
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Ilias Apalodimas <ilias.apalodimas@...aro.org>, Jakub Kicinski
	<kuba@...nel.org>
CC: Guowei Dang <guowei.dang@...mail.com>, <linux-kernel@...r.kernel.org>,
	<linux-doc@...r.kernel.org>, <netdev@...r.kernel.org>, Jesper Dangaard Brouer
	<hawk@...nel.org>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet
	<edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Simon Horman
	<horms@...nel.org>, Jonathan Corbet <corbet@....net>, Yunsheng Lin
	<linyunsheng@...wei.com>, Furong Xu <0x1207@...il.com>
Subject: Re: [PATCH net-next v1] net: page_pool: add
 page_pool_put_page_nosync()

From: Ilias Apalodimas <ilias.apalodimas@...aro.org>
Date: Fri, 20 Dec 2024 14:27:16 +0200

> Hi Jakub
> 
> On Thu, 19 Dec 2024 at 16:24, Jakub Kicinski <kuba@...nel.org> wrote:
>>
>> On Thu, 19 Dec 2024 11:11:38 +0800 Guowei Dang wrote:
>>> Add page_pool_put_page_nosync() to respond to dma_sync_size being 0.
>>>
>>> The purpose of this is to make the semantics more obvious and may
>>> enable removing some checkings in the future.
>>>
>>> And in the long term, treating the nosync scenario separately provides
>>> more flexibility for the user and enable removing of the
>>> PP_FLAG_DMA_SYNC_DEV in the future.
>>>
>>> Since we do have a page_pool_put_full_page(), adding a variant for
>>> the nosync seems reasonable.
>>
>> You should provide an upstream user with the API.
>> But IMHO this just complicates the already very large API,
>> for little benefit.
> 
> +1000, I think the API has grown more than it has to and we now have
> way too many abstractions.
> 
> I'll try to find some time and see if I can come up with a cleanup
> that makes sense

I'd remove:

* explicit 1-page-per-buffer API (leaving only the hybrid mode);
* order > 0 support (barely used if at all?);
* usage without DMA map and sync for device;

+ converting the users to netmem would allow to remove some wrappers.

Thanks,
Olek