Mikulas,

On 2/3/22 12:57, 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).

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