On Sun, Mar 05, 2023 at 04:38:59AM -0500, Michael S. Tsirkin wrote:
> On Fri, Mar 03, 2023 at 03:21:33PM -0500, Stefan Hajnoczi wrote:
>
> What happens if a command takes 1 second to complete, is the device
>
> allowed to process the next command from the virtqueue during this time,
>
> possibly completing it before the first command?
> >
>
> This requires additional clarification in the spec because "they are
>
> processed by the device in the order in which they are queued" does not
>
> explain whether commands block the virtqueue (in order completion) or
>
> not (out of order completion).
>
> Oh I begin to see. Hmm how does e.g. virtio scsi handle this?
virtio-scsi, virtio-blk, and NVMe requests may complete out of order.
Several may be processed by the device at the same time.
They rely on multi-queue for abort operations:
In virtio-scsi the abort requests (VIRTIO_SCSI_T_TMF_ABORT_TASK) are
sent on the control virtqueue. The the request identifier namespace is
shared across all virtqueues so it's possible to abort a request that
was submitted to any command virtqueue.
NVMe also follows the same design where abort commands are sent on the
Admin Submission Queue instead of an I/O Submission Queue. It's possible
to identify NVMe requests by <Submission Queue ID, Command Identifier>.
virtio-blk doesn't support aborting requests.
I think the logic behind this design is that if a queue gets stuck
processing long-running requests, then the device should not be forced
to perform lookahead in the queue to find abort commands. A separate
control/admin queue is used for the abort requests.
Stefan
