From: Koichiro Den <den@valinux.co.jp>
To: "Frank Li" <Frank.Li@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Jon Mason" <jdmason@kudzu.us>,
"Dave Jiang" <dave.jiang@intel.com>,
"Allen Hubbe" <allenbh@gmail.com>,
"Niklas Cassel" <cassel@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Jingoo Han <jingoohan1@gmail.com>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Rob Herring <robh@kernel.org>,
Jerome Brunet <jbrunet@baylibre.com>,
linux-pci@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, ntb@lists.linux.dev
Subject: [PATCH v6 0/8] PCI: endpoint: Remote DMA support via vNTB
Date: Tue, 20 Oct 2026 14:49:40 +0900 [thread overview]
Message-ID: <20261020054948.1218370-1-den@valinux.co.jp> (raw)
Hi,
This series lets host Linux use EPC-local DMA read (RC-to-EP) channels
through vNTB. I also tried a separate PCI DMA EPF, which reached v7 [1],
but came back to this vNTB-embedded approach after discussion.
An EPC-local DMA engine can use host DMA addresses (IOVAs when an IOMMU
is enabled) as PCI addresses to reach any host buffer mapped for the
endpoint. Letting the RC side drive its read channels also gives the RC
a direct path into endpoint-local buffers.
A major motivation is direct TX in ntb_transport. Both sides could use
the same dmaengine-based TX path (ie. symmetric), sending directly to RX
buffer DMA addresses supplied by the peer. This would avoid MW bounce
buffers and per-transfer MW remapping for payloads in both directions.
This assumes both sides trust each other. The RC side still programs DMA
over PCIe MMIO, so this is expected to pay off for large data transfers.
DesignWare eDMA is the only supported dmaengine backend for now. Other
EPC-local DMA engines can be added if there is a need and they have a
suitable programming interface.
This series does not include a consumer for the dmaengine channels exposed
to RC Linux. Native HDMA support is also left out to keep the series from
growing too large.
Setting pci-epf-vntb's 'dma_bar' configfs attribute enables DMA export.
The default is -1, which leaves it disabled. pci-epf-ntb only switches to
the shared control layout header and is functionally unchanged.
Dependency
==========
This series has a build dependency on the following dmaengine series,
already in linux-next but not yet in pci/endpoint:
[PATCH v4 0/3] dmaengine: dw-edma: Prepare channels for remote use
https://lore.kernel.org/r/20260912174023.1227397-1-den@valinux.co.jp/
And the following two patches already landed in pci/endpoint.
17c4115cbe99 ("PCI: endpoint: pci-epf-vntb: Use a local epf pointer in interrupt setup")
a5401ce3ab23 ("PCI: endpoint: pci-epf-vntb: Honor MSI-X selection")
Therefore, this submission is (re)based on next-20261019 (3d229ce89862),
with the two patches above applied on top.
Testing
=======
The existing MW-based ntb_netdev path worked with DMA export disabled
(dma_bar = -1) and enabled with the following EP-side BAR settings:
* Dedicated DMA BAR configuration on RK3588 Rock 5B:
ctrl_bar = 0
mw1_bar = 2
db_bar = 4
dma_bar = 5
* MW-shared DMA BAR configuration on R-Car S4 Spider:
ctrl_bar = 0
mw1_bar = 2
dma_bar = 2
db_bar = 4
Best regards,
Koichiro
---
Changes in v6:
- Add a prep patch that moves the control region layout to
include/linux/pci-epf-ntb.h, shared by pci-epf-ntb, pci-epf-vntb and
ntb_hw_epf. (Frank)
For earlier changes, see v5:
https://lore.kernel.org/r/20261009045949.1109871-1-den@valinux.co.jp/
[1] Superseded approach, PCI DMA EPF, v7:
https://lore.kernel.org/r/20260813063757.3131865-1-den@valinux.co.jp/
Koichiro Den (8):
PCI: endpoint: Add DMA auxiliary resource metadata
PCI: dwc: Expose endpoint DMA resources
PCI: endpoint: pci-epf-vntb: Move epf_ntb_is_bar_used() up
PCI: endpoint: Add pci-epf-ntb.h for the shared NTB control layout
PCI: endpoint: pci-epf-vntb: Export endpoint DMA channels
NTB: ntb_hw_epf: Discover vNTB-embedded DMA
PCI/NTB: endpoint: Allow DMA and MW to share a BAR
Documentation: PCI: endpoint: Document vNTB DMA export
Documentation/PCI/endpoint/pci-vntb-howto.rst | 31 +-
MAINTAINERS | 1 +
drivers/ntb/hw/epf/ntb_hw_epf.c | 409 +++++++--
.../pci/controller/dwc/pcie-designware-ep.c | 107 ++-
drivers/pci/endpoint/functions/pci-epf-ntb.c | 85 +-
drivers/pci/endpoint/functions/pci-epf-vntb.c | 783 +++++++++++++++---
include/linux/pci-epc.h | 34 +-
include/linux/pci-epf-ntb.h | 87 ++
8 files changed, 1261 insertions(+), 276 deletions(-)
create mode 100644 include/linux/pci-epf-ntb.h
base-commit: 3d229ce89862b8e82d71a9e11d6f840ca272a6d6
prerequisite-patch-id: f58157e3e05c3723bf60a1e42744c2fbea7d4da8
prerequisite-patch-id: 9e6690c769a60159d50bd9f0a7b66dd269104856
--
2.54.0
next reply other threads:[~2026-10-20 5:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 5:49 Koichiro Den [this message]
2026-10-20 5:49 ` [PATCH v6 1/8] PCI: endpoint: Add DMA auxiliary resource metadata Koichiro Den
2026-10-20 5:49 ` [PATCH v6 2/8] PCI: dwc: Expose endpoint DMA resources Koichiro Den
2026-10-20 5:49 ` [PATCH v6 3/8] PCI: endpoint: pci-epf-vntb: Move epf_ntb_is_bar_used() up Koichiro Den
2026-10-20 5:49 ` [PATCH v6 4/8] PCI: endpoint: Add pci-epf-ntb.h for the shared NTB control layout Koichiro Den
2026-10-20 5:49 ` [PATCH v6 5/8] PCI: endpoint: pci-epf-vntb: Export endpoint DMA channels Koichiro Den
2026-10-20 17:00 ` Frank Li
2026-10-20 5:49 ` [PATCH v6 6/8] NTB: ntb_hw_epf: Discover vNTB-embedded DMA Koichiro Den
2026-10-20 17:03 ` Frank Li
2026-10-20 5:49 ` [PATCH v6 7/8] PCI/NTB: endpoint: Allow DMA and MW to share a BAR Koichiro Den
2026-10-20 17:11 ` Frank Li
2026-10-21 1:39 ` Koichiro Den
2026-10-20 5:49 ` [PATCH v6 8/8] Documentation: PCI: endpoint: Document vNTB DMA export Koichiro Den
2026-10-20 18:49 ` Frank Li
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=20261020054948.1218370-1-den@valinux.co.jp \
--to=den@valinux.co.jp \
--cc=Frank.Li@kernel.org \
--cc=allenbh@gmail.com \
--cc=bhelgaas@google.com \
--cc=cassel@kernel.org \
--cc=corbet@lwn.net \
--cc=dave.jiang@intel.com \
--cc=jbrunet@baylibre.com \
--cc=jdmason@kudzu.us \
--cc=jingoohan1@gmail.com \
--cc=kishon@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=ntb@lists.linux.dev \
--cc=rdunlap@infradead.org \
--cc=robh@kernel.org \
--cc=skhan@linuxfoundation.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
all inboxes | Powered by JetHome®