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 06:12:09PM +0000, Parav Pandit wrote:
> > 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.

I don't get it. Can you show an example configuration where there's
a problem? Which device type, # of data queues and admin queues desired and etc etc.

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

OK I get the idea. True.
Trapping is not the same as driving or actually emulating though.
That part would be new. Certainly annoying.
Practical? Needs a bit of thought.


What's even more annoying is that provisioning would suffer too, instead
of treating all fields the same this one will have to be treated
differently.

Can't say something can't be done, but it's unfortunate that
we are adding to technical debt.

It's late here, I think I will sleep on this.


-- 
MST