On 02/03/18 09:18 AM, Jason Gunthorpe wrote:
This allocator is already seems not useful for the P2P target memory
on a Mellanox NIC due to the way it has a special allocation flow
(windowing) and special usage requirements..
Nor can it be usefull for the doorbell memory in the NIC.
No one says every P2P use has to use P2P memory. Doorbells are obviously
not P2P memory. But it's the p2mem interface that's important and the
interface absolutely does not belong in the NVMe driver. Once you have
the P2P memory interface you need an allocator behind it and the obvious
place is in the P2P code to handle the common case where you're just
mapping a BAR. We don't need to implement a genalloc in every driver
that has P2P memory attached with it. If some hardware wants to expose
memory that requires complicated allocation it's up to them to solve
that problem but that isn't enough justification, to me, to push common
code into every driver.
Both of these are existing use cases for P2P with out of tree patches..
And we have out of tree code that uses the generic allocator part of
The allocator seems to only be able to solve the CMB problem, and I
think due to that it is better to put this allocator in the NVMe
driver and not the core code.. At least until we find a 2nd user that
needs the same allocation scheme...
See the first P2PMEM RFC. We used Chelsio's NIC instead of the CMB with
a very similar allocation scheme. We'd still be enabling that NIC in the
same way if we didn't run into hardware issues with it. A simple BAR
with memory behind it is always going to be the most common case.