On Wed, Jul 10, 2024 at 11:09:43AM +0200, Klaus Jensen wrote: > On Jul 2 20:55, Klaus Jensen wrote: > > On Jul 2 09:24, Keith Busch wrote: > > > On Tue, Jul 02, 2024 at 01:32:32PM +0530, Ayush Mishra wrote: > > > > Abort was not implemented previously, but we can implement it for AERs > > > > and asynchrnously for I/O. > > > > > > Not implemented for a reason. The target has no idea if the CID the > > > host requested to be aborted is from the same context that the target > > > has. Target may have previoulsy completed it, and the host re-issued a > > > new command after the abort, and due to the queueing could have been > > > observed in a different order, and now you aborted the wrong command. > > > > I might be missing something here, but are you saying that the Abort > > command is fundamentally flawed? Isn't this a host issue? The Abort is > > for a specific CID on a specific SQID. The host *should* not screw this > > up and reuse a CID it has an outstanding Abort on? > > > > I don't think there are a lot of I/O commands that a host would be able > > to cancel (in QEMU, not at all, because only the iscsi backend > > actually implements blk_aio_cancel_async). But some commands that issue > > multiple AIOs, like Copy, may be long running and with this it can > > actually be cancelled. > > > > And with regards to AERs, I don't see why it is not advantageous to be > > able to Abort one? > > Keith, any thoughts on this?
Oh, you can take this if you want, I'm just mentioning the pitfalls with the abort command. While sequestoring command id's that are being aborted may be good practice for the host, the spec doesn't say anything about it. The Linux driver doesn't do that at least, though it recently created a different mechanism to avoid immediate command id reuse.
