On 5/6/24 13:04, Christoph Hellwig wrote:
On Fri, May 03, 2024 at 01:10:44PM -0700, Mina Almasry wrote:
Is the concern still that folks may be able to hook proprietary stuff
into this like you mentioned before[1]?
That is on concern. The other is that people will do stupid stuff
We're not now banning all virtual function tables because there is
a chance someone might probably conceivably do perhaps something
proprietary, aren't we? Let's just patch up all ways they might
use it if there is any left.
even in tree if you give them enough rope, and they should not have
that rope when the only sensible options are page/folio based kernel
memory (incuding large/huge folios) and dmabuf.
I believe there is at least one deep confusion here, considering you
previously mentioned Keith's pre-mapping patches. The "hooks" are not
that about in what format you pass memory, it's arguably the least
interesting part for page pool, more or less it'd circulate whatever
is given. It's more of how to have a better control over buffer lifetime
and implement a buffer pool passing data to users and empty buffers
back.
It's a different from storage where a user passes a buffer before it
initiates a read, data is sent by the other socket end. TCP devmem
uses dmabuf, io_uring keeps pages (of normal user memory).
cp net/core/page_pool.c net/core/dmabuf_pool.c
and then modify it such that the net stack maintains 2 page_pools?
There are a lot of cons to that:
No. Just have branches for page based vs dmabuf in a few places.
--
Pavel Begunkov
