virtio — archive

[Jason Wang]

? 2023/3/6 08:03, Stefan Hajnoczi ??: > 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. Or device need mandate some kind of QOS here, e.g a request must be complete in some time. Otherwise we don't have sufficient reliability for using it as management task? Thanks > > Stefan