On Thu, Feb 03, 2022 at 03:57:55PM -0500, Mikulas Patocka wrote:

On Thu, 3 Feb 2022, Luis Chamberlain wrote:

quoted

On Thu, Feb 03, 2022 at 05:15:34PM +0100, Christoph Hellwig wrote:

quoted

On Thu, Feb 03, 2022 at 08:06:33AM -0800, Luis Chamberlain wrote:

quoted

On Wed, Feb 02, 2022 at 06:01:13AM +0000, Adam Manzanares wrote:

quoted

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).

BTW Kanchan's group has looked at adding copy offload support to the target.
I'll let him respond on the timing of upstreaming, I'm under the assumption
that it is also a relatively small patch to the target code.

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