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


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