Re: [PATCH] virtio_net: return error when there is no virtqueue or MQ isn't support

On 04/22/2014 11:23 AM, Amos Kong wrote:

On Tue, Apr 22, 2014 at 11:11:50AM +0800, Jason Wang wrote:

quoted

On 04/21/2014 11:11 PM, Amos Kong wrote:

quoted

Currently ethtool returns zero if there is no virtqueue or MQ isn't
support, we should return -ENOTSUPP to notice user.

Signed-off-by: Amos Kong <redacted>
---
 drivers/net/virtio_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 8a852b5..eaf8266 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c

@@ -1053,7 +1053,7 @@ static int virtnet_set_queues(struct virtnet_info *vi, u16 queue_pairs)
 	struct net_device *dev = vi->dev;
 
 	if (!vi->has_cvq || !virtio_has_feature(vi->vdev, VIRTIO_NET_F_MQ))
-		return 0;
+		return -ENOTSUPP;
 
 	s.virtqueue_pairs = queue_pairs;
 	sg_init_one(&sg, &s, sizeof(s));

How about check the return value of virtnet_set_queues() in
virtnet_restore() also?

If we migrate a guest from MQ supported side to MQ non-supported side,
virtnet_restore() will not return error right now.

If we return error when no vq or no mq support, and check return value
of virtnet_set_queues() in virtnet_restore(), migration will fail. 
Is it expected?

I think what you mean is restore not migration here. The point is not to
execute VIRTIO_NET_CTRL_MQ when multiqueue is not supported, so it's the
caller responsibility to pass a valid queue_pairs to
virtnet_set_queues(). This patch is not necessary, your last patch is
fine enough to solve the issue. Do you agree?

Thanks