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

On Fri, Aug 21, 2026 at 05:55:17PM +0200, Niklas Cassel wrote:
> 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/[email protected]/
> > 
> > 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.

As to dw-edma performance testing of dw-edma, we already discussed it here:
https://lore.kernel.org/r/tau5svk3bcatzeapqeb6mun7dxi4ifk56g5ltkk366ljozjzit@vepneiac3f26/

I had already said in the first mail that dmatest did not seem to fit. Vinod
agreed, and Mani suggested an eDMA/HDMA-specific kselftest instead.

Which side programs the hardware may not matter for IP testing, but it does for
driver coverage, specifically dw-edma-pcie. Whether that path should be exposed
through a standalone EPF or vNTB should be a separate question, I suppose.

P.S. I almost ready to start reviving the vNTB-embedded approach:
https://lore.kernel.org/all/3ef3b7wdwpf364teperxcjc2leycxwke77cejjfzd5w4pnbmik@vlcbizvbxv4m/
but am waiting to hear back there in case the maintainers see something
differently.

Best regards,
Koichiro

> 
> 
> Kind regards,
> Niklas