Re: [PATCHv10 0/9] write hints with nvme fdp, scsi streams

["Martin K. Petersen" <martin.petersen@oracle.com>]

Bart,

> There are some strong arguments in this thread from May 2024 in favor of
> representing the entire copy operation as a single REQ_OP_ operation:
> https://lore.kernel.org/linux-block/20240520102033.9361-1-nj.shetty@samsung.com/

As has been discussed many times, a copy operation is semantically a
read operation followed by a write operation. And, based on my
experience implementing support for both types of copy offload in Linux,
what made things elegant was treating the operation as a read followed
by a write throughout the stack. Exactly like the token-based offload
specification describes.

> Token-based copy offloading (called ODX by Microsoft) could be
> implemented by maintaining a state machine in the SCSI sd driver

I suspect the SCSI maintainer would object strongly to the idea of
maintaining cross-device copy offload state and associated object
lifetime issues in the sd driver.

> I'm assuming that the IMMED bit will be set to zero in the WRITE USING
> TOKEN command. Otherwise one or more additional RECEIVE ROD TOKEN
> INFORMATION commands would be required to poll for the WRITE USING TOKEN
> completion status.

What would the benefit of making WRITE USING TOKEN be a background
operation? That seems like a completely unnecessary complication.

> I guess that the block layer maintainer wouldn't be happy if all block
> drivers would have to deal with three or four phases for copy
> offloading just because ODX is this complicated.

Last I looked, EXTENDED COPY consumed something like 70 pages in the
spec. Token-based copy is trivially simple and elegant by comparison.

-- 
Martin K. Petersen	Oracle Linux Engineering