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 7A884388F for ; Fri, 9 Dec 2016 14:36:05 +0100 (CET) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (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 CE258624A0; Fri, 9 Dec 2016 13:36:04 +0000 (UTC) Received: from [10.36.126.4] ([10.36.126.4]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB9DZx0D012341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Dec 2016 08:36:01 -0500 To: Yuanhan Liu , "Michael S. Tsirkin" , "Daniel P. Berrange" References: <20161011173526-mutt-send-email-mst@kernel.org> <20161117082902.GM5048@yliu-dev.sh.intel.com> <20161117094936.GN5048@yliu-dev.sh.intel.com> <20161117192445-mutt-send-email-mst@kernel.org> <20161122130223.GW5048@yliu-dev.sh.intel.com> <20161122164143-mutt-send-email-mst@kernel.org> <20161124063129.GE5048@yliu-dev.sh.intel.com> Cc: dev@dpdk.org, Stephen Hemminger , qemu-devel@nongnu.org, libvir-list@redhat.com, vpp-dev@lists.fd.io, =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= From: Maxime Coquelin Message-ID: <9b73a012-fb7a-4b7c-0dfe-6ef4b8cb48d2@redhat.com> Date: Fri, 9 Dec 2016 14:35:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161124063129.GE5048@yliu-dev.sh.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 09 Dec 2016 13:36:05 +0000 (UTC) Subject: Re: [dpdk-dev] dpdk/vpp and cross-version migration for vhost X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 13:36:05 -0000 ++Daniel for libvirt On 11/24/2016 07:31 AM, Yuanhan Liu wrote: >>>>>>>> As version here is an opaque string for libvirt and qemu, >>>>>>>> > > > > > >>anything can be used - but I suggest either a list >>>>>>>> > > > > > >>of values defining the interface, e.g. >>>>>>>> > > > > > >>any_layout=on,max_ring=256 >>>>>>>> > > > > > >>or a version including the name and vendor of the backend, >>>>>>>> > > > > > >>e.g. "org.dpdk.v4.5.6". >>> > > >>> > > The version scheme may not be ideal here. Assume a QEMU is supposed >>> > > to work with a specific DPDK version, however, user may disable some >>> > > newer features through qemu command line, that it also could work with >>> > > an elder DPDK version. Using the version scheme will not allow us doing >>> > > such migration to an elder DPDK version. The MTU is a lively example >>> > > here? (when MTU feature is provided by QEMU but is actually disabled >>> > > by user, that it could also work with an elder DPDK without MTU support). >>> > > >>> > > --yliu >> > >> > OK, so does a list of values look better to you then? > Yes, if there are no better way. > > And I think it may be better to not list all those features, literally. > But instead, using the number should be better, say, features=0xdeadbeef. > > Listing the feature names means we have to come to an agreement in all > components involved here (QEMU, libvirt, DPDK, VPP, and maybe more > backends), that we have to use the exact same feature names. Though it > may not be a big deal, it lacks some flexibility. > > A feature bits will not have this issue. I initially thought having key/value pairs would be more flexible, and could allow migrating to another application if compatible (i.e. from OVS to VPP, and vice versa...) without needing synchronization between the applications. But Daniel pointed me out that it would add a lot of complexity on management tool side, as it would need to know how to interpret these key/value pairs. I think his argument is very valid. So maybe the best way would be the version string, letting the application (OVS-DPDK/VPP/...) specify which version it is compatible with. For the downsides, as soon as a new feature is supported in vhost-user application, the new version will not be advertised as compatible with the previous one, even if the user disables the feature in Qemu (as pointed out by Yuanhan). The question is are we ready to add complexity on management tool side to permit more migration cases, or do we prefer keeping it simple but sometimes prevent migration even if technically possible? -- Maxime