linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: Christoph Hellwig <hch@lst.de>,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-nvme@lists.infradead.org, linux-rdma@vger.kernel.org,
	Bjorn Helgaas <bhelgaas@google.com>,
	Christian Koenig <Christian.Koenig@amd.com>,
	Jason Gunthorpe <jgg@mellanox.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 08:10:05 +0200	[thread overview]
Message-ID: <20190725061005.GB24875@lst.de> (raw)
In-Reply-To: <7173a4dd-0c9c-48de-98cd-93513313fd8d@deltatee.com>

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.

> > 
> >> +	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);
> >> +	else
> >> +		return __pci_p2pdma_map_sg(pgmap, dev, sg, nents);
> > 
> > Can't we organize the values so that we can switch on the return
> > value instead of doing flag checks?
> 
> Sorry, I don't follow what you are saying here. If you mean for
> upstream_bridge_distance() to just return how to map and not the
> distance that would interfere with other uses of that function.

The point is that in the map path we don't even care about the
distance.  I think we should just have a function that returns the
P2PDMA_ values from the xarray (maybe also store it there as two
values, but that isn't quite as important), and get rid of even
the concept of distance in the map path. e.g.:

	switch (pci_p2pdma_supported(pgmap->pci_p2pdma_provider, client))) {
	case P2PDMA_HOST_BRIDGE:
		return dma_map_sg_attrs(dev, sg, nents, dir, attrs);
	case P2PDMA_SWITCH:
		return __pci_p2pdma_map_sg(pgmap, dev, sg, nents);
	default:
		WARN_ON_ONCE(1);
		return 0;
	}

  reply	other threads:[~2019-07-25  6:10 UTC|newest]

Thread overview: 40+ 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 ` [PATCH 01/14] PCI/P2PDMA: Add constants for not-supported result upstream_bridge_distance() Logan Gunthorpe
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 ` [PATCH 03/14] PCI/P2PDMA: Apply host bridge white list for ACS Logan Gunthorpe
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 ` [PATCH 05/14] PCI/P2PDMA: Factor out host_bridge_whitelist() Logan Gunthorpe
2019-07-22 23:08 ` [PATCH 06/14] PCI/P2PDMA: Add whitelist support for Intel Host Bridges Logan Gunthorpe
2019-07-25 18:52   ` Jason 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-24  6:32   ` Christoph Hellwig
2019-07-24 15:50     ` Logan Gunthorpe
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 ` [PATCH 09/14] PCI/P2PDMA: Introduce pci_p2pdma_unmap_sg() 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 ` [PATCH 11/14] PCI/P2PDMA: dma_map P2PDMA map requests that traverse the host bridge Logan Gunthorpe
2019-07-24  6:32   ` Christoph Hellwig
2019-07-24 15:58     ` Logan Gunthorpe
2019-07-25  6:10       ` Christoph Hellwig [this message]
2019-07-25 16:00         ` Logan Gunthorpe
2019-07-25 16:34           ` Jason Gunthorpe
2019-07-25 17:22             ` Logan Gunthorpe
2019-07-25 18:58   ` Jason Gunthorpe
2019-07-25 19:17     ` Logan Gunthorpe
2019-07-25 19:29       ` Jason 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 ` [PATCH 13/14] PCI/P2PDMA: Update documentation for pci_p2pdma_distance_many() Logan Gunthorpe
2019-07-22 23:08 ` [PATCH 14/14] PCI/P2PDMA: Introduce pci_p2pdma_[un]map_resource() Logan Gunthorpe
2019-07-23 16:28   ` Koenig, Christian
2019-07-23 16:58     ` Logan Gunthorpe
2019-07-24  6:32   ` Christoph Hellwig
2019-07-24 16:06     ` Logan Gunthorpe
2019-07-25 11:50       ` Christoph Hellwig
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: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=20190725061005.GB24875@lst.de \
    --to=hch@lst.de \
    --cc=Christian.Koenig@amd.com \
    --cc=axboe@fb.com \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=epilmore@gigaio.com \
    --cc=jgg@mellanox.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).