Re: [virtio] Re: [PATCH v10 04/10] admin: introduce virtio admin virtqueues

[Jason Wang <jasowang@redhat.com>]

å 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