Re: [PATCH 00/17] dmaengine: dw-edma: Support dynamic LL appends

[Koichiro Den]

Hi Niklas, Mani,

On Mon, Jun 22, 2026 at 04:18:01PM +0200, Niklas Cassel wrote:
> On Mon, Jun 22, 2026 at 04:38:49PM +0900, Koichiro Den wrote:
> > On Tue, Jun 16, 2026 at 12:40:54AM +0900, Koichiro Den wrote:
> > 
> > Hi Frank, Niklas, all,
> > 
> > I am looking for a good way to stress PCIe controller DMA engines, such as
> > eDMA/HDMA, and measure their upper-bound throughput.
> > 
> > nvmet_pci_epf is useful since it is a real in-tree consumer, but it is not a
> > very direct benchmark for the DMA engine itself. So I wonder if
> > pci_endpoint_test would be a reasonable place to add an opt-in DMA performance
> > mode.
> > 
> > One possible option I have in mind is:
> > 
> >   - a new fixture, pci_ep_dma_perf
> >   - opt-in execution, for example with PCITEST_PERF=1 environment variable
> >   - a few variants such as single and sg, possibly with a few knobs:
> >      - PCITEST_PERF_NUM_WORKERS, to use multiple EP-side workers
> >      - PCITEST_PERF_NUM_CHANS, to use multiple DMA channels
> >      - perhaps other knobs for SG entry size, number of entries, etc.
> >   - the new tests: READ_PERF_TEST and WRITE_PERF_TEST
       `--- (A)

> > 
> > For the other possible places I could think of, this still seems to fit best in
> > pci_endpoint_test. For example, extending dmatest does not seem to fit well
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > because this needs both EP and RC side setup. A separate kselftest also feels
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                         `--- (B)

> > like it would duplicate a lot of pci_endpoint_test code. That said, I might be
> > missing something.
> > 
> > What do you think? Any thoughts or suggestions would be much appreciated.
> 
> There are two existing (out-of-tree) tests for eDMA that I know of:
> 
> 1)
> https://patchwork.kernel.org/project/linux-pci/patch/cc195ac53839b318764c8f6502002cd6d933a923.1547230339.git.gustavo.pimentel@xxxxxxxxxxxx/
> 
> But as you can see, the comment was to use dmatest instead.
> AFAICT, dmatest currently only supports DMA_MEMCPY, which, by hardware design,
> cannot be supported by DWC eDMA HW (since it only allows remote to local, or
> local to remote, and remote has to be a PCI address, while local is local
> physical address).
> 
> Perhaps it is possible to add DMA_SLAVE support to dmatest.

Thanks for the pointers, Niklas.

The first one looks like a host-side test on top of dw-edma-pcie, where the
RC-side driver programs the eDMA through BARs. That is useful, but it is a bit
different from what I had in mind here.

What I am looking for is closer to pci_endpoint_test READ_TEST/WRITE_TEST, but
with a perf/stress mode: the RC side provides the buffers, while EP Linux
drives the EP-local DMA engine and reports the throughput.

I agree that, if we extend dmatest with DMA_SLAVE support, then Vinod should be
involved early. In theory that could cover this too, if dmatest also had a way
to set up RC-side buffers and pass their PCI addresses to the EP side. That is
the part that makes me unsure dmatest is the right fit here (see (B) above).
Before going too far down that path, I wanted to check whether the PCI endpoint
test stack would be an acceptable home for this EP-driven case.

> 
> 
> 2)
> https://github.com/rockchip-linux/kernel/blob/develop-6.1/drivers/pci/controller/dwc/pcie-dw-dmatest.c
> https://github.com/rockchip-linux/kernel/blob/develop-6.1/drivers/pci/controller/rockchip-pcie-dma.h
> 
> 
> Anyway, since Vinod is the maintainer, it is probably him you need to talk
> to come up with a way forward. To not waste your time, I would talk to him
> before you spend a lot of time implementing something :)

Yes, that makes sense. I will keep Vinod in the loop. :)


Mani, since this is about the PCI EP test stack, do you think an opt-in perf
fixture in pci_endpoint_test/pci_epf_test would be acceptable, or would that be
too much for the EP test driver?

The rough shape is the one I described in (A) above:

  - a new fixture, pci_ep_dma_perf
  - opt-in execution, for example with PCITEST_PERF=1 environment variable
  - a few variants such as single and sg, possibly with a few knobs:
     - PCITEST_PERF_NUM_WORKERS, to use multiple EP-side workers
     - PCITEST_PERF_NUM_CHANS, to use multiple DMA channels
     - perhaps other knobs for SG entry size, number of entries, etc.
  - the new tests: READ_PERF_TEST and WRITE_PERF_TEST

Best regards,
Koichiro

> 
> 
> Kind regards,
> Niklas