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
