Re: [PATCH v2 1/4] Add virtio Admin Virtqueue

[Max Gurtovoy <mgurtovoy@nvidia.com>]

On 1/26/2022 5:03 PM, Michael S. Tsirkin wrote:
> On Wed, Jan 26, 2022 at 04:54:22PM +0200, Max Gurtovoy wrote:
> > On 1/26/2022 4:40 PM, Michael S. Tsirkin wrote:
> > > On Mon, Jan 24, 2022 at 11:39:15AM +0200, Max Gurtovoy wrote:
> > > > +Regardless of device offering VIRTIO_F_IN_ORDER, admin queue command buffers
> > > > +are used by the device in out of order manner.
> > > Instead of special-casing AQ I'd like to see a generic capability
> > > addressing this need. For example, TX for virtio net might benefit from
> > > this too. And I'd like to mention, again, VIRTIO_F_PARTIAL_ORDER
> > > proposal as one, arguably cleaner and more generic way to address this.
> > We already suggested a special capability for IN_ORDER for AQ and you asked
> > to drop it. We drop it and agreed that AQ will be OOO.
> >
> > Why are we going back here ?
> That's a misunderstanding. Currently all VQs of a device follow same
> ordering. So I suggested making AQ just follow ordering of rest of VQs
> of the device.
Can we say the the AQ is by nature OOO so if AQ is set then IN_ORDER 
can't be set ?
> > You also mentioned that this patch set is already big enough so why solve
> > all the problems we can think of in this one ?
> Right. So just leave the ordering be for now, driver can just skip
> IN_ORDER and use AQ without it if it wants to.

Without mentioning this in the spec ? can we control all the drivers in 
the world ?

> > Why mixing
> > VIRTIO_F_PARTIAL_ORDER here ?
> PARTIAL_ORDER has its own patch, no need to mix it in. Reusing that
> seems cleaner than special-casing here though, we do try to have
> reusable modules, otherwise things just get out of hand quickly.

re-using modules that haven't yet merged ? This require mixing 2 proposals.

I think best we can do is to say:

"A device MUST NOT propose VIRTIO_F_IN_ORDER if VIRTIO_F_ADMIN_VQ is 
proposed."

> > > And if that's not adequate I'd like to address that as part of the
> > > PARTIAL_ORDER proposal, this kind of per-queue in order was definitely
> > > on the radar as it was formulated.