netdev - Re: [RFC PATCH net-next] page_pool: Track DMA-mapped pages and unmap them when destroying the pool

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: <65dd1ce6-1ee3-4678-a156-244e6c0ca127@gmail.com>
Date: Wed, 12 Mar 2025 12:53:53 +0000
From: Pavel Begunkov <asml.silence@...il.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>,
 Yunsheng Lin <linyunsheng@...wei.com>,
 Yunsheng Lin <yunshenglin0825@...il.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Jesper Dangaard Brouer <hawk@...nel.org>,
 Ilias Apalodimas <ilias.apalodimas@...aro.org>,
 "David S. Miller" <davem@...emloft.net>
Cc: Yonglong Liu <liuyonglong@...wei.com>,
 Mina Almasry <almasrymina@...gle.com>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Simon Horman <horms@...nel.org>, linux-mm@...ck.org, netdev@...r.kernel.org
Subject: Re: [RFC PATCH net-next] page_pool: Track DMA-mapped pages and unmap
 them when destroying the pool

On 3/12/25 12:27, Toke Høiland-Jørgensen wrote:
> Yunsheng Lin <linyunsheng@...wei.com> writes:
...
>>>>> cases where it's absolutely needed.
>>>>
>>>> The above can also be done for using page_pool_item too as the
>>>> lower 2 bits can be used to indicate the pointer in 'struct page'
>>>> is 'page_pool_item' or 'page_pool', I just don't think it is
>>>> necessary yet as it might add more checking in the fast path.
>>>
>>> Yup, did think about using the lower bits to distinguish if it does turn
>>> out that we can't avoid an indirection. See above; it's not actually the
>>
>> The 'memdesc' seems like an indirection to me when using that to shrink
>> 'struct page' to a smaller size.
> 
> Yes, it does seem like we'll end up with an indirection of some kind
> eventually. But let's cross that bridge when we get to it...

At which point it might be easier to avoid all the "bump"s business,
fully embrace net_iov / netmem format, wrap all pp pages into a
structure on the page pool side, and pass that around. That would
remove the indirection for most of the accesses, and the allocation
can be easily cached.

-- 
Pavel Begunkov