On Tue, Feb 08, 2022 at 06:52:09PM +0000, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin <[email protected]>
> > 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 <[email protected]>
> > > > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
