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

[Parav Pandit <parav@nvidia.com>]

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

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