On Fri, May 23, 2025 at 11:29:45PM +0000, David Matlack wrote: > Drivers must implement the following methods: > > - probe(): Check if the driver supports a given device. > - init(): Initialize the driver. > - remove(): Deinitialize the driver and reset the device. > - memcpy_start(): Kick off a series of repeated memcpys (DMA reads and > DMA writes). > - memcpy_wait(): Wait for a memcpy operation to complete. > - send_msi(): Make the device send an MSI interrupt. > > memcpy_start/wait() are for generating DMA. We separate the operation > into 2 steps so that tests can trigger a long-running DMA operation. We > expect to use this to stress test Live Updates by kicking off a > long-running mempcy operation and then performing a Live Update. These > methods are required to not generate any interrupts.
I like this, it is a smart way to go about building a testing framework. Joel had sent something that looks related: https://lore.kernel.org/r/5zoh5r6eovbpijic22htkqik6mvyfbma5w7kjzcpz7kgbjufd2@yw6ymwy2a54s IMHO it would be very nice to lean into what Joel was thinking of a 'libvfn' where the above device stuff is inside a library and it can be re-used for other purposes. We keep running into scenarios where it would be really nice to be able to do DMA testing and we just don't have easy ways to build SW to do that. A reusable mini-driver framework that can trigger DMA is a huge leap forward. > Library: > > - Driver support for devices that can be used on AMD, ARM, and other > platforms. I would be very happy to see a mlx5 driver option. mlx5 class HW is widely available, cheap on ebay, and it would make this usable by pretty much anyone who wants. Jason
