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 12:58:47PM +0000, Parav Pandit wrote:
> 
> > 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.

it is related because you need to know which rqs to populate and
for this knowning how traffic is shaped, matters.

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

Re-read what you just wrote and contrast with "is not needed for the
device initialization".

Do I need to spell how you are contradicting yourself here?

Do you take "device initialization" to mean some hardware thing?
This is not what it means. It means whatever driver does once,
before it starts using the device.
-- 
MST


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/