RE: [virtio-comment] RE: [PATCH v3 2/2] content: Support enabling virtqueue after DRIVER_OK stage

[Parav Pandit <parav@nvidia.com>]

> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Friday, October 27, 2023 7:07 PM
> 
> On Fri, Oct 27 2023, Parav Pandit <parav@nvidia.com> wrote:
> 
> >> From: Cornelia Huck <cohuck@redhat.com>
> >> Sent: Friday, October 27, 2023 5:16 PM
> >
> >> "config registers" are transport specific. If they aren't an
> >> efficient method, then the transport needs to come up with something
> >> else -- but it's the task of the
> >> *transport* to provide something useful. The device should not need
> >> to do anything beyond specifying that it can support adding vqs
> >> dynamically, and exposing the upper boundary to the number of queues.
> >>
> > You are welcome to propose to PCI-SIG such enhancements. :) We cannot
> > keep blind eye to transport and say, virtio will expand infinity registers without
> caring about underlying transport limitations and efficiencies.
> >
> > There have been many discussions in past across many device + cpu vendors
> in various virtio and non virtio forums.
> > I would like to share that the industry does not prefer to put things as infinite
> set of registers unless its most fundamental thing needed to bootstrap the
> device.
> 
> Where does that "infinite" stuff come from? It makes no sense to me at all -- the
> device type supports a certain upper bound, the transport supports a certain
> upper bound, the device on the transport ends up supporting the lower of the
> two...
> 
We are not adding config registers for dynamic device and resource configuration.
Not even for reading capabilities either.

The infinite notion comes from the fact that, you propose to extend the pci transport by just extending more and more config registers.
And this is not the good direction.

The lower of two values is really very low for real devices.

> (And does the PCI transport really only have one way of implementing
> this?)
> 
PCI transport do not define how one should create dynamic resources efficiently and scalable way.
This is something every device type do by themselves.

Which way are you referring to?

> >
> >> >
> >> > Out of 19 devices, 6 devices already has cvq.
> >> > Out of remaining 13 devices, 12 devices have fixed number of queues
> >> > as they
> >> small enough in functionality that won't need a scale and dynamism either.
> >> > So for dynamic resource management reusing the existing cvq is more
> >> efficient for the devices.
> >>
> >> They have a device-specific cvq, which is used in a device-specific
> >> way for device-specific purposes. I don't see how turning them into
> >> frankencvqs is "efficient".
> > Sure, they are device specific, but we can define generic set of commands in
> basic facilities, which each device type can send via their cvq.
> > It is only matter of drafting it.
> 
> Nope, it's also a matter of implementing it, and wedging in something
> sidewards does not sound like a good design to me.
I am not following your suggestion.
What do you propose apart from config registers? Can you please explain?