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

[Jason Wang <jasowang@redhat.com>]

On Thu, Jun 23, 2022 at 10:57 AM Parav Pandit <parav@nvidia.com> wrote:
>
>
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Wednesday, June 22, 2022 10:42 PM
>
> [..]
> > > 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,
> Right.
> Management tasks (features) done via AQ are negotiated via the AQ (regardless of device type being management dev or managed dev).
> It is not replacing usual feature bits negotiation that has strong relationships with device initialization sequence.

Just to clarify,

E.g if the admin virtqueue is implemented in PF. I suggest using the
existing PCI transport based feature negotiation since:

1) we have selector, so we don't need any new registered and we don't
need worry about the scalability
2) the feature negotiated is done once, so we don't need to care about
the performance

This is the way we used for other features that require a specific
type of virtqueue.

If we use admin virtqueue (management device) to be a transport for
e.g scalable functions (managed devices). We must have a command that
is used for feature negotiation for the scalable function (managed
devices).

>
> > 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.
> >
> Regarding above _managed_device_:
>
> In current version the AQ is on the management device (not managed device).
> But AQ as stated is generic to be present on any device that wants to implement AQ.

Yes.

>
> > 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).
> Where do you see it?

E.g Intel E810

> In the spec draft?

No.

Thanks

>
> > 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).