From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id ACBCD8DED for ; Tue, 27 Oct 2015 11:41:27 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 27 Oct 2015 03:41:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,204,1444719600"; d="scan'208";a="672594949" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga003.jf.intel.com with ESMTP; 27 Oct 2015 03:41:27 -0700 Received: from fmsmsx152.amr.corp.intel.com (10.18.125.5) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 27 Oct 2015 03:41:25 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX152.amr.corp.intel.com (10.18.125.5) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 27 Oct 2015 03:41:25 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.96]) by shsmsx102.ccr.corp.intel.com ([169.254.2.253]) with mapi id 14.03.0248.002; Tue, 27 Oct 2015 18:41:24 +0800 From: "Xie, Huawei" To: "Michael S. Tsirkin" , Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v8 3/8] vhost: vring queue setup for multiple queue support Thread-Index: AdEQpAW+9EXUS+gqQ2W6qKAGGEKRxw== Date: Tue, 27 Oct 2015 10:41:23 +0000 Message-ID: References: <1445399294-18826-1-git-send-email-yuanhan.liu@linux.intel.com> <20151027093041.GI3115@yliu-dev.sh.intel.com> <20151027113807-mutt-send-email-mst@redhat.com> <1520656.Lg374xclAN@xps13> <20151027115257-mutt-send-email-mst@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" , "marcel@redhat.com" Subject: Re: [dpdk-dev] [PATCH v8 3/8] vhost: vring queue setup for multiple queue support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 10:41:28 -0000 On 10/27/2015 5:56 PM, Michael S. Tsirkin wrote:=0A= > On Tue, Oct 27, 2015 at 10:51:14AM +0100, Thomas Monjalon wrote:=0A= >> 2015-10-27 11:42, Michael S. Tsirkin:=0A= >>> On Tue, Oct 27, 2015 at 05:30:41PM +0800, Yuanhan Liu wrote:=0A= >>>> On Tue, Oct 27, 2015 at 11:17:16AM +0200, Michael S. Tsirkin wrote:=0A= >>>>> Looking at that, at least when MQ is enabled, please don't key=0A= >>>>> stopping queues off GET_VRING_BASE.=0A= >>>> Yes, that's only a workaround. I guess it has been there for quite a= =0A= >>>> while, maybe at the time qemu doesn't send RESET_OWNER message.=0A= >>> RESET_OWNER was a bad idea since it basically closes=0A= >>> everything.=0A= >>>=0A= >>>>> There are ENABLE/DISABLE messages for that.=0A= >>>> That's something new,=0A= >>> That's part of multiqueue support. If you ignore them,=0A= >>> nothing works properly.=0A= >>>=0A= >>>> though I have plan to use them instead, we still=0A= >>>> need to make sure our code work with old qemu, without ENABLE/DISABLE= =0A= >>>> messages.=0A= >>> OK but don't rely on this for new code.=0A= >>>=0A= >>>> And I will think more while enabling live migration: I should have=0A= >>>> more time to address issues like this at that time.=0A= >>>>=0A= >>>>> Generally guys, don't take whatever QEMU happens to do for=0A= >>>>> granted! Look at the protocol spec under doc/specs directory,=0A= >>>>> if you are making more assumptions you must document them!=0A= >>>> Indeed. And we will try to address them bit by bit in future.=0A= >>>>=0A= >>>> --yliu=0A= >>> But don't pile up these workarounds meanwhile. I'm very worried. The= =0A= >>> way you are carrying on, each new QEMU is likely to break your=0A= >>> assumptions.=0A= >> I think it may be saner to increase the minimum QEMU version supported i= n=0A= >> each DPDK release, dropping old stuff progressively.=0A= >> Michael, you are welcome to suggest how to move precisely.=0A= >> Thanks=0A= > This doesn't work for downstreams which need to backport fixes and=0A= > features.=0A= >=0A= > Just go by the spec, and if you find issues, fix them at the=0A= > source instead of working around them - the code is open.=0A= >=0A= > For new features, we have protocol feature bits.=0A= To me, one requirement is we need clear message(or spec) to know when=0A= virtio device (or better queue granularity) could be processed or should=0A= be stopped from processing. We need have a clear state machine in mind.=0A= For another requirement, we hope QEMU could send vhost an ID to let=0A= vhost-user have the ability to identify the connection. Let us discuss=0A= this in other thread.=0A= =0A= =0A=