Re: [virtio-comment] RE: [PATCH v5 2/7] Introduce admin command set

[Jason Wang <jasowang@redhat.com>]

On Thu, Jun 23, 2022 at 10:07 AM Parav Pandit <parav@nvidia.com> wrote:
>
>
>
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Wednesday, June 22, 2022 9:27 PM
>
> > > 1. proposed new command doesn't demand exposing registers in the PCI
> > > memory mapped area 2. Today AQ is perceived in to be PF, but it doesn't
> > have to be. For next 10 years spec may evolve to have AQ for some other
> > purpose on VFs/SFs.
> > > Such devices scale at much higher magnitude than PFs.
> > > And exposing memory mapped registers for rare functionality is the last
> > thing to do in my mind.
> > > 3. Placements of such features bits in an AQ gives device lot more flexibility
> > on _how_ to implement them. Some in sw, fw, hw, memory die etc.
> > > Placement of them in PCI register space reduces these options.
> > >
> > > So exposing them something in PCI register space has to have strong
> > technical reason than just simplicity of access.
> >
> > I think I know the advantages of admin virtqueue. But this part looks
> > suspicious and actually the reverse,
> >
> > 1) register based transport have been used for years, it's natural to add
> > features based on the existing transport and what you suggest here limit the
> > new features to be carried with those transports
> > 2) admin virtqueue is heavy weight in use cases like nesting, we need a
> > simple interface
> > 3) admin virtqueue is not the universal transport for all cases, we've already
> > had DMA/CMA based transports (e.g ccw and rproc)
> >
> Are you suggesting only feature bits through register-based transport or all commands via register-based transport?

For feature bits, if we don't have admin virtqueue as transport, I
suggest it be negotiated with existing transport: we don't need any
extension of the existing transport facility to make it work. If we
have admin virtqueue as a transport, we must allow the features of the
managed device to be negotiated through the admin virtqueue.

For other commands, we probably need to analyze it case by case. But
if the command is for management only, it should be done via admin
virtqueue. (Note that for the MSIX allocation, I do see some vendors
allocating it via registers). If the command is used for basic
facilities like the virtqueue reset, it should be allowed to be
implemented by any transport (admin virtqueue as well as others like
PCI registers).

Thanks