RE: [virtio-comment] Re: [PATCH v6 2/5] virtio-net: Add flow filter capabilities read commands

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Friday, November 24, 2023 11:48 AM
> 
> On Fri, Nov 24, 2023 at 05:40:26AM +0000, Parav Pandit wrote:
> > > we
> > > strongly suggest that *drivers* support both old and new mechanism,
> > > and then *devices* will only implement what's required.
> > There are other examples in the same document that makes things worst
> with old and new.
> >
> > Also there is literally no way to enforce that driver supports both
> > and new. It is just sounds like an excuse to force infinite config
> > space.
> 
> There is a very simple method though.  We allow devices to expose a subset of
> features when DMA is not used. So drivers that want maximum features will
> always opt for DMA. We can also strongly recommend that all drivers support
> DMA if available.
Yeah, don't see how this is elegant at all with all mixed bits.
Nor do I see any enforcement, single method via cvq still holds strong.

> 
> 
> 
> > The method proposed here is elegant and clearly promote one way to do
> things for driver and device with predictability.
> >
> 
> I don't see it as elegant at all. What is elegant is *a single tag* that describes
> each property of the device. And this single tag should be good for everything:
> driver, provisioning, migration. And config space offset serves as such.
The single tag is the set of structures.
Provisioning access them via owner device.
Member driver access them via CVQ or 1.2 legacy config space.