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

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

On Mon, Nov 27, 2023 at 11:12:47AM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Monday, November 27, 2023 4:40 PM
> > 
> > On Mon, Nov 27, 2023 at 10:19:45AM +0000, Parav Pandit wrote:
> > > >
> > > > > The bright line in based on this usage: bootstap or not.
> > > > > If its runtime, sure have it over CVQ.
> > > > > Following the nice tenet of B.2 of the spec snippet: "Device
> > > > > configuration
> > > > space should only be used for initialization-time parameters"
> > > > > Thatâs it.
> > > > > And everyone is already aligned to it.
> > > >
> > > > Absolutely. Specifically, when do you expect driver to probe these
> > > > caps? As you yourself explained, it has to do it before ethtool
> > > > calls - that clearly means it will do it in probe.
> > > > To me this simply screams "initialization time".
> > > >
> > > It can be done in driver probe routine after DRIVER_OK, this is fine.
> > 
> > No - it is preferable to do it before DRIVER_OK because VQs are probed and
> > initialized before DRIVER_OK.
> > For example, it is reasonable to decide to only enable MQ if specific flow
> > control can later be enabled.
> 
> For flow filter related caps has no hard dependency to it before driver_ok, same as stats.
> MQ has users even without flow filter.

driver ok is not the end of driver initialization. Things like
pre-populating receive queues are also part of that.

Yes, there is a dependency.  The capability is either not useful at all
(as in the current form - driver makes no decisions here so it
is pointless). Or it will be useful and then it has to be
probed at init time so the data is available at runtime
when decisions are to be made. How *hard* is this dependency?
I don't know. I do know that 100% of drivers will either not
use this command at all or use it at init time.


-- 
MST