RE: [virtio-comment] 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 3:02 PM


> > Existing fields used by existing drivers must be in MMIO.
> > Device does not have a choice.
> 
> They can if they like mask some less important features reducing the footprint.
How do to that? How would device know to not have existing fields on MMIO?

> This will be the cost/benefit analysis each vendor does separately.
> 
> Case in point, if inner hash support is in 1.3, and linux drivers don't really use
> that at all for a year or two because it's only used by alibaba in their stack, and
> by the time linux starts using them it also supports the new commands, then
> practically devices do not care and can just mask the feature bit in MMIO.
> 
Once it lands to config space, it becomes existing fields.
More below.
> 

> > > If they want to cut at 1.3 time, they can, but they also can cut it
> > > at 1.2 time, this means some features will not be accessible through
> > > MMIO only through the new commands.
> > >
> > New commands services new fields by newer driver.
> > Newer driver can call new command to get new and old fields both.
> 
> yes.
> 
> > So 1.3 and 1.4 devices cannot optimize for older drivers.
> 
> 
> I don't know what this means.
> 
I guess next below question answers it.
 
> >
> > > > Once cfgvq is present for new fields, from the day 1, device does
> > > > not need to
> > > store any newly defined fields on MMIO.
> > >
> > > Exactly.
> > >
> > > > And 10 to 20 years, it can stop for existing fields..
> > > >
> > > > The clear benefit is fields defined in 1.4 no longer needs to be
> > > > stored starting
> > > from 2023-24.
> > >
> > > And why is it a problem that someone can also build a 1.4 device with
> MMIO?
> > >
> > Why to build device using large MMIO when those fields are accessible via vq.
> 
> If you don't want to - don't. But it's simple and handy for software.
> Not all devices are complex beasts like net.

Every single device has a VQ to my knowledge.
So VQ is already simple for communication even without cvq.

> 
> Apropos, I am not yet sure the best way is simply adding admin vq to vfs, in that
> this only works for fields not needed before DRIVER_OK.
> Ideally I think we should fix all of config space, including device and common
> config. I have some ideas but let's not get ahead of ourselves.
> 
> > VQ construct exists so it is already simple.
> >
> > If the spec is defined in a way, that new fields must be accessible via vq, and
> optionally via MMIO, than it is ok.
> > One can choose to build via MMIO.
> > So MMIO for new fields must not be mandatory.
> 
> For devices, yes. I am suggesting mandating it for drivers.
It must be mandatory for the driver to support VQ, only than it works.
If driver does not implement, and device only offers via VQ, it does not work.

> Or maybe it's enough to make it a SHOULD.