RE: [PATCH 2/5] Introduce VIRTIO_F_ADMIN_VQ_INDIRECT_DESC/VIRTIO_F_ADMIN_VQ_IN_ORDER

[Parav Pandit <parav@nvidia.com>]

> From: Jason Wang <jasowang@redhat.com>
> Sent: Wednesday, January 26, 2022 2:37 PM
> 
> On Wed, Jan 26, 2022 at 4:09 PM Parav Pandit <parav@nvidia.com> wrote:
> >
> >
> > > From: Jason Wang <jasowang@redhat.com>
> > > Sent: Wednesday, January 26, 2022 12:24 PM
> > >
> > > > >
> > > > > 1) the vendor and transport that doesn't want to use admin
> > > > > virtqueue
> > > > It is not the choice of vendor to use admin virtqueue or not. It
> > > > is the spec
> > > definition.
> > >
> > > We are discussing the proposal which hasn't been a part of the spec right
> now.
> > > It doesn't mean we can't do better.
> > Sure. Itâs the proposal we are discussing, but I fail to understand why a vendor
> doesnât want to use a admin queue due to which it needs to be detached.
> 
> What do you mean by "detached"?
Detaching the mgmt cmd from the admin queue.

> >
> > A descriptor in a virtqueue represents wide range of things.
> > 1. Sometime sending packet,
> > 2. sometimes configuring vlan,
> > 3. sometime configuring adding mac to table.
> > 4. sometime adding crypto session
> > 5. and now sometime managing a managed VF or SF device
> >
> > Item #5 is no different than #1 to #4.
> > Managed device configuration != "generic configure the device".
> 
> Well, I think then you need to explain this well in the patch.
> 
Did you get a chance to review v2 commit log?
It describes the motivation for AQ.

> So a virtqueue is needed only when DMA is required. That is the case for
> virtio_fs_req.
> 
> For other cases that DMA is not a must, it could or not be a queue interface.
It is not only the DMA, it is the ability to enqueue multiple requests to the device.

> > If you want to attribute it as "mandate" than yes, it is no different
> > than, virtio_fs_req is mandated on request vq.
> > virtio_crypto_op_ctrl_req ia mandated on control vq.
> >
> > What prevents both above examples to used AQ in generic manner?
> 
> Nothing, but for simple features like MSI I don't think we can exclude the
> possibility of using dedicated registers. For a simple setup like a guest that is
> using an MMIO device, using new virtqueue just for MSI seems an odd burden.
You mixing MSI configuration done by guest driver with AQ.
Guest driver can never use AQ for configuring its own vector configuration which must happen before AQ is created.
So AQ is not useful for that purpose anyway.
And how many vectors a MMIO device gets, can be always configured by HV over AQ.
Even for the simple setup.

> To clarify, we need to define what exactly did management mean? E.g is IMS
> considered to be mgmt or control?
What is IMS. Please be specific?
(a) IMS vector configuration before queue configuration by guest driver?
Or 
(b) IMS vector provisioning for a VF or SF by its parent(management) device by PF?

Above #a falls in the configuration area and needs transport specific registers.
Above #b falls in the mgmt bucket.

> > > > Michael also responded that device configuration will not end at
> > > > msix
> > > configuration.
> > > > So adding more and more tiny capabilities for each configuration
> > > > doesn't
> > > scale either.
> > > >
> > You need to ack above point otherwise we will keep discussing this
> > even 2 weeks from now. :)
> 
> I think I've acknowledged in another thread about the idea of using admin
> virtqueue.
> 
Ok. I am clear now that we have ack from you to use AQ for MSI-X provisioning by the HV PF.