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 12:28 PM

> > > Not sure what's the implication?
> > Implication is device needs to store this in always available on-chip memory
> which is not good.
> 
> Oh by devices you mean VFs. Now I get your motivation, at least. Thanks.
>
> > >
> > > > > For example, for migration driver might want to validate that two
> > > > > devices have same capability. doing it without dma is nicer.
> > > > >
> > > > A migration driver for real world scenario, will almost have to use the dma
> for
> > > amount of data it needs to exchange.
> > >
> > > Not migration itself, provisioning.
> > >
> > Provisioning driver usually do not attach to the member device directly.
> > This requires device reset, followed by reaching _DRIVER stage, querying
> features etc and config area.
> > And unbinding it and second reset by member driver. Ugh.
> > Provisioning driver also needs to get the state or capabilities even when
> member driver is already attached.
> > So config space is not much a gain either.
> >
> 
> Absolutely, that's why we have admin commands.  I was hoping for an
> admin command that basically gets/sets RO fields of the config space.
>
Admin command as I recall are not accessible directly by the member driver to the member device.
So a cmdq or cfgq is needed.
 
> > Instead of decision point being RO vs RW,
> > any new fields via cmdvq and existing fields stays in cfg space, give predictable
> behavior to size the member devices in the system.
> > Once the cmdvq is available, we can get rid of GET command used in this
> version for new future features.
> > Till that arrives, GET command is the efficient way.
> 
> I understand.  I just don't much like these patchwork solutions though.
> And I don't like that we will pay by not having a single conherent
> way to provision and query capabilities through config space,
> instead just for this thing we will have a special thing.
>
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).
 
> 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.
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.