On Fri, Nov 29, 2024 at 06:13:12PM +0100, Niklas Cassel wrote:
On Fri, Nov 29, 2024 at 10:22:56PM +0530, Manivannan Sadhasivam wrote:
On Fri, Nov 29, 2024 at 05:42:26PM +0100, Niklas Cassel wrote:
On Fri, Nov 29, 2024 at 10:05:55PM +0530, Manivannan Sadhasivam wrote:
On Fri, Nov 29, 2024 at 02:51:26PM +0100, Niklas Cassel wrote:
Hello Mani,
On Fri, Nov 29, 2024 at 02:54:15PM +0530, Manivannan Sadhasivam wrote:
Migrate the PCI endpoint test to Kselftest framework. All the tests that were part of the previous pcitest.sh file were migrated.
Below is the exclusive list of tests:
- BAR Tests (BAR0 to BAR5)
- Legacy IRQ Tests
- MSI Interrupt Tests (MSI1 to MSI32)
- MSI-X Interrupt Tests (MSI-X1 to MSI-X2048)
- Read Tests - MEMCPY (For 1, 1024, 1025, 1024000, 1024001 Bytes)
- Write Tests - MEMCPY (For 1, 1024, 1025, 1024000, 1024001 Bytes)
- Copy Tests - MEMCPY (For 1, 1024, 1025, 1024000, 1024001 Bytes)
- Read Tests - DMA (For 1, 1024, 1025, 1024000, 1024001 Bytes)
- Write Tests - DMA (For 1, 1024, 1025, 1024000, 1024001 Bytes)
- Copy Tests - DMA (For 1, 1024, 1025, 1024000, 1024001 Bytes)
I'm not sure if it is a great idea to add test case number 10.
While it will work if you use the "dummy memcpy" DMA channel which uses MMIO under the hood, if you actually enable a real DMA controller (which often sets the DMA_PRIVATE cap in the DMA controller driver (e.g. if you are using a DWC based PCIe EP controller and select CONFIG_DW_EDMA=y)), pci_epf_test_copy() will fail with: [ 93.779444] pci_epf_test pci_epf_test.0: Cannot transfer data using DMA
So the idea is to exercise all the options provided by the epf-test driver. In that sense, we need to have the DMA COPY test. However, I do agree that the common DMA controllers will fail this case. So how about just simulating the DMA COPY for controllers implementing DMA_PRIVATE cap? I don't think it hurts to have this feature in test driver.
I guess you could modify pci-epf-test to simply do MMIO in test_copy(), if USE_DMA && DMA_PRIVATE is set, as you suggest.
No not memcpy, but using the DMA to copy from src to local buf and then local buf to dst. This way, we do not need to fallback and at the same time simulate DMA COPY.
Sounds very slow :)
What would be the value to add such code to pci-epf-test?
Well, the test case is to test COPY functionality using DMA. Either we use MEM_TO_MEM if supported, or just do DMA from source to dst. Even if the performance is going to be half of what read/write would achieve separately, it would give users a real benchmark. Otherwise, we have to skip the test case altogether. Like,
./pci_endpoint_test -f pci_ep_basic -v memcpy -T COPY_TEST -v dma
Perhaps we should document this limitation and show above command to skip the COPY_TEST for DMA?
Sounds like we would just add a lot of extra code in pci-epf-test.c that would not test anything new. (It would basically just be the DMA read test followed by the DMA write test. If those tests pass, this new simulated test should be guaranteed to pass.)
Wouldn't it make more sense to simply do something like:
if (use_dma && dma_prive) { dev_warn(dev, "DEV_TO_DEV not supported with USE_DMA, falling back to MMIO\n"); use_dma = 0; }
Maybe yes, but memcpy is also doing the same. The problem with falling back is that, it provides a fake benchmark to the users which I want to avoid doing so.
- Mani