From: Jason Gunthorpe <jgg@ziepe.ca>
To: Leon Romanovsky <leon@kernel.org>
Cc: "Bjorn Helgaas" <helgaas@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Logan Gunthorpe" <logang@deltatee.com>,
"Joerg Roedel (AMD)" <joro@8bytes.org>,
"Will Deacon" <will@kernel.org>,
"Robin Murphy" <robin.murphy@arm.com>,
"Christian König" <christian.koenig@amd.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, iommu@lists.linux.dev,
"Tushar Dave" <tdave@nvidia.com>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-rdma@vger.kernel.org,
kvm@vger.kernel.org, "Chaitanya Kulkarni" <kch@nvidia.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jens Axboe" <axboe@kernel.dk>,
"Alex Williamson" <alex@shazbot.org>,
"Ankit Agrawal" <ankita@nvidia.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <skhan@linuxfoundation.org>,
"Randy Dunlap" <rdunlap@infradead.org>,
"Sumit Semwal" <sumit.semwal@linaro.org>
Subject: Re: [PATCH v13 00/19] PCI/P2PDMA: Route peer-to-peer DMA by TLP class
Date: Fri, 13 Nov 2026 15:59:34 -0400 [thread overview]
Message-ID: <20261113195934.GD2532299@ziepe.ca> (raw)
In-Reply-To: <20261112092326.GU8635@unreal>
On Thu, Nov 12, 2026 at 11:23:26AM +0200, Leon Romanovsky wrote:
> > I guess one benefit of this series is that a path where P2P Completion
> > Redirect is set used to mean that pci_p2pdma_map_type() would return
> > PCI_P2PDMA_MAP_NOT_SUPPORTED (unless the RC was allow-listed), and now
> > it might return PCI_P2PDMA_MAP_BUS_ADDR because if P2P Request
> > Redirect is clear, Requests can be routed directly?
>
> I'm not sure the first part (return PCI_P2PDMA_MAP_NOT_SUPPORTED) is correct,
> since callers have so far ensured that P2P is supported before calling this
> function. The second part is correct.
>
> >
> > That sounds great as long as the Request uses Relaxed Ordering, so the
> > Completion won't be affected by P2P Completion Redirect. But devices
> > aren't *required* to use RO even if enabled, and I'm doubtful that a
> > non-RO Completion redirected to the RC is going to work. So I don't
> > understand how p2pdma.c can guarantee safety.
> >
> > Translated Requests seems similar -- are we assuming that if ACS
> > Direct Translated P2P is set and ATS Enable is set, the device
> > *always* generates Translated Requests?
>
> PCI spec allows "A Function is permitted to intermix translated
> and untranslated requests" and p2p doesn't decide anything except
> if routing is possible or not.
Both of these are basically the question we left open in the
discussion with Christian.
To use this new TLP specific API correctly the initiator needs to tell
the API what kinds of TLPs it intends to generate, and ask if that set
is OK.
So you need to say 'I will use translated, I will use RO, I will use
untranslated' because each of them can have different routing.
NOT_SUPPORTED has to be returned if the modes the driver asks for
don't have identical routing.
I forget how this ended up when that got deferred, but that missing
driver input is an important part of the puzzle.
eg mlx5 knows exactly which of the three TLPs it is going to generate.
Jason
prev parent reply other threads:[~2026-11-13 19:59 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 10:04 [PATCH v13 00/19] PCI/P2PDMA: Route peer-to-peer DMA by TLP class Leon Romanovsky
2026-11-05 10:04 ` [PATCH v13 01/19] PCI/P2PDMA: Honor device-specific ACS redirection Leon Romanovsky
2026-11-05 10:26 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 02/19] PCI/P2PDMA: Document the TLP attribute assumptions Leon Romanovsky
2026-11-05 10:15 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 03/19] PCI/P2PDMA: Derive routing from directional ACS controls Leon Romanovsky
2026-11-05 10:21 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 04/19] PCI: Reject unreadable ACS controls in isolation checks Leon Romanovsky
2026-11-05 10:13 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 05/19] PCI/P2PDMA: Evaluate ACS controls at the path divergence Leon Romanovsky
2026-11-05 10:21 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 06/19] PCI/P2PDMA: Document directional ACS routing Leon Romanovsky
2026-11-05 10:11 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 07/19] PCI/P2PDMA: Collect the path's ACS controls before deciding Leon Romanovsky
2026-11-05 10:15 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 08/19] PCI/P2PDMA: Answer routing per TLP class Leon Romanovsky
2026-11-05 10:22 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 09/19] PCI/P2PDMA: Route Relaxed Ordering Completions directly Leon Romanovsky
2026-11-05 10:12 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 10/19] PCI/P2PDMA: Reject Translated Requests blocked by Translation Blocking Leon Romanovsky
2026-11-05 10:18 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 11/19] PCI/P2PDMA: Route Translated Requests under Direct Translated P2P Leon Romanovsky
2026-11-05 10:14 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 12/19] PCI/P2PDMA: Log detailed ACS routing diagnostics Leon Romanovsky
2026-11-05 10:19 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 13/19] PCI/P2PDMA: Add KUnit tests for the ACS routing decisions Leon Romanovsky
2026-11-05 10:16 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 14/19] PCI/P2PDMA: Test the ACS P2P routing walk Leon Romanovsky
2026-11-05 10:17 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 15/19] PCI: Add KUnit coverage for ACS isolation checks Leon Romanovsky
2026-11-05 10:17 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 16/19] PCI/P2PDMA: Document TLP-class routing Leon Romanovsky
2026-11-05 10:16 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 17/19] PCI/P2PDMA: Let a client declare that it selects ATS per mapping Leon Romanovsky
2026-11-05 10:17 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 18/19] PCI/P2PDMA: Evaluate the ATS path for clients with ATS enabled Leon Romanovsky
2026-11-05 10:34 ` sashiko-bot
2026-11-05 10:04 ` [PATCH v13 19/19] PCI/P2PDMA: Test the routing of " Leon Romanovsky
2026-11-05 10:20 ` sashiko-bot
2026-11-11 12:16 ` [PATCH v13 00/19] PCI/P2PDMA: Route peer-to-peer DMA by TLP class Leon Romanovsky
2026-11-11 22:41 ` Bjorn Helgaas
2026-11-12 9:23 ` Leon Romanovsky
2026-11-13 19:59 ` Jason Gunthorpe [this message]
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=20261113195934.GD2532299@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=alex@shazbot.org \
--cc=ankita@nvidia.com \
--cc=axboe@kernel.dk \
--cc=bhelgaas@google.com \
--cc=christian.koenig@amd.com \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=helgaas@kernel.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kch@nvidia.com \
--cc=kvm@vger.kernel.org \
--cc=leon@kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=rdunlap@infradead.org \
--cc=robin.murphy@arm.com \
--cc=skhan@linuxfoundation.org \
--cc=sumit.semwal@linaro.org \
--cc=tdave@nvidia.com \
--cc=thomas.hellstrom@linux.intel.com \
--cc=will@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