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

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, March 9, 2023 9:43 AM

> > >
> > Ok. so there may be some use case for transport VQ.
> > Worth to mention in the cover letter and things will be fine.
> > Actual review of the transport VQ and its use will be in the respective
> patchset.
> >
> > > > 2. Having the infrastructure to support multiple AQ is also good.
> > > > The extra cost of this infra is only one read-only field = aq
> > > > count as Michael
> > > proposed.
> > > >
> > > > 3. Ability to send multiple outstanding commands and execute them
> > > > out of
> > > order by device is/should be supported as long as IN_ORDER is not
> negotiated.
> > > > Should it be relaxed for AQ that even if IN_ORDER is negotiated,
> > > > AQ by
> > > default can be out of order queue?
> > >
> > > I feel there's no need: driver can just avoid negotiating IN_ORDER.
> > I didn't understand the "no need" part.
> > Do you mean to make use of out-of-order AQ commands, driver should skip
> IN_ORDER negotiation for the data path queues?
> > If yes, it may not be a big loss for the PF.
> >
> > I am considering that since AQ is so fresh, it can keep itself detached from
> the IN_ORDER from the beginning.
> > This way AQ and data path queues stay on their own course.
> 
> You can make this claim for different types of data queues too.
Those queues are already defined. Without any new feature bit, not sure how can it change.

> I'd rather try to solve it for all queues than special-case AQ.
> 
AQ is newly introduce which has chance of not follow the same limitations as existing queues.

Keeping my inputs aside for moment, what do you propose for v11?