07:17 <_florent_> tnt: The current gateware/software architecture and loop mode, the FPGA is indeed imposing the speed of the transfers (on a pre-allocated circular buffer) and software synchronize to it. (so have to handle underflow/overflow when not able to keep up). It should not be too complicated to operate differently, but this is what is currently used for the dma loopback test.

07:19 <_florent_> tnt: I'm going to look at the DMA RX_DELAY issue you saw, I added it to be able to compensate for unknown initial delay in the loopback chain (when doing a loopback over the RFIC for example), but I've mostly been testing it on a specific configuration and will do more tests with others

08:45 <tnt> _florent_: yeah, I think just using the programmable mode and re-submit descriptors when the user space reads the current buffer would work. I didn't check the hardware side, but I assume if it has no descriptors, it just stops transfers until it has one.

08:47 <tnt> The RX_DELAY could very well just be that the host PC is too slow and the dropped buffers prevent it from syncing. The host test machine is a relatively weak i3-10105 and gen3 4x full bandwidth is quite fast.

09:16 <_florent_> tnt: When using loop mode, you first fill all the descriptors in the table and the core will just loop on it, but it's indeed perfectly possible to use the disable loop mode. In this case, the DMA will just execute the full table and stop after that. You'll also get an IRQ for each executed descriptor.

09:17 <_florent_> tnt: Not sure indeed an i

09:17 <_florent_> tnt: Not sure indeed an i3 will be able to keep up with the gen3 x4 full bandwidth

09:18 <_florent_> tnt: disabling random data will speed up software: https://github.com/enjoy-digital/litepcie/blob/master/litepcie/software/user/litepcie_util.c#L21 but still not sure it will be enough

19:14 <tnt> _florent_: yup I tried disabling random mode but it didn't seem to help.