[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] Re: [PATCH v18] virtio-net: support inner header hash
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]