net/virtio-user: fix number of vrings calculation

  When moving to dynamic allocation of vrings metadata, the
number of vrings to allocate was incremented if the backend
supports control queue.

The problem is that the control queue metadata have to be
allocated even if the backend does not use it directly,
since the control queue is managed by the Virtio-user layer
as soon as multiqueue is negotiated..

This patch fixes this by incrementing the number of vrings
as soon as the device features have VIRTIO_NET_F_MQ.

Fixes: d57c3a601e44 ("net/virtio-user: remove max queues limitation")

Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---

I plan to squash it with faulty commit in the Virtio branch
since it has not been pulled yet by Thomas once acked and
if no objection.

 drivers/net/virtio/virtio_user/virtio_user_dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

On Fri, Feb 10, 2023 at 4:10 PM Maxime Coquelin
<maxime.coquelin@redhat.com> wrote:
>
> When moving to dynamic allocation of vrings metadata, the
> number of vrings to allocate was incremented if the backend
> supports control queue.
>
> The problem is that the control queue metadata have to be
> allocated even if the backend does not use it directly,
> since the control queue is managed by the Virtio-user layer
> as soon as multiqueue is negotiated..
>
> This patch fixes this by incrementing the number of vrings
> as soon as the device features have VIRTIO_NET_F_MQ.
>
> Fixes: d57c3a601e44 ("net/virtio-user: remove max queues limitation")
>
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>

Acked-by: David Marchand <david.marchand@redhat.com>

> ---
>
> I plan to squash it with faulty commit in the Virtio branch
> since it has not been pulled yet by Thomas once acked and
> if no objection.

No objection from me.
  

On 2/10/23 16:10, Maxime Coquelin wrote:
> When moving to dynamic allocation of vrings metadata, the
> number of vrings to allocate was incremented if the backend
> supports control queue.
> 
> The problem is that the control queue metadata have to be
> allocated even if the backend does not use it directly,
> since the control queue is managed by the Virtio-user layer
> as soon as multiqueue is negotiated..
> 
> This patch fixes this by incrementing the number of vrings
> as soon as the device features have VIRTIO_NET_F_MQ.
> 
> Fixes: d57c3a601e44 ("net/virtio-user: remove max queues limitation")
> 
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> ---
> 
> I plan to squash it with faulty commit in the Virtio branch
> since it has not been pulled yet by Thomas once acked and
> if no objection.
> 
>   drivers/net/virtio/virtio_user/virtio_user_dev.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c b/drivers/net/virtio/virtio_user/virtio_user_dev.c
> index cf58b63029..ccb4d7326b 100644
> --- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
> +++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
> @@ -575,7 +575,7 @@ virtio_user_alloc_vrings(struct virtio_user_dev *dev)
>   	bool packed_ring = !!(dev->device_features & (1ull << VIRTIO_F_RING_PACKED));
>   
>   	nr_vrings = dev->max_queue_pairs * 2;
> -	if (dev->hw_cvq)
> +	if (dev->device_features & (1ull << VIRTIO_NET_F_MQ))
>   		nr_vrings++;
>   
>   	dev->callfds = rte_zmalloc("virtio_user_dev", nr_vrings * sizeof(*dev->callfds), 0);

Squashed with d57c3a601e44 and pushed to next-virtio.

Thanks,
Maxime