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 5:04 PM
> 
> On Fri, Nov 24, 2023 at 06:31:03AM +0000, Parav Pandit wrote:
> >
> > > 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.
> 
> It's elegant because simple low end devices can cheaply implement MMIO and
> not worry about DMA.
> 
It is not of much help in this case because any low end cheap device which want to support flow filter commands need to have CVQ anyway.
And hence reusing the same CVQ is more elegant that already does the DMA.

So CVQ is fulfilling all the below needs.
1. Single interface for the get/set config flow filters
2. DMA the data
3. Not have any partial issues
4. provides consistent structures that provisioning side will be able to use

> > Nor do I see any enforcement, single method via cvq still holds strong.
> 
> You don't need to enforce things, if people want to put a lot of RAM on device
> and put it in a register let them.
> 
Not enforced. It uses the CVQ for flow group and flow filter life cycles and for the sharing this config as well.
Also aligns with stats that rest also agreed on.

> >
> > >
> > >
> > >
> > > > 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.
> 
> I have no idea how this will work. If migration format i started reviewing is
> anything to go by then there will be a huge elaborate structure nothing single
> or simple. By comparison there's already a proposal how provisioning can
> work by supplying config space.
> it is just a clean model to grasp.
> 
The provisioning model is simple is to supply all the configuration.
To draw parallels to some sw side,

There is per functionality socket option to set things, instead of one giant structure.
There is per functionality ethtool option/cmd instead of Set ALL/get ALL enforcement.

> > Provisioning access them via owner device.
> > Member driver access them via CVQ or 1.2 legacy config space.
>