RE: [virtio-dev] Re: [virtio-comment] Re: [PATCH v18] virtio-net: support inner header hash

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, June 22, 2023 1:15 PM
> 
> On Thu, Jun 22, 2023 at 05:04:04PM +0000, Parav Pandit wrote:
> >
> >
> > > From: virtio-dev@lists.oasis-open.org
> > > <virtio-dev@lists.oasis-open.org> 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.
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.

> > > > The single way for every device to query their capabilities is via
> > > > a cfgvq for all
> > > new fields without extending the existing config space.
> > > > (and optionally old fields).
> > >
> > > Or adminq with self group. I like this somewhat better because we
> > > need exactly same query from owner.
> > >
> > Yes. this is why I proposed to name is cmdvq that can carry admin commands
> or other.
> > But fine, we had to progress for group owner.
> >
> > > > > Why don't we focus on a work on a full solution? Just don't
> > > > > implement this thing in your devices meanwhile until we do.
> > > > >
> > > > Then Heng needs to wait for cfgvq to be defined to be implemented first.
> > > > Doesn't look reasonable to me.
> > >
> > > And *everything* has to wait. No, not reasonable. We somehow managed
> > > to release several spec versions and things did not ground to a halt without
> cfgvq.
> > > Don't see a reason to do it right now, what's special about now? I
> > > feel we should add to config space and then solve it all.
> > >
> > Things didn't ground at cost of device keep increasing their memory footprint.
> > The latest addition I remember is the queue_reset register.
> > It was bit but a purely control operation that got in there.
> >
> > > > Current GET is coherent with the new commands defined such as
> > > > notification
> > > coalescing.
> > > >
> > > > As community, we should work on defining the cfgvq, till that time
> > > > have the
> > > optimal way to get the config, i.e. using the cvq.
> > >
> > > cvq doesn't really work for capabilities though.
> >
> > For the device itself, it does which is what is being done here.
> 
> Yes but not for migration.

For migration a admin command to query capabilities is needed.
This is present in the transport vq proposal already to be rebased on top of admin cmd.