Re: [virtio-comment] Re: [PATCH v18] virtio-net: support inner header hash

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jun 21, 2023 at 08:52:04PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Wednesday, June 21, 2023 4:38 PM
> 
> > > > And the field is RO so no memory cost to exposing it in all VFs.
> > > Two structures do not bring the asymmetry.
> > > Accessing current and enabled fields via two different mechanism is bringing
> > the asymmetry.
> > 
> > I guess it's a matter of taste, but it is clearly more consistent with other hash
> > things, to which it's very similar.
> >
> This is consistent with new commands we define including notification coalescing whose GET is not coming config space.

But there GET just reports the current state. Not the read only
capability. So there would be cost per VF to keep it in config space.
This one is RO no cost per VF. Let's make it convenient?

> > 
> > Nah, config space is too convenient when we can live with its limitations. I don't
> > thin kwe prefer not to keep growing it.
> > For some things such as this one it's perfect.
> >
> Fields are different between different devices.

Not sure what's the implication?

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

> > Another example, future admin transport will have ability to provision devices
> > by supplying their config space.
> > This will include this capability automatically, if instead we hide it in a command
> > we need to do extra custom work.
> > 
> > > So we do not prefer to keep growing the config space anymore, hence
> > > GET is the right approach to me.
> > 
> > Heh I know you hate config space. Let it go, stop wasting time arguing about the
> > same thing on every turn and instead help define admin transport to solve it
> 
> This was discussed many times, a driver to have a direct (non-intercepted by owner device) channel to device.
> If you mean this non-intercepted channel as admin transport, fine.

we can do that, sure.

> If you mean this is intercepted and it is going over admin cmd, then it is of no use for all future interfaces.
> 
> We discussed this in thread with you and Jason.
> I provided concrete example with size and device provisioning math too and other example of multi-physical address VQ.
> So transporting register by register over some admin transport is sub-optimal.
> 

Not register by register, we can send all of config space as long as
it's RO. This field is.

-- 
MST