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.