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

[Jiri Pirko <jiri@nvidia.com>]

Mon, Mar 06, 2023 at 07:37:31PM CET, mst@redhat.com 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.

Hmm, is it suitable to have this approach for configuration interface?
Storage device is a different beast, having parallel reads and writes
makes complete sense for performance.

->read a req
->read b req
->read c req
<-read a rep
<-read b rep
<-read c rep

There is no dependency, even between writes.

But in case of configuration, does not make any sense to me.
Why is it needed? To pass the burden of consistency of
configuration to driver sounds odd at least.

I sense there is no concete idea about what the "admin virtqueue" should
serve for exactly.



>
>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".
>
>-- 
>MST
>
>
>This publicly archived list offers a means to provide input to the
>OASIS Virtual I/O Device (VIRTIO) TC.
>
>In order to verify user consent to the Feedback License terms and
>to minimize spam in the list archive, subscription is required
>before posting.
>
>Subscribe: virtio-comment-subscribe@lists.oasis-open.org
>Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
>List help: virtio-comment-help@lists.oasis-open.org
>List archive: https://lists.oasis-open.org/archives/virtio-comment/
>Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
>List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
>Committee: https://www.oasis-open.org/committees/virtio/
>Join OASIS: https://www.oasis-open.org/join/
>