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 16:34:44 +0000 [thread overview]
Message-ID: <20190725163438.GF7450@mellanox.com> (raw)
In-Reply-To: <fb39485a-2914-bac4-b249-e1f4ecc8d2be@deltatee.com>
On Thu, Jul 25, 2019@10:00:25AM -0600, Logan Gunthorpe wrote:
>
>
> On 2019-07-25 12:10 a.m., Christoph Hellwig wrote:
> > On Wed, Jul 24, 2019@09:58:59AM -0600, Logan Gunthorpe wrote:
> >>
> >>
> >> On 2019-07-24 12:32 a.m., Christoph Hellwig wrote:
> >>>> 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;
> >>>>
> >>>> + dist = upstream_bridge_distance(pgmap->pci_p2pdma_provider,
> >>>> + client, NULL);
> >>>
> >>> Doing this on every mapping call sounds expensive..
> >>
> >> The result of this function is cached in an xarray (per patch 4) so, on
> >> the hot path, it should just be a single xa_load() which should be a
> >> relatively fast lookup which is similarly used for other hot path
> >> operations.
> >
> > We don't cache find_parent_pci_dev, though. So we should probably
> > export find_parent_pci_dev with a proper namespaces name and cache
> > that in the caler.
>
> Oh, yes, I'll take a look at this. Of the two callers: NVMe should be
> easy we could just pass the PCI device instead of the struct device.
> RDMA is significantly more unclear: would you add a pci_dev to struct
> ib_device? Or maybe we should be able to simply rely on the fact that
> the DMA device *must* be a PCI device and just use to_pci_dev() directly?
AFAIK you need to use the ib_device->dma_device and add some kind of
is_pci_dev to make it safe
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@mellanox.com>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: Christoph Hellwig <hch@lst.de>,
"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>,
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 16:34:44 +0000 [thread overview]
Message-ID: <20190725163438.GF7450@mellanox.com> (raw)
In-Reply-To: <fb39485a-2914-bac4-b249-e1f4ecc8d2be@deltatee.com>
On Thu, Jul 25, 2019 at 10:00:25AM -0600, Logan Gunthorpe wrote:
>
>
> On 2019-07-25 12:10 a.m., Christoph Hellwig wrote:
> > On Wed, Jul 24, 2019 at 09:58:59AM -0600, Logan Gunthorpe wrote:
> >>
> >>
> >> On 2019-07-24 12:32 a.m., Christoph Hellwig wrote:
> >>>> 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;
> >>>>
> >>>> + dist = upstream_bridge_distance(pgmap->pci_p2pdma_provider,
> >>>> + client, NULL);
> >>>
> >>> Doing this on every mapping call sounds expensive..
> >>
> >> The result of this function is cached in an xarray (per patch 4) so, on
> >> the hot path, it should just be a single xa_load() which should be a
> >> relatively fast lookup which is similarly used for other hot path
> >> operations.
> >
> > We don't cache find_parent_pci_dev, though. So we should probably
> > export find_parent_pci_dev with a proper namespaces name and cache
> > that in the caler.
>
> Oh, yes, I'll take a look at this. Of the two callers: NVMe should be
> easy we could just pass the PCI device instead of the struct device.
> RDMA is significantly more unclear: would you add a pci_dev to struct
> ib_device? Or maybe we should be able to simply rely on the fact that
> the DMA device *must* be a PCI device and just use to_pci_dev() directly?
AFAIK you need to use the ib_device->dma_device and add some kind of
is_pci_dev to make it safe
Jason
next prev parent reply other threads:[~2019-07-25 16:34 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 [this message]
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
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=20190725163438.GF7450@mellanox.com \
--to=jgg@mellanox.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.