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 3:43 PM

> > These are common commands defined across all device types in basic
> facilities section.
> > Those devices which has cvq, they define how to transport these generic
> defined commands.
> > Those devices which do not have cvq, but when they need dynamic resources,
> they will define and create one cvq.
> > As such devices will likely need more than just dynamic vq creation, for which
> it will need cvq anyway.
> 
> I think that is too complicated: not all devices will want to add a control vq for
> resource management, especially if other mechanisms are already in use. Just
> using a generic mechanism guarded by a feature bit seems much simpler.
Not really, if a complex device has dynamic resource management, it is likely to have more functionality than just q creation.
And for some reason, even if it does not, having efficient control channel for non_init is needed anyway.

It not about device wants to add/not_add a control vq. It is about how device a should offer dynamic resource management.
From device point of view, it is equally complex for the hw device to build dynamic config registers for N VQs which it never knows whether it will be used or not.

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.