On Thu, Jun 20, 2024 at 05:38:22PM +0800, Heng Qi wrote:

On Thu, 20 Jun 2024 04:32:15 -0400, "Michael S. Tsirkin" [off-list ref] wrote:

quoted

On Thu, Jun 20, 2024 at 03:29:15PM +0800, Heng Qi wrote:

quoted

On Wed, 19 Jun 2024 17:19:12 -0400, "Michael S. Tsirkin" [off-list ref] wrote:

quoted

On Thu, Jun 20, 2024 at 12:19:05AM +0800, Heng Qi wrote:

quoted

@@ -5312,7 +5315,7 @@ static int virtnet_find_vqs(struct virtnet_info *vi)
 
 	/* Parameters for control virtqueue, if any */
 	if (vi->has_cvq) {
-		callbacks[total_vqs - 1] = NULL;
+		callbacks[total_vqs - 1] = virtnet_cvq_done;
 		names[total_vqs - 1] = "control";
 	}
 

If the # of MSIX vectors is exactly for data path VQs,
this will cause irq sharing between VQs which will degrade
performance significantly.

So no, you can not just do it unconditionally.

The correct fix probably requires virtio core/API extensions.

If the introduction of cvq irq causes interrupts to become shared, then
ctrlq need to fall back to polling mode and keep the status quo.

Thanks.

I don't see that in the code.

I guess we'll need more info in find vqs about what can and what can't share irqs?

I mean we should add fallback code, for example if allocating interrupt for ctrlq
fails, we should clear the callback of ctrlq.

I have no idea how you plan to do that. interrupts are allocated in
virtio core, callbacks enabled in drivers.

quoted

Sharing between ctrl vq and config irq can also be an option.

Not sure if this violates the spec. In the spec, used buffer notification and
configuration change notification are clearly defined - ctrlq is a virtqueue
and used buffer notification should be used.

Thanks.

It is up to driver to choose which msix vector will trigger.
Nothing says same vector can't be reused.
Whether devices made assumptions based on current driver
behaviour is another matter.

quoted

quoted

quoted

-- 
MST