On 2/3/22 22:28, Damien Le Moal wrote: > 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. > agree on simplicity but then why do we have QEMU implementations for the NVMe features (e.g. ZNS, NVMe Simple Copy) ? we can just build memoery backed NVMeOF test target for NVMe controller features. Also, recognizing the simplicity I proposed initially NVMe ZNS fabrics based emulation over QEMU (I think I still have initial state machine implementation code for ZNS somewhere), those were "nacked" for the right reason, since we've decided go with QEMU and use that as a primary platform for testing, so I failed to understand what has changed.. since given that QEMU already supports NVMe simple copy ... > 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. > One can do that with creating null_blk based NVMeOF target namespace, no need to emulate simple copy memory backed code in the fabrics with nvme-loop.. it is as simple as inserting module and configuring ns with nvmetcli once we have finalized the solution for copy offload. If you remember, I already have patches for that... >> >> 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 >> -ck -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
