On 11/18/24 6:03 PM, Martin K. Petersen wrote:
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.
Hi Martin, 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@xxxxxxxxxxx/ Token-based copy offloading (called ODX by Microsoft) could be implemented by maintaining a state machine in the SCSI sd driver and using a single block layer request to submit the four following SCSI commands: * POPULATE TOKEN * RECEIVE ROD TOKEN INFORMATION * WRITE USING TOKEN 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. 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. Thanks, Bart.
