[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230706095028.19c4c637@kernel.org>
Date: Thu, 6 Jul 2023 09:50:28 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Mina Almasry <almasrymina@...gle.com>
Cc: Jesper Dangaard Brouer <jbrouer@...hat.com>, brouer@...hat.com,
Alexander Duyck <alexander.duyck@...il.com>, Yunsheng Lin
<linyunsheng@...wei.com>, davem@...emloft.net, pabeni@...hat.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Lorenzo Bianconi
<lorenzo@...nel.org>, Yisen Zhuang <yisen.zhuang@...wei.com>, Salil Mehta
<salil.mehta@...wei.com>, Eric Dumazet <edumazet@...gle.com>, Sunil Goutham
<sgoutham@...vell.com>, Geetha sowjanya <gakula@...vell.com>, Subbaraya
Sundeep <sbhatta@...vell.com>, hariprasad <hkelam@...vell.com>, Saeed
Mahameed <saeedm@...dia.com>, Leon Romanovsky <leon@...nel.org>, Felix
Fietkau <nbd@....name>, Ryder Lee <ryder.lee@...iatek.com>, Shayne Chen
<shayne.chen@...iatek.com>, Sean Wang <sean.wang@...iatek.com>, Kalle Valo
<kvalo@...nel.org>, Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Jesper Dangaard Brouer <hawk@...nel.org>, Ilias Apalodimas
<ilias.apalodimas@...aro.org>, linux-rdma@...r.kernel.org,
linux-wireless@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, Jonathan Lemon
<jonathan.lemon@...il.com>
Subject: Re: Memory providers multiplexing (Was: [PATCH net-next v4 4/5]
page_pool: remove PP_FLAG_PAGE_FRAG flag)
On Thu, 29 Jun 2023 19:27:46 -0700 Mina Almasry wrote:
> I've discussed your page pool frontend idea with our gve owners and
> the idea is attractive. In particular it would be good not to insert
> much custom code into the driver to support device memory pages or
> other page types. I plan on trying to change my approach to match the
> page pool provider you have in progress here:
> https://github.com/kuba-moo/linux/tree/pp-providers
>
> In particular the main challenge right now seems to be that my device
> memory pages are ZONE_DEVICE pages, which can't be inserted to the
> page pool as-is due to the union in struct page between the page pool
> entries and the ZONE_DEVICE entries. I have some ideas on how to work
> around that I'm looking into.
Right, have you talked to Willem? I mentioned to him that I initially
pursued the idea of using the page pool as an abstraction but I
realized that fitting both the dma addr and the frag reference count
into struct page which isn't just a basic page will be a challenge.
So the second best thing seems to be to create an API which matches
the page pool API, and have it select between a page pool and another
provider based on user configuration. As you said the main goal is to
be able to feed kernel / user / device memory to the driver without
having to modify driver code.
I thought this would live "above" the page pool (perhaps that's what
you mean by gen_pool) but Jesper brought up integrating it into the
(middle of?) page pool and have page pool switch on the pp_magic.
No strong preference on which on is better, seems like something that
can only be ironed out by modifying a couple of drivers to find out
what fits best :(
I'm hoping to jump back into the pp_provider work and finish that up
over the next few days, to at least post a PoC. Even if it doesn't work
for user / device memory - being able to feed the page pool from huge
pages is already a big win for the IOTLB.
Powered by blists - more mailing lists