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:20:23PM +0000, Parav Pandit wrote:
> 
> > 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.

Make that same across VFs?

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


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

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.

-- 
MST