OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Monday, November 27, 2023 6:22 PM
> 
> 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.

Rq populating is unrelated here.

> 
> 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). 
It is making decisions based on group and flow id ranges.
As I acked few times, that normative lines are missing and I am in middle of adding them for v7.

> 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?
It is wrong for me to put this cap in the config space which is not needed for the device initialization.

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

I donât see without this how driver can work as it does not know the valid id and group ranges to use.

Driver can use this command at init time before registering the device to the OS.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]