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

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Feb 08, 2022 at 06:52:09PM +0000, Parav Pandit wrote:
> 
> > 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?

I can go into it but it's beside the point.  I was just trying to help
you come up with use-cases.  Don't like it - come up with your own ones.


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