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

[Cornelia Huck <cohuck@redhat.com>]

On Fri, Oct 27 2023, Parav Pandit <parav@nvidia.com> wrote:

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

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

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