Re: [PATCH v2 0/3] PCI: endpoint: Add PCI DMA endpoint function (part 3/3)

[Niklas Cassel <cassel@kernel.org>]

On Mon, May 25, 2026 at 04:05:02PM +0900, Koichiro Den wrote:
> 
> I would like to ask you for your high-level opinion on the direction of this
> series.
> 
> Previously, I have tried two different approaches for the same objective:
> avoiding the extra CPU memcpy (or local DMA memcpy) in NTB transport on both EP
> and RC sides.
> 
> 1. Put dw-edma-specific handling under drivers/ntb/hw and let the (new) NTB
>    driver carry the metadata needed for channel delegation.
> 
>    [RFC PATCH v4 00/38] NTB transport backed by PCI EP embedded DMA
>    https://lore.kernel.org/all/20260118135440.1958279-1-den@valinux.co.jp/
> 
> 2. Treat endpoint DMA as a first-class part of vNTB. The RC-side ntb_hw_epf
>    would create an auxiliary device, and a new dw-edma-aux driver would create
>    the delegated DMA channels on the RC side.
> 
>    [PATCH 00/15] PCI: endpoint: Remote DMA support via vNTB
>    https://lore.kernel.org/linux-pci/20260312165005.1148676-1-den@valinux.co.jp/
> 
>    I added an ASCII diagram for the overview as a follow-up comment here:
>    https://lore.kernel.org/all/sn67hi7kljh7cgmgodatb3naz2astlaklqfobdbxyyzgoohxqb@4nnetbhqwba4/)
> 
> Now, this v2 series takes a third direction. It moves the DMA controller out of
> vNTB/NTB-specific ABI and exposes it as a separate PCI endpoint DMA function.
> The host then discovers it as a DMA controller function. The initial host-side
> driver is the existing dw-edma-pcie driver, and dw-edma-aux is no longer needed.
> 
> My current thinking is that this is the cleanest among the previous attempts.
> But this is mostly an architecture question, so I would like to know whether
> this direction looks acceptable to you.
> 
> In short, do you agree with the direction of this series, that endpoint DMA
> channel delegation should be modeled as a separate PCI endpoint DMA function?
> 
> If you think the vNTB-integrated direction is preferable, or if this should be
> modeled differently in the endpoint framework, I would rather adjust the
> direction as early as possible, before building the NTB transport on top of it.

Hello Koichiro,

I think it would have been nice if your overall goal was more clearly
described in the cover letter.

AFAICT, you goal is for "upper layer NTB consumers" to be able to use these
DMA channels.


Since these DMAengine channels will exposed on the host side, I assume that
these "upper layer NTB consumers" are also on the host side.
Could you perhaps give some specific examples of drivers on the host side
that will use these DMA channels?

How will these drivers on the host side know to use the correct DMA channel,
i.e. the DMA channel that is backed by this new PCI DMA EPF?
(And not some other random DMA channel, in case the SoC has multiple DMA
channels.)

If you need to configure your endpoint SoC to bind to the PCI DMA EPF,
don't you need the endpoint SoC to bind to the pci-epf-ntb or pci-epf-vntb
driver? I know that some endpoint controllers can bind to multiple EPFs.
Is the intention for the endpoint SoC to bind both to this new and PCI
DMA EPF and pci-epf-vntb ?

If so, but do really all endpoint controllers / endpoint controller drivers
support binding to multiple EPFs?


Kind regards,
Niklas