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

[Parav Pandit <parav@nvidia.com>]

> From: Eugenio Perez Martin <eperezma@redhat.com>
> Sent: Thursday, October 26, 2023 1:58 PM

> > Let me work on more mature interface that solves following challenges.
> > 1. ability to create a virtqueue dynamically after driver_ok 2.
> > ability to create virtqueue with one or multiple physical addresses 3.
> > ability for the device to return error if it cannot create dynamic vq
> > creation
> >
> 
> I think 1 is very complex for the simpler use case of delaying the enabling of the
> dataplane, especially because virtio-net already assigns "the last queue" for
> CVQ. It would require changes to it too.
Vq numbers do not change for virtio-net when enabled dynamically after driver_ok.
This is because max_virtqueue_pair is RO parameter.

It is not complex because is it only about defining a command format for create and destroy a vq to run on the cvq.
It is actually the opposite because there is good protocol and handshake.

Many devices has simple array of physical addresses for queue creation.
So command is straightforward.

> 
> 2 can be solved if we allow resetting a queue before DRIVER_OK, 
This is just the hack of enabling and reset for no apparent gain.
Future devices may have many queues and enabling 1000 queues, resetting them is just an ugly interface.

> Would that work for the use case you have in mind?
It works but not spec worthy method to build which just delays the whole device init flow with no gain.

> 
> 3 can be solved by re-reading the queue_enable field? This is the way we're
> already using for checking DRIVER_OK in the PCI transport.
Only polarity is not enough. An error code such as out of resource/busy/success is needed.

The whole point is to not abuse these basic init time registers at run time.
> 
> > The question is, do we need this generic facility beyond virtio-net?
> 
> I would try to avoid solutions specific for virtio-net, as other devices may need
> to reuse them and it would be bad to need to add quirks for that.
No need to add the quirk.
But I would like to listen if there is any concrete requirement.
And if there is, possibly such device can add the cvq at that point for dynamic work.
So, this will still provide the unified approach when/if needed on other devices.