Mikulas, On 2/3/22 12:57, Mikulas Patocka wrote: > > > On Thu, 3 Feb 2022, Luis Chamberlain wrote: > >> On Thu, Feb 03, 2022 at 05:15:34PM +0100, Christoph Hellwig wrote: >>> On Thu, Feb 03, 2022 at 08:06:33AM -0800, Luis Chamberlain wrote: >>>> On Wed, Feb 02, 2022 at 06:01:13AM +0000, Adam Manzanares wrote: >>>>> BTW I think having the target code be able to implement simple copy without >>>>> moving data over the fabric would be a great way of showing off the command. >>>> >>>> Do you mean this should be implemented instead as a fabrics backend >>>> instead because fabrics already instantiates and creates a virtual >>>> nvme device? And so this would mean less code? >>> >>> It would be a lot less code. In fact I don't think we need any new code >>> at all. Just using nvme-loop on top of null_blk or brd should be all >>> that is needed. >> >> Mikulas, >> >> That begs the question why add this instead of using null_blk with >> nvme-loop? >> >> Luis > > I think that nvme-debug (the patch 3) doesn't have to be added to the > kernel. > > Nvme-debug was an old student project that was canceled. I used it because > it was very easy to add copy offload functionality to it - adding this > capability took just one function with 43 lines of code (nvme_debug_copy). > > I don't know if someone is interested in continuing the development of > nvme-debug. If yes, I can continue the development, if not, we can just > drop it. > > Mikulas > Thanks for explanation seems like we are on the same page, we don't want any code such as this that is controller specific in the NVMe repo including target. -ck -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
