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

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?

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

-- 
மணிவண்ணன் சதாசிவம்