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 BA92E2B8B for ; Tue, 27 Sep 2016 21:56:42 +0200 (CEST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 06DA683F44; Tue, 27 Sep 2016 19:56:42 +0000 (UTC) Received: from redhat.com (dhcp-17-141.bos.redhat.com [10.18.17.141]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id u8RJueEK026803; Tue, 27 Sep 2016 15:56:41 -0400 Date: Tue, 27 Sep 2016 22:56:40 +0300 From: "Michael S. Tsirkin" To: Yuanhan Liu Cc: Stephen Hemminger , Maxime Coquelin , dev@dpdk.org, qemu-devel@nongnu.org Message-ID: <20160927224935-mutt-send-email-mst@kernel.org> References: <1474872056-24665-1-git-send-email-yuanhan.liu@linux.intel.com> <1474872056-24665-2-git-send-email-yuanhan.liu@linux.intel.com> <20160926221112-mutt-send-email-mst@kernel.org> <20160927031158.GA25823@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160927031158.GA25823@yliu-dev.sh.intel.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 27 Sep 2016 19:56:42 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 1/2] vhost: enable any layout feature 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 Sep 2016 19:56:43 -0000 On Tue, Sep 27, 2016 at 11:11:58AM +0800, Yuanhan Liu wrote: > On Mon, Sep 26, 2016 at 10:24:55PM +0300, Michael S. Tsirkin wrote: > > On Mon, Sep 26, 2016 at 11:01:58AM -0700, Stephen Hemminger wrote: > > > I assume that if using Version 1 that the bit will be ignored > > Yes, but I will just quote what you just said: what if the guest > virtio device is a legacy device? I also gave my reasons in another > email why I consistently set this flag: > > - we have to return all features we support to the guest. > > We don't know the guest is a modern or legacy device. That means > we should claim we support both: VERSION_1 and ANY_LAYOUT. > > Assume guest is a legacy device and we just set VERSION_1 (the current > case), ANY_LAYOUT will never be negotiated. > > - I'm following the way Linux kernel takes: it also set both features. > > Maybe, we could unset ANY_LAYOUT when VERSION_1 is _negotiated_? > > The unset after negotiation I proposed turned out it won't work: the > feature is already negotiated; unsetting it only in vhost side doesn't > change anything. Besides, it may break the migration as Michael stated > below. I think the reverse. Teach vhost user that for future machine types only VERSION_1 implies ANY_LAYOUT. > > Therein lies a problem. If dpdk tweaks flags, updating it > > will break guest migration. > > > > One way is to require that users specify all flags fully when > > creating the virtio net device. > > Like how? By a new command line option? And user has to type > all those features? Make libvirt do this. users use management normally. those that don't likely don't migrate VMs. > > QEMU could verify that all required > > flags are set, and fail init if not. > > > > This has other advantages, e.g. it adds ability to > > init device without waiting for dpdk to connect. > > > > However, enabling each new feature would now require > > management work. How about dpdk ships the list > > of supported features instead? > > Management tools could read them on source and destination > > and select features supported on both sides. > > That means the management tool would somehow has a dependency on > DPDK project, which I have no objection at all. But, is that > a good idea? It already starts the bridge somehow, does it not? > BTW, I'm not quite sure I followed your idea. I mean, how it supposed > to fix the ANY_LAYOUT issue here? How this flag will be set for > legacy device? > > --yliu For ANY_LAYOUT, I think we should just set in in qemu, but only for new machine types. This addresses migration concerns. But there will be more new features in the future and it is necessary to think how we will enable them without breaking migration. -- MST