| Message ID | 20210408170123.8788-1-logang@deltatee.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add new DMA mapping operation for P2PDMA | expand |
On Thu, Apr 08, 2021 at 11:01:07AM -0600, Logan Gunthorpe wrote: > Hi, > > This patchset continues my work to to add P2PDMA support to the common > dma map operations. This allows for creating SGLs that have both P2PDMA > and regular pages which is a necessary step to allowing P2PDMA pages in > userspace. > > The earlier RFC[1] generated a lot of great feedback and I heard no show > stopping objections. Thus, I've incorporated all the feedback and have > decided to post this as a proper patch series with hopes of eventually > getting it in mainline. > > I'm happy to do a few more passes if anyone has any further feedback > or better ideas. For the user of the DMA API the idea seems reasonable enough, the next steps to integrate with pin_user_pages() seem fairly straightfoward too Was there no feedback on this at all? Jason
On 4/27/21 12:28 PM, Jason Gunthorpe wrote: > On Thu, Apr 08, 2021 at 11:01:07AM -0600, Logan Gunthorpe wrote: >> Hi, >> >> This patchset continues my work to to add P2PDMA support to the common >> dma map operations. This allows for creating SGLs that have both P2PDMA >> and regular pages which is a necessary step to allowing P2PDMA pages in >> userspace. >> >> The earlier RFC[1] generated a lot of great feedback and I heard no show >> stopping objections. Thus, I've incorporated all the feedback and have >> decided to post this as a proper patch series with hopes of eventually >> getting it in mainline. >> >> I'm happy to do a few more passes if anyone has any further feedback >> or better ideas. > > For the user of the DMA API the idea seems reasonable enough, the next > steps to integrate with pin_user_pages() seem fairly straightfoward > too > > Was there no feedback on this at all? > oops, I meant to review this a lot sooner, because this whole p2pdma thing is actually very interesting and important...somehow it slipped but I'll take a look now. thanks,
On Tue, Apr 27, 2021 at 1:22 PM John Hubbard <jhubbard@nvidia.com> wrote: > > On 4/27/21 12:28 PM, Jason Gunthorpe wrote: > > On Thu, Apr 08, 2021 at 11:01:07AM -0600, Logan Gunthorpe wrote: > >> Hi, > >> > >> This patchset continues my work to to add P2PDMA support to the common > >> dma map operations. This allows for creating SGLs that have both P2PDMA > >> and regular pages which is a necessary step to allowing P2PDMA pages in > >> userspace. > >> > >> The earlier RFC[1] generated a lot of great feedback and I heard no show > >> stopping objections. Thus, I've incorporated all the feedback and have > >> decided to post this as a proper patch series with hopes of eventually > >> getting it in mainline. > >> > >> I'm happy to do a few more passes if anyone has any further feedback > >> or better ideas. > > > > For the user of the DMA API the idea seems reasonable enough, the next > > steps to integrate with pin_user_pages() seem fairly straightfoward > > too > > > > Was there no feedback on this at all? > > > > oops, I meant to review this a lot sooner, because this whole p2pdma thing is > actually very interesting and important...somehow it slipped but I'll take > a look now. Still in my queue as well behind Joao's memmap consolidation series, and a recent copy_mc_to_iter() fix series from Al.
On 4/8/21 10:01 AM, Logan Gunthorpe wrote: > Hi, > > This patchset continues my work to to add P2PDMA support to the common > dma map operations. This allows for creating SGLs that have both P2PDMA > and regular pages which is a necessary step to allowing P2PDMA pages in > userspace. > > The earlier RFC[1] generated a lot of great feedback and I heard no show > stopping objections. Thus, I've incorporated all the feedback and have > decided to post this as a proper patch series with hopes of eventually > getting it in mainline. > > I'm happy to do a few more passes if anyone has any further feedback > or better ideas. > After an initial pass through these, I think I like the approach. And I don't have any huge structural comments or new ideas, just smaller comments and notes. I'll respond to each patch, but just wanted to say up front that this is looking promising, in my opinion. thanks,
On 4/8/21 1:01 PM, Logan Gunthorpe wrote: > Hi, > > This patchset continues my work to to add P2PDMA support to the common > dma map operations. This allows for creating SGLs that have both P2PDMA > and regular pages which is a necessary step to allowing P2PDMA pages in > userspace. > > The earlier RFC[1] generated a lot of great feedback and I heard no show > stopping objections. Thus, I've incorporated all the feedback and have > decided to post this as a proper patch series with hopes of eventually > getting it in mainline. > > I'm happy to do a few more passes if anyone has any further feedback > or better ideas. > > This series is based on v5.12-rc6 and a git branch can be found here: > > https://github.com/sbates130272/linux-p2pmem/ p2pdma_map_ops_v1 > > Thanks, > > Logan > > [1] https://lore.kernel.org/linux-block/20210311233142.7900-1-logang@deltatee.com/ > > > Changes since the RFC: > * Added comment and fixed up the pci_get_slot patch. (per Bjorn) > * Fixed glaring sg_phys() double offset bug. (per Robin) > * Created a new map operation (dma_map_sg_p2pdma()) with a new calling > convention instead of modifying the calling convention of > dma_map_sg(). (per Robin) > * Integrated the two similar pci_p2pdma_dma_map_type() and > pci_p2pdma_map_type() functions into one (per Ira) > * Reworked some of the logic in the map_sg() implementations into > helpers in the p2pdma code. (per Christoph) > * Dropped a bunch of unnecessary symbol exports (per Christoph) > * Expanded the code in dma_pci_p2pdma_supported() for clarity. (per > Ira and Christoph) > * Finished off using the new dma_map_sg_p2pdma() call in rdma_rw > and removed the old pci_p2pdma_[un]map_sg(). (per Jason) > > -- > > Logan Gunthorpe (16): > PCI/P2PDMA: Pass gfp_mask flags to upstream_bridge_distance_warn() > PCI/P2PDMA: Avoid pci_get_slot() which sleeps > PCI/P2PDMA: Attempt to set map_type if it has not been set > PCI/P2PDMA: Refactor pci_p2pdma_map_type() to take pagmap and device > dma-mapping: Introduce dma_map_sg_p2pdma() > lib/scatterlist: Add flag for indicating P2PDMA segments in an SGL > PCI/P2PDMA: Make pci_p2pdma_map_type() non-static > PCI/P2PDMA: Introduce helpers for dma_map_sg implementations > dma-direct: Support PCI P2PDMA pages in dma-direct map_sg > dma-mapping: Add flags to dma_map_ops to indicate PCI P2PDMA support > iommu/dma: Support PCI P2PDMA pages in dma-iommu map_sg > nvme-pci: Check DMA ops when indicating support for PCI P2PDMA > nvme-pci: Convert to using dma_map_sg_p2pdma for p2pdma pages > nvme-rdma: Ensure dma support when using p2pdma > RDMA/rw: use dma_map_sg_p2pdma() > PCI/P2PDMA: Remove pci_p2pdma_[un]map_sg() > > drivers/infiniband/core/rw.c | 50 +++------- > drivers/iommu/dma-iommu.c | 66 ++++++++++-- > drivers/nvme/host/core.c | 3 +- > drivers/nvme/host/nvme.h | 2 +- > drivers/nvme/host/pci.c | 39 ++++---- > drivers/nvme/target/rdma.c | 3 +- > drivers/pci/Kconfig | 2 +- > drivers/pci/p2pdma.c | 188 +++++++++++++++++++---------------- > include/linux/dma-map-ops.h | 3 + > include/linux/dma-mapping.h | 20 ++++ > include/linux/pci-p2pdma.h | 53 ++++++---- > include/linux/scatterlist.h | 49 ++++++++- > include/rdma/ib_verbs.h | 32 ++++++ > kernel/dma/direct.c | 25 ++++- > kernel/dma/mapping.c | 70 +++++++++++-- > 15 files changed, 416 insertions(+), 189 deletions(-) > > > base-commit: e49d033bddf5b565044e2abe4241353959bc9120 > -- > 2.20.1 > Apologies in the delay to provide feedback; climbing out of several deep trenches at the mother ship :-/ Replying to some directly, and indirectly (mostly through JohH's reply's). General comments: 1) nits in 1,2,3,5; 4: I agree w/JohnH & JasonG -- seems like it needs a device-layer that gets to a bus-layer, but I'm wearing my 'broader then PCI' hat in this review; I see a (classic) ChristophH refactoring and cleanup in this area, and wondering if we ought to clean it up now, since CH has done so much to clean it up and make the dma-mapping system so much easier to add/modify/review due to the broad arch (& bus) cleanup that has been done. If that delays it too much, then add a TODO to do so. 2) 6: yes! let's not worry or even both supporting 32-bit anything wrt p2pdma. 3) 7:nit 4) 8: ok; 5) 9: ditto to JohnH's feedback on added / clearer comment & code flow (if-else). 6) 10: nits; q: should p2pdma mapping go through dma-ops so it is generalized for future interconnects (CXL, GenZ)? 7) 11: It says it is supporting p2pdma in dma-iommu's map_sg, but it seems like it is just leveraging shared code and short-circuiting IOMMU use. 8) 12-14: didn't review; letting the block/nvme/direct-io folks cover this space 9) 15: Looking to JasonG to sanitize 10) 16: cleanup; a-ok. - DonD