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

On Fri, Aug 14, 2026 at 07:27:10AM +0200, Manivannan Sadhasivam wrote:
> On Thu, Aug 13, 2026 at 10:59:58AM -0500, Frank Li wrote:
> > On Thu, Aug 13, 2026 at 11:15:31PM +0900, Koichiro Den wrote:
> > > On Thu, Aug 13, 2026 at 02:50:59PM +0200, Manivannan Sadhasivam wrote:
> > > > On Thu, Aug 13, 2026 at 01:46:07PM +0200, Niklas Cassel wrote:
> > > > > Hello Koichiro,
> > > > >
> > > > > On Thu, Aug 13, 2026 at 03:37:47PM +0900, Koichiro Den wrote:
> > > > > > This is v7, the remaining patch set for PCI endpoint DMA.
> > > > > > Parts 2 and 3 were merged per Frank's suggestion.
> > > > >
> > > > > (snip)
> > > > >
> > > > > > One open question is how to support endpoint controllers with only one
> > > > > > PF. Keeping DMA in a separate EPF requires multi-function endpoint
> > > > > > support. Folding it into vNTB would work on single-function
> > > > > > controllers, but would also couple the two implementations. This series
> > > > > > keeps the separate EPF model.
> > > > >
> > > > > I see all the work you are putting in and I admire the effort.
> > > > >
> > > > > This is now v7. I think it is time that we close the open question by
> > > > > waiting for a reply from the PCI endpoint maintainers' opinion on the
> > > > > design before continuing. (I am not a PCI endpoint maintainer.)
> > > > >
> > > > > I understand that you want a common DMA abstraction, that can represent
> > > > > different (embedded) DMA controllers on the endpoint side.
> > > > >
> > > > > But if vNTB is the only consumer of this, then why not simply embed this
> > > > > DMA abstraction in some BAR exposed by the vNTB EPF?
> > > > >
> > > > > Looking at the host side driver that goes with the (v)NTB driver:
> > > > > drivers/ntb/hw/epf/ntb_hw_epf.c
> > > > >
> > > > > The BAR layouts are hard coded, and it only supports three different
> > > > > layouts. Would it not be possible to add a fourth layout that has the
> > > > > DMA abstraction somewhere in one of the BARs? ('BAR_DMA' ?)
> > > > >
> > > > >
> > > > > Right now, I wonder if it is not a bit premature optimization to create a
> > > > > DMA EPF, if vNTB will be the only (ever?) user.
> > > > >
> > > >
> > > > Yeah, I feel the same. I haven't seen an usecase to program the DMA controller
> > > > from the host outside of vNTB. This feature is supported mostly because it
> > > > exists in hardware and someone wants to tick the checkbox.
> > > >
> > > > Though, I'm not against doing it within vNTB as Niklas suggested, but
> > > > generalising it in the form of a new EPF driver just for the sake of a single
> > > > driver sounds like an overkill and maintenance burden.
> > > >
> > > > Sorry for saying this in v7. I've been meaning to say it, but somehow ended up
> > > > procrastinating too much.
> > >
> > > No bother. Since Frank has given a lot of feedback on this series, I'd also like
> > > to hear his view.
> > >
> > > I'm fine with either direction, and can revisit the earlier vNTB-embedded
> > > approach:
> > > https://lore.kernel.org/r/sn67hi7kljh7cgmgodatb3naz2astlaklqfobdbxyyzgoohxqb@4nnetbhqwba4/
> > 
> > One of the important value is test dw-edma-pcie.c, which generally depend
> > on some fpga hardware. If there are epf driver work as fpga hardware, it
> > will help cover edma remote user case. So more user can test it.
> > 
> 
> 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)

Best regards,
Koichiro

> 
> Most of the time, dw-edma-pcie.c driver feels like a dead code to me which no
> one actively uses or tests. So unless a real justification is put forward, I
> don't want to add a whole new EPF driver for it.
> 
> - Mani
> 
> -- 
> மணிவண்ணன் சதாசிவம்