[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH v3 1/4] Add virtio Admin virtqueue
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]