[virtio-dev] 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:24:57PM +0000, Parav Pandit wrote:
> 
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Wednesday, June 21, 2023 4:17 PM
> 
> > 
> > and actually I missed the fact that instead of making this symmetric it forced
> > separate structures for GET and SET.
> > 
> > If we move supported_tunnel_hash_types back to config space then GET and
> > SET just need the active bitmap. *that* seems symmetric to me.
> > 
> > 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.


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.

For example, for migration driver might want to validate
that two devices have same capability. doing it without
dma is nicer.

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

-- 
MST


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org