On Sat, Mar 09, 2024 at 05:14:18PM +0100, Christoph Hellwig wrote:
> On Fri, Mar 08, 2024 at 04:23:42PM -0400, Jason Gunthorpe wrote:
> > > The DMA API callers really need to know what is P2P or not for
> > > various reasons. And they should generally have that information
> > > available, either from pin_user_pages that needs to special case
> > > it or from the in-kernel I/O submitter that build it from P2P and
> > > normal memory.
> >
> > I think that is a BIO thing. RDMA just calls with FOLL_PCI_P2PDMA and
> > shoves the resulting page list into in a scattertable. It never checks
> > if any returned page is P2P - it has no reason to care. dma_map_sg()
> > does all the work.
>
> Right now it does, but that's not really a good interface. If we have
> a pin_user_pages variant that only pins until the next relevant P2P
> boundary and tells you about we can significantly simplify the overall
> interface.
Sorry for the delay, I was away..
I kind of understand your thinking on the DMA side, but I don't see
how this is good for users of the API beyond BIO.
How will this make RDMA better? We have one MR, the MR has pages, the
HW doesn't care about the SW distinction of p2p, swiotlb, direct,
encrypted, iommu, etc. It needs to create one HW page list for
whatever user VA range was given.
Or worse, whatever thing is inside a DMABUF from a DRM
driver. DMABUF's can have a (dynamic!) mixture of P2P and regular
AFAIK based on the GPU's migration behavior.
Or triple worse, ODP can dynamically change on a page by page basis
the type depending on what hmm_range_fault() returns.
So I take it as a requirement that RDMA MUST make single MR's out of a
hodgepodge of page types. RDMA MRs cannot be split. Multiple MR's are
not a functional replacement for a single MR.
Go back to the start of what are we trying to do here:
1) Make a DMA API that can support hmm_range_fault() users in a
sensible and performant way
2) Make a DMA API that can support RDMA MR's backed by DMABUF's, and
user VA's without restriction
3) Allow to remove scatterlist from BIO paths
4) Provide a DMABUF API that is not scatterlist that can feed into
the new DMA API - again supporting DMABUF's hodgepodge of types.
I'd like to do all of these things. I know 3 is your highest priority,
but it is my lowest :)
So, if the new API can only do uniformity I immediately loose #1 -
hmm_range_fault() can't guarentee anything, so it looses the IOVA
optimization that Leon's patches illustrate.
For uniformity #2 probably needs multiple DMA API "transactions". This
is doable, but it is less performant than one "transaction".
#3 is perfectly happy because BIO already creates uniformity
#4 is like #2, there is not guarenteed uniformity inside DMABUF so
every DMABUF importer needs to take some complexity to deal with
it. There are many DMABUF importers so this feels like a poor API
abstraction if we force everyone there to take on complexity.
So I'm just not seeing why this would be better. I think Leon's series
shows the cost of non-uniformity support is actually pretty
small. Still, we could do better, if the caller can optionally
indicate it knows it has uniformity then that can be optimized futher.
I'd like to find something that works well for all of the above, and I
think abstracting non-uniformity at the API level is important for the
above reasons.
Can we tweak what Leon has done to keep the hmm_range_fault support
and non-uniformity for RDMA but add a uniformity optimized flow for
BIO?
Jason
