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

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

Nitesh,

> 1.payload based approach:
>   a. Based on Mikulas patch, here a common payload is used for both source
>     and destination bio.
>   b. Initially we send source bio, upon reaching driver we update payload
>     and complete the bio.
>   c. Send destination bio, in driver layer we recover the source info
>     from the payload and send the copy command to device.
>
>   Drawback:
>   Request payload contains IO information rather than data.
>   Based on past experience Christoph and Bart suggested not a good way
>   forward.
>   Alternate suggestion from Christoph was to used separate BIOs for src
>   and destination and match them using token/id.
>   As Bart pointed, I find it hard how to match when the IO split happens.

In my experience the payload-based approach was what made things work. I
tried many things before settling on that. Also note that to support
token-based SCSI devices, you inevitably need to separate the
read/copy_in operation from the write/copy_out ditto and carry the token
in the payload.

For "single copy command" devices, you can just synthesize the token in
the driver. Although I don't really know what the point of the token is
in that case because as far as I'm concerned, the only interesting
information is that the read/copy_in operation made it down the stack
without being split.

Handling splits made things way too complicated for my taste. Especially
with a potential many-to-many mapping. Better to just fall back to
regular read/writes if either the copy_in or the copy_out operation
needs to be split. If your stacked storage is configured with a
prohibitively small stripe chunk size, then your copy performance is
just going to be approaching that of a regular read/write data movement.
Not a big deal as far as I'm concerned...

-- 
Martin K. Petersen	Oracle Linux Engineering