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 3D6EE2C63 for ; Mon, 26 Sep 2016 21:24:58 +0200 (CEST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 A0A90C00B6FA; Mon, 26 Sep 2016 19:24:57 +0000 (UTC) Received: from redhat.com (vpn-54-197.rdu2.redhat.com [10.10.54.197]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id u8QJOtqU010564; Mon, 26 Sep 2016 15:24:56 -0400 Date: Mon, 26 Sep 2016 22:24:55 +0300 From: "Michael S. Tsirkin" To: Stephen Hemminger Cc: Yuanhan Liu , Maxime Coquelin , dev@dpdk.org, qemu-devel@nongnu.org Message-ID: <20160926221112-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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 26 Sep 2016 19:24:57 +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: Mon, 26 Sep 2016 19:24:58 -0000 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 > 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. 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. -- MST