From: helgaas@kernel.org (Bjorn Helgaas)
Subject: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory
Date: Wed, 14 Mar 2018 13:51:59 -0500 [thread overview]
Message-ID: <20180314185159.GD179719@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <112493af-ccd0-455b-6600-b50764f7ab7e@deltatee.com>
On Wed, Mar 14, 2018@10:17:34AM -0600, Logan Gunthorpe wrote:
> On 13/03/18 08:56 PM, Bjorn Helgaas wrote:
> > I agree that peers need to have a common upstream bridge. I think
> > you're saying peers need to have *two* common upstream bridges. If I
> > understand correctly, requiring two common bridges is a way to ensure
> > that peers directly below Root Ports don't try to DMA to each other.
>
> No, I don't get where you think we need to have two common upstream
> bridges. I'm not sure when such a case would ever happen. But you seem
> to understand based on what you wrote below.
Sorry, I phrased that wrong. You don't require two common upstream
bridges; you require two upstream bridges, with the upper one being
common, i.e.,
static struct pci_dev *get_upstream_bridge_port(struct pci_dev *pdev)
{
struct pci_dev *up1, *up2;
up1 = pci_dev_get(pci_upstream_bridge(pdev));
up2 = pci_dev_get(pci_upstream_bridge(up1));
return up2;
}
So if you're starting with pdev, up1 is the immediately upstream
bridge and up2 is the second upstream bridge. If this is PCIe, up1
may be a Root Port and there is no up2, or up1 and up2 are in a
switch.
This is more restrictive than the spec requires. As long as there is
a single common upstream bridge, peer-to-peer DMA should work. In
fact, in conventional PCI, I think the upstream bridge could even be
the host bridge (not a PCI-to-PCI bridge).
You are focused on PCIe systems, and in those systems, most topologies
do have an upstream switch, which means two upstream bridges. I'm
trying to remove that assumption because I don't think there's a
requirement for it in the spec. Enforcing this assumption complicates
the code and makes it harder to understand because the reader says
"huh, I know peer-to-peer DMA should work inside any PCI hierarchy*,
so why do we need these two bridges?"
[*] For conventional PCI, this means anything below the same host
bridge. Two devices on a conventional PCI root bus should be able to
DMA to each other, even though there's no PCI-to-PCI bridge above
them. For PCIe, it means a "hierarchy domain" as used in PCIe r4.0,
sec 1.3.1, i.e., anything below the same Root Port.
> > So I guess the first order of business is to nail down whether peers
> > below a Root Port are prohibited from DMAing to each other. My
> > assumption, based on 6.12.1.2 and the fact that I haven't yet found
> > a prohibition, is that they can.
>
> If you have a multifunction device designed to DMA to itself below a
> root port, it can. But determining this is on a device by device basis,
> just as determining whether a root complex can do peer to peer is on a
> per device basis. So I'd say we don't want to allow it by default and
> let someone who has such a device figure out what's necessary if and
> when one comes along.
It's not the job of this infrastructure to answer the device-dependent
question of whether DMA initiators or targets support peer-to-peer
DMA.
All we want to do here is figure out whether the PCI topology supports
it, using the mechanisms guaranteed by the spec. We can derive that
from the basic rules about how PCI bridges work, i.e., from the
PCI-to-PCI Bridge spec r1.2, sec 4.3:
A bridge forwards PCI memory transactions from its primary interface
to its secondary interface (downstream) if a memory address is in
the range defined by the Memory Base and Memory Limit registers
(when the base is less than or equal to the limit) as illustrated in
Figure 4-3. Conversely, a memory transaction on the secondary
interface that is within this address range will not be forwarded
upstream to the primary interface. Any memory transactions on the
secondary interface that are outside this address range will be
forwarded upstream to the primary interface (provided they are not
in the address range defined by the prefetchable memory address
range registers).
This works for either PCI or PCIe. The only wrinkle PCIe adds is that
the very top of the hierarchy is a Root Port, and we can't rely on it
to route traffic to other Root Ports. I also doubt Root Complex
Integrated Endpoints can participate in peer-to-peer DMA.
Thanks for your patience in working through all this. I know it
sometimes feels like being bounced around in all directions. It's
just a normal consequence of trying to add complex functionality to an
already complex system, with interest and expertise spread unevenly
across a crowd of people.
Bjorn
next prev parent reply other threads:[~2018-03-14 18:51 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-12 19:35 [PATCH v3 00/11] Copy Offload in NVMe Fabrics with P2P PCI Memory Logan Gunthorpe
2018-03-12 19:35 ` [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory Logan Gunthorpe
2018-03-13 3:28 ` Sinan Kaya
2018-03-13 16:43 ` Logan Gunthorpe
2018-03-13 17:49 ` Sinan Kaya
2018-03-13 18:44 ` Logan Gunthorpe
2018-03-13 19:10 ` Sinan Kaya
2018-03-13 19:19 ` Logan Gunthorpe
2018-03-13 19:53 ` Sinan Kaya
2018-03-13 20:46 ` Logan Gunthorpe
2018-03-13 21:22 ` Sinan Kaya
2018-03-13 22:00 ` Logan Gunthorpe
2018-03-13 22:29 ` Sinan Kaya
2018-03-13 22:45 ` Stephen Bates
2018-03-13 22:48 ` Logan Gunthorpe
2018-03-13 23:19 ` Sinan Kaya
2018-03-13 23:45 ` Logan Gunthorpe
2018-03-14 12:16 ` David Laight
2018-03-14 16:23 ` Logan Gunthorpe
2018-03-13 22:31 ` Stephen Bates
2018-03-13 23:08 ` Bjorn Helgaas
2018-03-13 23:21 ` Logan Gunthorpe
2018-03-14 2:56 ` Bjorn Helgaas
2018-03-14 14:05 ` Stephen Bates
2018-03-14 16:17 ` Logan Gunthorpe
2018-03-14 18:51 ` Bjorn Helgaas [this message]
2018-03-14 19:03 ` Logan Gunthorpe
2018-03-14 19:28 ` Dan Williams
2018-03-14 19:30 ` Logan Gunthorpe
2018-03-14 19:34 ` Stephen Bates
2018-03-15 4:00 ` Martin K. Petersen
2018-03-15 4:30 ` Dan Williams
2018-03-22 22:57 ` Stephen Bates
2018-03-23 21:50 ` Bjorn Helgaas
2018-03-23 21:59 ` Logan Gunthorpe
2018-03-24 3:49 ` Bjorn Helgaas
2018-03-24 15:28 ` Stephen Bates
2018-03-26 15:43 ` Logan Gunthorpe
2018-03-26 11:11 ` Jonathan Cameron
2018-03-26 14:01 ` Bjorn Helgaas
2018-03-26 15:46 ` Logan Gunthorpe
2018-03-27 8:47 ` Jonathan Cameron
2018-03-27 15:37 ` Logan Gunthorpe
2018-04-13 21:56 ` Stephen Bates
2018-03-26 16:41 ` Jason Gunthorpe
2018-03-26 17:30 ` Logan Gunthorpe
2018-03-26 19:35 ` Jason Gunthorpe
2018-03-26 20:42 ` Logan Gunthorpe
2018-03-13 18:40 ` Logan Gunthorpe
2018-03-12 19:35 ` [PATCH v3 02/11] PCI/P2PDMA: Add sysfs group to display p2pmem stats Logan Gunthorpe
2018-03-12 19:35 ` [PATCH v3 03/11] PCI/P2PDMA: Add PCI p2pmem dma mappings to adjust the bus offset Logan Gunthorpe
2018-03-12 19:35 ` [PATCH v3 04/11] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches Logan Gunthorpe
2018-03-12 19:35 ` [PATCH v3 05/11] PCI/P2PDMA: Add P2P DMA driver writer's documentation Logan Gunthorpe
2018-03-12 19:41 ` Jonathan Corbet
2018-03-12 21:18 ` Logan Gunthorpe
2018-03-12 19:35 ` [PATCH v3 06/11] block: Introduce PCI P2P flags for request and request queue Logan Gunthorpe
2018-03-21 9:27 ` Christoph Hellwig
2018-03-12 19:35 ` [PATCH v3 07/11] IB/core: Ensure we map P2P memory correctly in rdma_rw_ctx_[init|destroy]() Logan Gunthorpe
2018-03-21 9:27 ` Christoph Hellwig
2018-03-12 19:35 ` [PATCH v3 08/11] nvme-pci: Use PCI p2pmem subsystem to manage the CMB Logan Gunthorpe
2018-03-13 1:55 ` Sinan Kaya
2018-03-13 1:58 ` Sinan Kaya
2018-03-12 19:35 ` [PATCH v3 09/11] nvme-pci: Add support for P2P memory in requests Logan Gunthorpe
2018-03-21 9:23 ` Christoph Hellwig
2018-03-12 19:35 ` [PATCH v3 10/11] nvme-pci: Add a quirk for a pseudo CMB Logan Gunthorpe
2018-03-12 19:35 ` [PATCH v3 11/11] nvmet: Optionally use PCI P2P memory Logan Gunthorpe
2018-03-21 9:27 ` Christoph Hellwig
2018-03-21 16:52 ` 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=20180314185159.GD179719@bhelgaas-glaptop.roam.corp.google.com \
--to=helgaas@kernel.org \
/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