On Mon, Mar 06, 2023 at 03:17:59PM -0500, Stefan Hajnoczi wrote:
> On Mon, Mar 06, 2023 at 01:37:31PM -0500, Michael S. Tsirkin wrote:
>
> On Mon, Mar 06, 2023 at 06:03:40AM -0500, Stefan Hajnoczi wrote:
> >
> On Sun, Mar 05, 2023 at 07:18:24PM -0500, Michael S. Tsirkin wrote:
> > >
> On Sun, Mar 05, 2023 at 07:03:02PM -0500, Stefan Hajnoczi wrote:
> > > >
> 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.
> > > >
> > >
> Let's say I submit a write followed by read - is read
> > >
> guaranteed to return an up to date info?
> > >
> >
> In general, no. The driver must wait for the write completion before
> >
> submitting the read if it wants consistency.
> > >
> >
> Stefan
> >
>
> I see. I think it's a good design to follow then.
> >
>
> I'll just copy
>
> The driver queues requests to an arbitrary request queue, and
>
> they are used by the device on that same queue. It is the
>
> responsibility of the driver to ensure strict request ordering
>
> for commands placed on different queues, because they will be
>
> consumed with no order constraints.
> >
>
> replacing "request" with "admin".
>
> That sounds like it's only about multi-queue because it says "... for
> commands placed on different queues". What I mentioned about a write
> followed by a read quest also applies within a single queue.
Well that text is from the virtio scsi spec. turning it around does
it need clarification there?
> Can you clarify the semantics in the single queue case?
>
> Stefan
