RE: [PATCH v3 1/4] Add virtio Admin virtqueue

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Tuesday, February 8, 2022 9:10 PM
> 
> On Tue, Feb 08, 2022 at 03:06:16PM +0000, Parav Pandit wrote:
> >
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Tuesday, February 8, 2022 7:29 PM
> > >
> > > > Do we have a concrete example of a command that can be targeted
> > > > for same
> > > device and a target device, which requires differentiating their
> > > destination? If so, lets discuss and then it make sense to add for the well-
> defined use case.
> > >
> > > So e.g. things like controlling NIC's MAC can reasonably be part of
> > > the same device.
> > A mac address of NIC can be programmed via the existing control VQ for the
> self.
> 
> Not if it's disabled for the guest.
> 
Its unrelated.
The idea was to issue same command in same way by two devices = primary and secondary.
And in case of primary, it will refer to secondary device.
And in second case secondary tells to self.

So if its disabled by guest, it doesn't matter how guest transports it, either via CVQ or AQ.
Its disabled.
Why to re-invent command that exists on CVQ to AQ?

> OK, and Cornelia also said she thinks 64 is necessary.
> 
> > So if we really want to cover variety of cases like [1] and some more
> > complex nested cases, we better define, Device identifier as below,
> > struct device_identifier {
> > 	u8 id_length;
> > 	u8 id[];	/* variable length field
> > };
> > For implicitly grouped VFs of a PF, id can be 2 bytes.
> > For more advance cases it can be a structure consist one or more
> combination of (a) host id or controller id (b) PF BDF, (c) sf id (d) PASID and
> more.
> >
> > [1]
> > https://www.kernel.org/doc/Documentation/networking/devlink/devlink-po
> > rt.rst
> 
> I'm fine with this too.
>
Since we aim for future proofing and flexibility, variable length id is better than constant u64. It covers the u64 case anyway.
 
> --
> MST