linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	"Stephen Bates" <sbates@raithlin.com>,
	"Christoph Hellwig" <hch@lst.de>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Christian König" <christian.koenig@amd.com>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Don Dutile" <ddutile@redhat.com>
Subject: Re: [PATCH v1 1/6] PCI/P2PDMA: Rename upstream_bridge_distance() and rework documentation
Date: Thu, 10 Jun 2021 17:05:41 -0500	[thread overview]
Message-ID: <20210610220541.GA2779926@bjorn-Precision-5520> (raw)
In-Reply-To: <20210610160609.28447-2-logang@deltatee.com>

On Thu, Jun 10, 2021 at 10:06:04AM -0600, Logan Gunthorpe wrote:
> The function upstream_bridge_distance() has evolved such that it's name
> is no longer entirely reflective of what the function does.
> 
> The function not only calculates the distance between two peers but also
> calculates how the DMA addresses for those two peers should be mapped.
> 
> Thus, rename the function to calc_map_type_and_dist() and rework the
> documentation to better describe the two pieces of information the
> function returns.
> 
> Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
> ---
>  drivers/pci/p2pdma.c | 63 ++++++++++++++++++++++----------------------
>  1 file changed, 32 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index 196382630363..6f90e9812f6e 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -354,7 +354,7 @@ static bool host_bridge_whitelist(struct pci_dev *a, struct pci_dev *b)
>  }
>  
>  static enum pci_p2pdma_map_type
> -__upstream_bridge_distance(struct pci_dev *provider, struct pci_dev *client,
> +__calc_map_type_and_dist(struct pci_dev *provider, struct pci_dev *client,
>  		int *dist, bool *acs_redirects, struct seq_buf *acs_list)
>  {
>  	struct pci_dev *a = provider, *b = client, *bb;
> @@ -433,17 +433,18 @@ static unsigned long map_types_idx(struct pci_dev *client)
>  }
>  
>  /*
> - * Find the distance through the nearest common upstream bridge between
> - * two PCI devices.
> + * Calculate the P2PDMA mapping type and distance between two PCI devices.
>   *
> - * If the two devices are the same device then 0 will be returned.
> + * If the two devices are the same device then PCI_P2PDMA_MAP_BUS_ADDR
> + * and a distance of 0 will be returned.
>   *
>   * If there are two virtual functions of the same device behind the same
> - * bridge port then 2 will be returned (one step down to the PCIe switch,
> - * then one step back to the same device).
> + * bridge port then PCI_P2PDMA_MAP_BUS_ADDR and a distance of 2 will be
> + * returned (one step down to the PCIe switch, then one step back to the
> + * same device).

The new text is:

  If there are two virtual functions of the same device behind the same
  bridge port then PCI_P2PDMA_MAP_BUS_ADDR and a distance of 2 will be
  returned (one step down to the PCIe switch, then one step back to the
  same device).

I *think* this includes two functions of the same multi-function
device, or two virtual functions of the same device, right?  In both
cases, the two devices are obviously behind the same bridge port.

Is this usage of "down to the PCIe switch" the common usage in P2PDMA?
I normally think of going from an endpoint to a switch as being "up"
toward the CPU.  But PCIe made it all confusing by putting downstream
ports at the upstream end of links and vice versa.

We also have a bit of a mix in terminology between "bridge," "switch,"
"bridge port."  I'd probably write something like:

  If they are two functions of the same device behind the same bridge,
  return PCI_P2PDMA_MAP_BUS_ADDR and a distance of 2 (one hop up to
  the bridge, then one hop back down to another function of the same
  device).

No need to repost for this; just let me know what you think and I can
tweak accordingly.

Bjorn

  reply	other threads:[~2021-06-10 22:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-10 16:06 [PATCH v1 0/6] P2PDMA Cleanup Logan Gunthorpe
2021-06-10 16:06 ` [PATCH v1 1/6] PCI/P2PDMA: Rename upstream_bridge_distance() and rework documentation Logan Gunthorpe
2021-06-10 22:05   ` Bjorn Helgaas [this message]
2021-06-10 22:25     ` Logan Gunthorpe
2021-06-10 16:06 ` [PATCH v1 2/6] PCI/P2PDMA: Use a buffer on the stack for collecting the acs list Logan Gunthorpe
2021-06-10 16:06 ` [PATCH v1 3/6] PCI/P2PDMA: Cleanup type for return value of calc_map_type_and_dist() Logan Gunthorpe
2021-06-10 16:06 ` [PATCH v1 4/6] PCI/P2PDMA: Print a warning if the host bridge is not in the whitelist Logan Gunthorpe
2021-06-10 16:06 ` [PATCH v1 5/6] PCI/P2PDMA: Refactor pci_p2pdma_map_type() to take pagemap and device Logan Gunthorpe
2021-06-10 16:06 ` [PATCH v1 6/6] PCI/P2PDMA: Avoid pci_get_slot() which sleeps Logan Gunthorpe
2021-06-10 23:04 ` [PATCH v1 0/6] P2PDMA Cleanup Bjorn Helgaas

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=20210610220541.GA2779926@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=christian.koenig@amd.com \
    --cc=dan.j.williams@intel.com \
    --cc=ddutile@redhat.com \
    --cc=hch@lst.de \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=logang@deltatee.com \
    --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).