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

[Cornelia Huck <cohuck@redhat.com>]

On Thu, Oct 26 2023, Parav Pandit <parav@nvidia.com> wrote:

>> From: Michael S. Tsirkin <mst@redhat.com>
>> Sent: Thursday, October 26, 2023 2:58 PM
>> 
>> On Thu, Oct 26, 2023 at 09:24:06AM +0000, Parav Pandit wrote:
>> >
>> > > From: Michael S. Tsirkin <mst@redhat.com>
>> > > Sent: Thursday, October 26, 2023 2:46 PM
>> >
>> > > > So, this will still provide the unified approach when/if needed on
>> > > > other
>> > > devices.
>> > >
>> > > What do you want to know? Whether dynamically adding/deleting queues
>> > > is useful generally? For example, queue per CPU is not uncommon to
>> > > avoid need for locks. In the presence of CPU hotplug, the natural
>> > > thing to do is to add/delete them.
>> > So for those devices who care for such performance, it is reasonable for them
>> to have the cvq providing channel for complex and dynamic commands.
>> 
>> Again, let's please not waste time adding this piecemeal to each device type,
>> this is clearly a generic thing that belongs in the core.
>
> Maybe I didn't explain well.
>
> I am proposing a generic way for all device types as following.
> 1. create cvq as main communication channel for resource create/destroy
> 2. create resource dynamically using this cvq
>
> 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.