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

[Parav Pandit <parav@nvidia.com>]

> 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?