RE: [virtio-comment] RE: [PATCH v19] virtio-net: support inner header hash

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Wednesday, June 28, 2023 6:27 AM
> 
> On Wed, Jun 28, 2023 at 04:23:09AM +0000, Parav Pandit wrote:
> >
> > > From: Jason Wang <jasowang@redhat.com>
> > > Sent: Tuesday, June 27, 2023 11:46 PM
> > >
> > > Having it in the config space, then a type agnostic provisioning
> > > through config space + feature bits just works fine.
> > >
> > Provisioning is far simpler thing to do in device specific way than asking device
> to store this value in onchip area which is rarely accessed.
> 
> I thought a lot about this over the weekend. I just do not see this working out,
> sorry.  Two things is never easier than one. 

You proposed two things and making it mandatory.
I am glad that you realized to do using one interface.

In different context, you proposed two interface for driver notification on PF and/or VF BAR in separate thread for flexibility. I asked for one.
Somehow you promoted flexibility (and also complexity that no vendor wanted), and here you lean towards single interface...

So more explanation of the rationale will help to understand.

I didn't propose two interfaces. Let me explain again.

I proposed, 
a. all new fields to go via vq (single interface)
b. all existing fields to stay in cfg space (single interface)
c. if one wants to optimize optionally existing fields can utilize (same flexibility how you asked for PF and VF notification).


> We already need config space with provisioning.  
Provisioning does provision features, config space and control parameters, msix vectors and more.
Provisioning does _not_ need config space.

> In fact e.g. on Linux we want drivers to keep doing virtio_cread()
> and all the DMA tricks should be hidden behind the scenes. You don't like it that
> config space is on-chip? Build an interface for it not to be on chip. There is
> simply no downside to that.
> 
This is the ask to build software interface between driver and device to not demand on-chip config space more importantly _predictably_.

> I came back after a small break and I still see this discussion that keeps playing
> out as a big distraction.
> In particular where are you doing to store the things that are for DMA?
> In system RAM? We don't *have* anywhere in system RAM to store this, we will
> need an interface to allocate system RAM and pass it to device for this idea to
> work. So in 1.3 where we won't have this, there is much less of an excuse to use
> a vq.
To store what?
CVQ is already there to do GET and SET operation.

> 
> 
> 
> 
> > There are many fields of many features for 1.4 are discussed including this
> one. All of these capabilities just cannot be stored in config space.
> 
> config space is synchronous interface, vq is asynchronous.  Setup is just too
> messy to do asynchronously. So yes, config space.
> 
Huh, I disagree. The whole virtio spec has got the VQs all over and you say that VQ is messy.
Doesn't make any sense at all.

> 
> Please let people just focus on fixing config space instead of temporary cvq
> hacks.

The ask is to have predictable sizing for existing defined config space field and not keep infinitely growing by two interfaces.