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

[Koichiro Den]

On Mon, May 25, 2026 at 10:35:46AM +0200, Niklas Cassel wrote:
> 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@xxxxxxxxxxxxx/
> > 
> > 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@xxxxxxxxxxxxx/
> > 
> >    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,

Hello Niklas,

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

Fair enough. Part 1 describes the use case:
https://lore.kernel.org/dmaengine/20260525062420.3315904-1-den@xxxxxxxxxxxxx/
but part 3 should probably have stated the overall goal as well.

> 
> 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?

I have not submitted the first real consumer code (= NTB transport backed by PCI
EP DMA) yet. I plan to do that after checking whether the direction taken by
this series is acceptable.

That said, the consumer would be something like:
https://lore.kernel.org/ntb/20260118135440.1958279-27-den@xxxxxxxxxxxxx/
although the naming "ntb_transport_edma" is no longer suitable (it would be
"ntb_transport_ep_dma" or something similar). Also, the old RFC holds
dw-edma-specific handling under drivers/ntb/hw, which is what I am trying to
avoid with this series, so the whole drivers/ntb/hw/edma/ would no longer be
needed.

With this direction, the NTB transport would use a DMA engine provider exposed
by the separate PCI DMA EPF, while the data path would still be very close to
the old RFC.

> 
> 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.)

I believe the NTB transport client driver should not request a channel by
capability mask alone, even if a specific dma_transaction_type for this sort of
transfer is added. It will need to know the specific PCI DMA EPF device to use,
for example through configuration. One option would be to let the admin specify
the PCI BDF of the DMA function when loading/configuring the NTB transport
client.

> 
> 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 ?

Yes, for the NTB transport backed by PCI EP DMA, the endpoint side would expose
both functions, vNTB and PCI DMA EPF.

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

No. For example, R-Car S4's PCIe controller supports multi-functions, while
RK3588's PCIe controller seems not. So with this scheme, RK3588 would not
support the NTB transport backed by PCI EP DMA.

That restriction should be documented with the new NTB transport, which I will
submit if the direction taken by this series is acceptable.

Best regards,
Koichiro

> 
> 
> Kind regards,
> Niklas