From nobody Mon May 13 22:32:04 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1561367720; cv=none; d=zoho.com; s=zohoarc; b=kWI/CQf0ZwRDpTXDT5mKVLWM7CDejrmckwO6sL8fKX5e9yXTyMl/lEWxjUxMHIVJsbCMhjlB5pmjbdIPvNzBqJgZTCzb3soXzPcWFSQwMtk1l9qTsch4nRp5rqZGAWGt81Qn6GWRmEt5pZv/BwhyQMfaNFubWg5JPpREK3BO+qw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1561367720; h=Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To:ARC-Authentication-Results; bh=YlHA6YOOr7vIEJDoOpVd1OJLABNGG9NrDYsBJkw9tVY=; b=WPdpOlTdVb7/um6EsC5Yv4MWocaXcYHm4o1Y0HyPRqdP0p8OvYcCWnS26EVedkRjui/LcYLn3ozXFneTX+3pfB/AOCIxPbmis8eOP+MI0/KMOD90r8OhxaqEv/H/EPnsi55oZeTplT9r84rUQGonKXVSPjrvGL+ajtEj+K9qN+M= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (209.51.188.17 [209.51.188.17]) by mx.zohomail.com with SMTPS id 1561367720108515.3361370313979; Mon, 24 Jun 2019 02:15:20 -0700 (PDT) Received: from localhost ([::1]:48968 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hfL4E-00054X-1g for importer@patchew.org; Mon, 24 Jun 2019 05:15:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52192) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hfL2X-0003l8-Mi for qemu-devel@nongnu.org; Mon, 24 Jun 2019 05:13:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hfL2V-0002uN-TB for qemu-devel@nongnu.org; Mon, 24 Jun 2019 05:13:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51382) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hfL2V-0001y3-J5 for qemu-devel@nongnu.org; Mon, 24 Jun 2019 05:13:27 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 722AEC05681F; Mon, 24 Jun 2019 09:13:12 +0000 (UTC) Received: from localhost (ovpn-117-224.ams2.redhat.com [10.36.117.224]) by smtp.corp.redhat.com (Postfix) with ESMTP id A327660BF7; Mon, 24 Jun 2019 09:13:05 +0000 (UTC) From: Stefan Hajnoczi To: qemu-devel@nongnu.org Date: Mon, 24 Jun 2019 10:13:04 +0100 Message-Id: <20190624091304.666-1-stefanha@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 24 Jun 2019 09:13:12 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH] docs: clarify multiqueue vs multiple virtqueues X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Sebastien Boeuf , Cathy Zhang , Stefan Hajnoczi , "Michael S. Tsirkin" Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" The vhost-user specification does not explain when VHOST_USER_PROTOCOL_F_MQ must be implemented. This may lead implementors of vhost-user masters to believe that this protocol feature is required for any device that has multiple virtqueues. That would be a mistake since existing vhost-user slaves offer multiple virtqueues but do not advertise VHOST_USER_PROTOCOL_F_MQ. For example, a vhost-net device with one rx/tx queue pair is not multiqueue. The slave does not need to advertise VHOST_USER_PROTOCOL_F_MQ. Therefore the master must assume it has these virtqueues and cannot rely on askingt the slave how many virtqueues exist. Extend the specification to explain the different between true multiqueue and regular devices with a fixed virtqueue layout. Signed-off-by: Stefan Hajnoczi Reviewed-by: Marc-Andr=C3=A9 Lureau --- Based-on: <20190621094005.4134-1-stefanha@redhat.com> --- docs/interop/vhost-user.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst index 5750668aba..7827b710aa 100644 --- a/docs/interop/vhost-user.rst +++ b/docs/interop/vhost-user.rst @@ -324,6 +324,15 @@ must support changing some configuration aspects on th= e fly. Multiple queue support ---------------------- =20 +Many devices have a fixed number of virtqueues. In this case the master +already knows the number of available virtqueues without communicating wit= h the +slave. + +Some devices do not have a fixed number of virtqueues. Instead the maximum +number of virtqueues is chosen by the slave. The number can depend on host +resource availability or slave implementation details. Such devices are c= alled +multiple queue devices. + Multiple queue support allows the slave to advertise the maximum number of queues. This is treated as a protocol extension, hence the slave has to implement protocol features first. The multiple queues feature is supported @@ -339,6 +348,14 @@ queue in the sent message to identify a specified queu= e. The master enables queues by sending message ``VHOST_USER_SET_VRING_ENABLE= ``. vhost-user-net has historically automatically enabled the first queue pair. =20 +Slaves should always implement the ``VHOST_USER_PROTOCOL_F_MQ`` protocol +feature, even for devices with a fixed number of virtqueues, since it is s= imple +to implement and offers a degree of introspection. + +Masters must not rely on the ``VHOST_USER_PROTOCOL_F_MQ`` protocol feature= for +devices with a fixed number of virtqueues. Only true multiqueue devices +require this protocol feature. + Migration --------- =20 --=20 2.21.0