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:44 PM
> 
> 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?
>
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.