From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 228F31C00 for ; Mon, 4 Dec 2017 15:48:58 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 43B304E4CA; Mon, 4 Dec 2017 14:48:58 +0000 (UTC) Received: from [10.36.112.49] (ovpn-112-49.ams2.redhat.com [10.36.112.49]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 444BC61F25; Mon, 4 Dec 2017 14:48:56 +0000 (UTC) To: Ladi Prosek Cc: dev@dpdk.org, yliu@fridaylinux.org, tiwei.bie@intel.com, jianfeng.tan@intel.com, Laszlo Ersek References: <20171204140900.7906-1-maxime.coquelin@redhat.com> From: Maxime Coquelin Message-ID: <20185de0-3f19-b1a1-4887-3d89c4cafe44@redhat.com> Date: Mon, 4 Dec 2017 15:48:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 04 Dec 2017 14:48:58 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 0/4] Vhost: fix mq=on but VIRTIO_NET_F_MQ not negotiated X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 14:48:59 -0000 On 12/04/2017 03:27 PM, Ladi Prosek wrote: > On Mon, Dec 4, 2017 at 3:08 PM, Maxime Coquelin > wrote: >> Having QEMU started with mq=on but guest driver not negotiating >> VIRTIO_NET_F_MQ feature ends up in the vhost device to never >> start. Indeed, more queues are created in the vhost backend than >> configured. >> >> Guest drivers known to not advertise the VIRTIO_NET_F_MQ feature are >> iPXE and OVMF Virtio-net drivers. >> >> Queues are created because before starting the guest, QEMU sends >> VHOST_USER_SET_VRING_CALL requests for all queues declared in QEMU >> command line. Also, once Virtio features negotiated, QEMU sends >> VHOST_USER_SET_VRING_ENABLE requests to disable all but the first >> queue pair. >> >> This series fixes this by destroying all but first queue pair in >> the backend if VIRTIO_NET_F_MQ isn't negotiated. > The destroyed queue pairs will be re-created when an MQ-enabled driver > takes over later on, though, is that correct? Correct! When the new driver registers, QEMU sends VHOST_USER_SET_VRING_ENABLE requests to all queues in order to enable only the first queue pair, disabling all others queue pairs. In QEMU, see virtio_net_set_queues() in hw/net/virtio-net.c > iPXE and OVMF virtio-net drivers will typically not be the last ones > driving the device. They will likely load an OS equipped with a driver > that negotiates the MQ feature. Thanks! Maxime