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

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

Nitesh,

> This approach looks simpler to me as well.
> But where do we store the read sector info before sending write.
> I see 2 approaches here,

> 1. Should it be part of a payload along with write ? We did something
> similar in previous series which was not liked by Christoph and Bart.

> 2. Or driver should store it as part of an internal list inside
> namespace/ctrl data structure ? As Bart pointed out, here we might
> need to send one more fail request later if copy_write fails to land
> in same driver.

The problem with option 2 is that when you're doing copy between two
different LUNs, then you suddenly have to maintain state in one kernel
object about stuff relating to another kernel object. I think that is
messy. Seems unnecessarily complex.

With option 1, for single command offload, there is no payload to worry
about. Only command completion status matters for the COPY_IN phase. And
once you have completion, you can issue a COPY_OUT. Done.

For token based offload, I really don't understand the objection to
storing the cookie in the bio. I fail to see the benefit of storing the
cookie in the driver and then have the bio refer to something else which
maps to the actual cookie returned by the storage. Again that introduces
object lifetime complexity. It's much simpler to just have the cookie be
part of the very command that is being executed. Once the COPY_IN
completes, you can either use the cookie or throw it away. Doesn't
matter. The device will time it out if you sit on it too long. And there
is zero state in the kernel outside of the memory for the cookie that
you, as the submitter, are responsible for deallocating.

-- 
Martin K. Petersen	Oracle Linux Engineering