> From: Michael S. Tsirkin <[email protected]> > Sent: Thursday, June 22, 2023 1:44 PM > > On Thu, Jun 22, 2023 at 05:20:23PM +0000, Parav Pandit wrote: > > > > > From: Michael S. Tsirkin <[email protected]> > > > Sent: Thursday, June 22, 2023 1:15 PM > > > > > > On Thu, Jun 22, 2023 at 05:04:04PM +0000, Parav Pandit wrote: > > > > > > > > > > > > > From: [email protected] > > > > > <[email protected]> On Behalf Of Michael S. > > > > > Tsirkin > > > > > Sent: Thursday, June 22, 2023 12:54 PM > > > > > > > > > > Admin command as I recall are not accessible directly by the > > > > > > member driver to > > > > > the member device. > > > > > > So a cmdq or cfgq is needed. > > > > > > > > > > Possible, sure. Or we actually discussed a self group. I took it > > > > > away until it had a user. > > > > > > > > > The problematic part of AQ is that its index is placed in the yet > > > > another onchip > > > die register that does not scale as each member device has different > > > queue count. > > > > When admin queue was discussed, it was only for group owner, (you > > > answered to Jiri). > > > > Hence the scale is relatively less, so it was acceptable. > > > > > > > > Now having unique numbers for VFs is not good. > > > > Max proposal was the last index after existing defined VQs of > > > > num_queues, > > > that saves the storage space on device. > > > > > > Surely, you can just have a very large index and be done with it? > > > > > There is count of AQ too. > > Make that same across VFs? > Queues are not infinite, so when one doesn't need it, better to not make same number. > > For receive flow filters one may want to have multiple flowfilter_vqs as the > perf req is high for some vms. > > > > And device to build non linear PCI steering on the driver notification for > > this > very high q count. > > It is optimal to have finite and linear q max value. > > What does this have to do with AQ? These are data vqs. >
I think further. Ignore this comment. We need few bare minimum fields to bootstrap the device. So num_aq is one of them to absorb. This is ok. > So 1.4 will maybe have new migration capabilities, and that is great. > But I do not like it that we are adding in 1.3 features that can't be > supported > with current migration capabilities. For 1.3 vdpa style solution are anyway trapping the CVQ so no problem for it either. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
