On 2/4/22 12:12, Chaitanya Kulkarni wrote: > >>>> One can instantiate scsi devices with qemu by using fake scsi devices, >>>> but one can also just use scsi_debug to do the same. I see both efforts >>>> as desirable, so long as someone mantains this. >>>> > > Why do you think both efforts are desirable ? When testing code using the functionality, it is far easier to get said functionality doing a simple "modprobe" rather than having to setup a VM. C.f. running blktests or fstests. So personally, I also think it would be great to have a kernel-based emulation of copy offload. And that should be very easy to implement with the fabric code. Then loopback onto a nullblk device and you get a quick and easy to setup copy-offload device that can even be of the ZNS variant if you want since nullblk supports zones. > > NVMe ZNS QEMU implementation proved to be perfect and works just > fine for testing, copy offload is not an exception. > >>>> For instance, blktests uses scsi_debug for simplicity. >>>> >>>> In the end you decide what you want to use. >>> >>> Can we use the nvme-loop target instead? >> >> I am advocating for this approach as well. It presentas a virtual nvme >> controller already. >> > > It does that assuming underlying block device such as null_blk or > QEMU implementation supports required features not to bloat the the > NVMeOF target. > > -ck > > -- Damien Le Moal Western Digital Research -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
