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

[Koichiro Den]

On Tue, May 26, 2026 at 07:35:06AM +0200, Niklas Cassel wrote:
> Hello Koichiro,
> 
> On 26 May 2026 04:04:07 CEST, Koichiro Den <den@xxxxxxxxxxxxx> wrote:
> >On Mon, May 25, 2026 at 10:32:06PM +0200, Niklas Cassel wrote:
> >> On 25 May 2026 16:03:35 CEST, Koichiro Den <den@xxxxxxxxxxxxx> wrote:
> >> >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:
> >> >> 
> >> >That restriction should be documented with the new NTB transport, which I will
> >> >submit if the direction taken by this series is acceptable.
> >> 
> >> This is easy for me to say, since I am not the NTB maintainer, but it would be nice if we could somehow come up with a design where we don't only support EPCs that have 'max-functions' != 1, because IIRC, most PCI EPCs have 'max-functions' == 1.
> >
> >Yes, that's fair point. As a quick check on v7.1-rc5, among DWC-based EP nodes,
> >only 6 out of 45 set max-functions > 1 (about 13%). Assuming there are no cases
> >where the hardware supports more functions than the DT advertises, that means only
> >about 13% of DWC-based EP instances described in DT could support the "NTB
> >transport backed by PCI EP DMA" use case. If I also count non-DWC EP nodes, I
> >get 15 out of 64 (about 23%).
> 
> The only DMA "backend" added in your 3-part series is the eDMA in DWC-based controllers.
> 
> So if all three of your series lands, then 13% of the DWC-based endpoint controllers can theoretically use this new feature.
> 
> 
> >
> >If supporting single-function EPCs is a requirement, then the separate PCI DMA
> >EPF model is not a good choice for that NTB transport use case. We would need to
> >keep the DMA delegation metadata inside the vNTB function, or use some other
> >single-function design.
> >
> >That is basically option 2 from my earlier mail:
> >https://lore.kernel.org/linux-pci/xnfnxv64hpil6if4ikyohxnarvsekbmjcc37k5zej264ix46z3@qtu6xj2uy3xi/
> >
> >    [snip]
> >    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/
> >    [snip]
> >
> >Do you prefer the vNTB-integrated model over this series?
> 
> My take:
> 
> I do think that the design in  this series is more elegant that the vNTB-integrated model.
> 
> However, if the design in this series only supports 13% of DWC-based endpoint controllers, when the vNTB-integrated model can support 100% of DWC-based endpoint controllers...
> 
> What good it is to have an elegant design if in reality, it supports drastically fewer SoCs?
> 
> But please don't listen only to my opinion, Mani is the maintainer, so it would be interesting to hear his thoughts as well.

Yes, I also think the architecture of this series is much cleaner. The option 2
series may look like it overloads and complicates vNTB a bit too much, and the
auxiliary device created from ntb_hw_epf only for the channel delegation purpose
may look awkward to some.

The coverage concern is a real downside of this direction though. This is a
trade-off between a cleaner PCI/DMA model and broader EPC coverage. On my side,
R-Car Gen4+ is the main target, so the multi-function requirement is acceptable.
In that sense, I am also curious whether future DWC-based SoCs will typically
support more than one function or not.

Thanks for sharing your thoughts, Niklas. I would also like to hear Mani's view
on this series vs. previous attempts. Any comments from others are also very
welcome.

Best regards,
Koichiro

> 
> 
> Kind regards,
> Niklas