[dpdk-dev] [PATCH v5 0/4] Vhost: fix mq=on but VIRTIO_NET_F_MQ not negotiated

Paolo Bonzini pbonzini at redhat.com
Wed Dec 13 10:15:22 CET 2017

On 13/12/2017 09:51, Maxime Coquelin wrote:
> This series fixes this by destroying all but first queue pair in
> the backend if VIRTIO_NET_F_MQ isn't negotiated. First patches
> makes sure that VHOST_USER_SET_FEATURES request doesn't change
> Virtio features while the device is running, which should never
> happen as per the Virtio spec. This helps to make sure vitqueues
> aren't destroyed while being processed, but also protect from
> other illegal features changes (e.g. VIRTIO_NET_F_MRG_RXBUF).

Hi Maxime,

I think this series is wrong from the virtio spec's point of view.  If
the driver requests VIRTIO_NET_F_MQ, that does not mean "the driver
knows about multiqueue", it only means that "the driver wants to read
max_virtqueue_pairs" from configuration space.

Just like it's perfectly fine for a device to propose VIRTIO_NET_F_MQ
and set max_virtqueue_pairs=1, a driver can negotiate VIRTIO_NET_F_MQ
and then skip initialization of some virtqueues.

In fact, for virtio-net there is an explicit way to say how many
virtqueue pairs are available; the virtio spec's section 5.1.5 (Network
device, Device Initialization) mentions that

	Even with VIRTIO_NET_F_MQ, only receiveq1, transmitq1 and
	controlq are used by default. The driver would send the
	VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command specifying the number of
	the transmit and receive queues to use.



More information about the dev mailing list