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

["Michael S. Tsirkin" <mst@redhat.com>]

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?

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

-- 
MST