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

[Niklas Cassel <cassel@kernel.org>]

Hello Koichiro,

On 26 May 2026 04:04:07 CEST, Koichiro Den <den@valinux.co.jp> 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@valinux.co.jp> 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@valinux.co.jp/
>    
>       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.


Kind regards,
Niklas