All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@mellanox.com>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Christoph Hellwig <hch@lst.de>,
	Christian Koenig <Christian.Koenig@amd.com>,
	Sagi Grimberg <sagi@grimberg.me>, Keith Busch <kbusch@kernel.org>,
	Jens Axboe <axboe@fb.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Eric Pilmore <epilmore@gigaio.com>,
	Stephen Bates <sbates@raithlin.com>
Subject: Re: [PATCH 11/14] PCI/P2PDMA: dma_map P2PDMA map requests that traverse the host bridge
Date: Thu, 25 Jul 2019 19:29:49 +0000	[thread overview]
Message-ID: <20190725192944.GI7450@mellanox.com> (raw)
In-Reply-To: <cf61d237-8a8a-e3ac-a9df-466f20b63020@deltatee.com>

On Thu, Jul 25, 2019 at 01:17:02PM -0600, Logan Gunthorpe wrote:
> 
> 
> On 2019-07-25 12:58 p.m., Jason Gunthorpe wrote:
> > On Mon, Jul 22, 2019 at 05:08:56PM -0600, Logan Gunthorpe wrote:
> >> Any requests that traverse the host bridge will need to be mapped into
> >> the IOMMU, so call dma_map_sg() inside pci_p2pdma_map_sg() when
> >> appropriate.
> >>
> >> Similarly, call dma_unmap_sg() inside pci_p2pdma_unmap_sg().
> >>
> >> Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
> >>  drivers/pci/p2pdma.c | 31 ++++++++++++++++++++++++++++++-
> >>  1 file changed, 30 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> >> index 5f43f92f9336..76f51678342c 100644
> >> +++ b/drivers/pci/p2pdma.c
> >> @@ -830,8 +830,22 @@ int pci_p2pdma_map_sg_attrs(struct device *dev, struct scatterlist *sg,
> >>  		int nents, enum dma_data_direction dir, unsigned long attrs)
> >>  {
> >>  	struct dev_pagemap *pgmap = sg_page(sg)->pgmap;
> >> +	struct pci_dev *client;
> >> +	int dist;
> >> +
> >> +	client = find_parent_pci_dev(dev);
> >> +	if (WARN_ON_ONCE(!client))
> >> +		return 0;
> >>  
> >> -	return __pci_p2pdma_map_sg(pgmap, dev, sg, nents);
> >> +	dist = upstream_bridge_distance(pgmap->pci_p2pdma_provider,
> >> +					client, NULL);

Isn't is a bit of a leap to assume that the pgmap is uniform across
all the sgs?

> >> +	if (WARN_ON_ONCE(dist & P2PDMA_NOT_SUPPORTED))
> >> +		return 0;
> >> +
> >> +	if (dist & P2PDMA_THRU_HOST_BRIDGE)
> >> +		return dma_map_sg_attrs(dev, sg, nents, dir, attrs);
> > 
> > IIRC at this point the SG will have struct page references to the BAR
> > memory - so (all?) the IOMMU drivers are able to handle P2P setup in
> > this case?
> 
> Yes. The IOMMU drivers refer to the physical address for BAR which they
> can get from the struct page. And this works fine today.

Interesting.

So, for the places where we already map BAR memory to userspace, if I
were to make struct pages for those BARs and use vm_insert_page()
instead of io_remap_pfn_range(), then the main thing missing in RDMA
to actually do P2P DMA is a way to get those struct pages out of
get_user_pages and know to call the pci_p2pdma_map_sg version (ie in
ib_umem_get())?

Jason

WARNING: multiple messages have this Message-ID (diff)
From: jgg@mellanox.com (Jason Gunthorpe)
Subject: [PATCH 11/14] PCI/P2PDMA: dma_map P2PDMA map requests that traverse the host bridge
Date: Thu, 25 Jul 2019 19:29:49 +0000	[thread overview]
Message-ID: <20190725192944.GI7450@mellanox.com> (raw)
In-Reply-To: <cf61d237-8a8a-e3ac-a9df-466f20b63020@deltatee.com>

On Thu, Jul 25, 2019@01:17:02PM -0600, Logan Gunthorpe wrote:
> 
> 
> On 2019-07-25 12:58 p.m., Jason Gunthorpe wrote:
> > On Mon, Jul 22, 2019@05:08:56PM -0600, Logan Gunthorpe wrote:
> >> Any requests that traverse the host bridge will need to be mapped into
> >> the IOMMU, so call dma_map_sg() inside pci_p2pdma_map_sg() when
> >> appropriate.
> >>
> >> Similarly, call dma_unmap_sg() inside pci_p2pdma_unmap_sg().
> >>
> >> Signed-off-by: Logan Gunthorpe <logang at deltatee.com>
> >>  drivers/pci/p2pdma.c | 31 ++++++++++++++++++++++++++++++-
> >>  1 file changed, 30 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> >> index 5f43f92f9336..76f51678342c 100644
> >> +++ b/drivers/pci/p2pdma.c
> >> @@ -830,8 +830,22 @@ int pci_p2pdma_map_sg_attrs(struct device *dev, struct scatterlist *sg,
> >>  		int nents, enum dma_data_direction dir, unsigned long attrs)
> >>  {
> >>  	struct dev_pagemap *pgmap = sg_page(sg)->pgmap;
> >> +	struct pci_dev *client;
> >> +	int dist;
> >> +
> >> +	client = find_parent_pci_dev(dev);
> >> +	if (WARN_ON_ONCE(!client))
> >> +		return 0;
> >>  
> >> -	return __pci_p2pdma_map_sg(pgmap, dev, sg, nents);
> >> +	dist = upstream_bridge_distance(pgmap->pci_p2pdma_provider,
> >> +					client, NULL);

Isn't is a bit of a leap to assume that the pgmap is uniform across
all the sgs?

> >> +	if (WARN_ON_ONCE(dist & P2PDMA_NOT_SUPPORTED))
> >> +		return 0;
> >> +
> >> +	if (dist & P2PDMA_THRU_HOST_BRIDGE)
> >> +		return dma_map_sg_attrs(dev, sg, nents, dir, attrs);
> > 
> > IIRC at this point the SG will have struct page references to the BAR
> > memory - so (all?) the IOMMU drivers are able to handle P2P setup in
> > this case?
> 
> Yes. The IOMMU drivers refer to the physical address for BAR which they
> can get from the struct page. And this works fine today.

Interesting.

So, for the places where we already map BAR memory to userspace, if I
were to make struct pages for those BARs and use vm_insert_page()
instead of io_remap_pfn_range(), then the main thing missing in RDMA
to actually do P2P DMA is a way to get those struct pages out of
get_user_pages and know to call the pci_p2pdma_map_sg version (ie in
ib_umem_get())?

Jason

  reply	other threads:[~2019-07-25 19:29 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-22 23:08 [PATCH 00/14] PCI/P2PDMA: Support transactions that hit the host bridge Logan Gunthorpe
2019-07-22 23:08 ` Logan Gunthorpe
2019-07-22 23:08 ` [PATCH 01/14] PCI/P2PDMA: Add constants for not-supported result upstream_bridge_distance() Logan Gunthorpe
2019-07-22 23:08   ` Logan Gunthorpe
2019-07-23 16:20   ` Koenig, Christian
2019-07-23 16:20     ` Koenig, Christian
2019-07-22 23:08 ` [PATCH 02/14] PCI/P2PDMA: Factor out __upstream_bridge_distance() Logan Gunthorpe
2019-07-22 23:08   ` Logan Gunthorpe
2019-07-22 23:08 ` [PATCH 03/14] PCI/P2PDMA: Apply host bridge white list for ACS Logan Gunthorpe
2019-07-22 23:08   ` Logan Gunthorpe
2019-07-23 16:23   ` Koenig, Christian
2019-07-23 16:23     ` Koenig, Christian
2019-07-22 23:08 ` [PATCH 04/14] PCI/P2PDMA: Cache the result of upstream_bridge_distance() Logan Gunthorpe
2019-07-22 23:08   ` Logan Gunthorpe
2019-07-22 23:08 ` [PATCH 05/14] PCI/P2PDMA: Factor out host_bridge_whitelist() Logan Gunthorpe
2019-07-22 23:08   ` Logan Gunthorpe
2019-07-22 23:08 ` [PATCH 06/14] PCI/P2PDMA: Add whitelist support for Intel Host Bridges Logan Gunthorpe
2019-07-22 23:08   ` Logan Gunthorpe
2019-07-25 18:52   ` Jason Gunthorpe
2019-07-25 18:52     ` Jason Gunthorpe
2019-07-25 19:14     ` Logan Gunthorpe
2019-07-25 19:14       ` Logan Gunthorpe
2019-07-22 23:08 ` [PATCH 07/14] PCI/P2PDMA: Add the provider's pci_dev to the dev_pgmap struct Logan Gunthorpe
2019-07-22 23:08   ` Logan Gunthorpe
2019-07-24  6:32   ` Christoph Hellwig
2019-07-24  6:32     ` Christoph Hellwig
2019-07-24 15:50     ` Logan Gunthorpe
2019-07-24 15:50       ` Logan Gunthorpe
2019-07-25  6:02       ` Christoph Hellwig
2019-07-25  6:02         ` Christoph Hellwig
2019-07-22 23:08 ` [PATCH 08/14] PCI/P2PDMA: Add attrs argument to pci_p2pdma_map_sg() Logan Gunthorpe
2019-07-22 23:08   ` Logan Gunthorpe
2019-07-22 23:08 ` [PATCH 09/14] PCI/P2PDMA: Introduce pci_p2pdma_unmap_sg() Logan Gunthorpe
2019-07-22 23:08   ` Logan Gunthorpe
2019-07-22 23:08 ` [PATCH 10/14] PCI/P2PDMA: Factor out __pci_p2pdma_map_sg() Logan Gunthorpe
2019-07-22 23:08   ` Logan Gunthorpe
2019-07-22 23:08 ` [PATCH 11/14] PCI/P2PDMA: dma_map P2PDMA map requests that traverse the host bridge Logan Gunthorpe
2019-07-22 23:08   ` Logan Gunthorpe
2019-07-24  6:32   ` Christoph Hellwig
2019-07-24  6:32     ` Christoph Hellwig
2019-07-24 15:58     ` Logan Gunthorpe
2019-07-24 15:58       ` Logan Gunthorpe
2019-07-25  6:10       ` Christoph Hellwig
2019-07-25  6:10         ` Christoph Hellwig
2019-07-25 16:00         ` Logan Gunthorpe
2019-07-25 16:00           ` Logan Gunthorpe
2019-07-25 16:34           ` Jason Gunthorpe
2019-07-25 16:34             ` Jason Gunthorpe
2019-07-25 17:22             ` Logan Gunthorpe
2019-07-25 17:22               ` Logan Gunthorpe
2019-07-25 18:58   ` Jason Gunthorpe
2019-07-25 18:58     ` Jason Gunthorpe
2019-07-25 19:17     ` Logan Gunthorpe
2019-07-25 19:17       ` Logan Gunthorpe
2019-07-25 19:29       ` Jason Gunthorpe [this message]
2019-07-25 19:29         ` Jason Gunthorpe
2019-07-25 19:36         ` Logan Gunthorpe
2019-07-25 19:36           ` Logan Gunthorpe
2019-07-22 23:08 ` [PATCH 12/14] PCI/P2PDMA: No longer require no-mmu for host bridge whitelist Logan Gunthorpe
2019-07-22 23:08   ` Logan Gunthorpe
2019-07-22 23:08 ` [PATCH 13/14] PCI/P2PDMA: Update documentation for pci_p2pdma_distance_many() Logan Gunthorpe
2019-07-22 23:08   ` Logan Gunthorpe
2019-07-22 23:08 ` [PATCH 14/14] PCI/P2PDMA: Introduce pci_p2pdma_[un]map_resource() Logan Gunthorpe
2019-07-22 23:08   ` Logan Gunthorpe
2019-07-23 16:28   ` Koenig, Christian
2019-07-23 16:28     ` Koenig, Christian
2019-07-23 16:58     ` Logan Gunthorpe
2019-07-23 16:58       ` Logan Gunthorpe
2019-07-24  6:32   ` Christoph Hellwig
2019-07-24  6:32     ` Christoph Hellwig
2019-07-24 16:06     ` Logan Gunthorpe
2019-07-24 16:06       ` Logan Gunthorpe
2019-07-25 11:50       ` Christoph Hellwig
2019-07-25 11:50         ` Christoph Hellwig
2019-07-25 16:00         ` Logan Gunthorpe
2019-07-25 16:00           ` Logan Gunthorpe
2019-07-23 16:30 ` [PATCH 00/14] PCI/P2PDMA: Support transactions that hit the host bridge Koenig, Christian
2019-07-23 16:30   ` Koenig, Christian
2019-07-23 16:58   ` Logan Gunthorpe
2019-07-23 16:58     ` Logan Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190725192944.GI7450@mellanox.com \
    --to=jgg@mellanox.com \
    --cc=Christian.Koenig@amd.com \
    --cc=axboe@fb.com \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=epilmore@gigaio.com \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=sagi@grimberg.me \
    --cc=sbates@raithlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.