Re: [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function

[Niklas Cassel]

On Fri, Aug 14, 2026 at 02:57:12PM +0900, Koichiro Den wrote:
> On Fri, Aug 14, 2026 at 07:27:10AM +0200, Manivannan Sadhasivam wrote:
> > 
> > Testing is one thing, but using is what matters. Are there any products or
> > use case based on remote eDMA? Or even dw-edma-pcie.c?
> 
> My end goal for this work is this series:
> 
> https://lore.kernel.org/r/20260810165136.2292436-1-den@xxxxxxxxxxxxx/
> 
> It now depends on the PCI DMA EPF. The host side controls the endpoint eDMA
> through dw-edma-pcie for one direction. This is for an industrial use case, not
> just testing.
> 
> The resulting ntb_netdev/ntb_transport improvement is substantial:
> 
>   (unit: Gbps) (UL=EP->RC, DL=RC->EP)
> 
>           UL UDP  DL UDP   UL TCP  DL TCP
>   ------- ------  -------  ------  ------
>   Before  ~0.6     ~0.6     ~0.6     ~0.6
>   After   ~19.5    ~17.3    ~12.3    ~10.8
> 
>   (On R-Car S4, PCIe Gen4 x2, controller IP v5.20a, eDMA)
> 

You have an industrial use case, and your performance numbers show that
remote eDMA can bring great performance gains for your use case.

I don't think anyone is arguing about that.

At least to me, the question is if you need a new PCI EPF driver to implement
the code for this use case. I think the answer is: No, it is not strictly
needed. You can extend vNTB EPF to support your use case.
(As that was your original approach.)



The question how you should test remote eDMA is a different question IMO.
I'm not an expert, but from a testing perspective, does it really matter if
it is the host or the endpoint itself that programs the eDMA hardware?

I understand that you gain performance by having the host program the eDMA
directly. But.. from a eDMA hardware verification standpoint, does it really
matter which side that writes the eDMA registers?
You should be able to test both dma directions, regardless of which side
programs the eDMA hardware, no?

I guess what you mentioned earlier, that the existing pci-epf-test tests
are not pushing sufficient concurrent data to trigger certain driver bugs
when multiple eDMA channels are used.

I guess you could have a test suite that does whatever you did to uncover
these bugs... vNTB + iperf? But I guess it could also be interesting to add
tests that push more data concurrently, such that multiple eDMA channels are
used. To me, that is basically what dmatest was designed for...

Yes, we know that dmatest is currently not a great fit for DWC eDMA, because
dmatest uses different dmaengine APIs.

I think Vinod is best qualified to answer this question, but I guess the answer
is either:
A) Extend dmatest so that it can use the dmaengine APIs to fit DWC eDMA.
or
B) Write a copy of dmatest that is tailored to hardware that uses the dmaengine
   APIs in a similar way as DWC eDMA requires.


Kind regards,
Niklas