From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yuanhan Liu Subject: Re: [PATCH 1/2] vhost: enable any layout feature Date: Tue, 27 Sep 2016 11:11:58 +0800 Message-ID: <20160927031158.GA25823@yliu-dev.sh.intel.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Stephen Hemminger , Maxime Coquelin , dev@dpdk.org, qemu-devel@nongnu.org To: "Michael S. Tsirkin" Return-path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id C30C92BAD for ; Tue, 27 Sep 2016 05:11:33 +0200 (CEST) Content-Disposition: inline In-Reply-To: <20160926221112-mutt-send-email-mst@kernel.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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. > 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? > 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? 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