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

[Parav Pandit <parav@nvidia.com>]

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