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 DE7CF282 for ; Tue, 14 Feb 2017 14:54:31 +0100 (CET) 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 0F5A84E4C7; Tue, 14 Feb 2017 13:54:32 +0000 (UTC) Received: from [10.36.116.199] (ovpn-116-199.ams2.redhat.com [10.36.116.199]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1EDsSwG004033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2017 08:54:30 -0500 To: Yuanhan Liu , dev@dpdk.org References: <1485176682-12379-1-git-send-email-yuanhan.liu@linux.intel.com> Cc: Thomas Monjalon , John McNamara From: Maxime Coquelin Message-ID: <6c363701-011b-a615-a577-52145cb5d1de@redhat.com> Date: Tue, 14 Feb 2017 14:54:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <1485176682-12379-1-git-send-email-yuanhan.liu@linux.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.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 14 Feb 2017 13:54:32 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH] doc: announce API/ABI changes 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: Tue, 14 Feb 2017 13:54:32 -0000 Hi Yuanhan, On 01/23/2017 02:04 PM, Yuanhan Liu wrote: > I made a vhost ABI/API refactoring at v16.04, meant to avoid such issue > forever. Well, apparently, I lied. > > People are looking for more vhost-user options now days, other than > vhost-user net only. For example, SPDK (Storage Performance Development > Kit) are looking for chance of vhost-user SCSI and vhost-user block. > > Apparently, they also need a vhost-user backend, while DPDK already > has a (mature enough) backend, they don't want to implement it again > from scratch. They want to leverage the one DPDK provides. > > However, the last refactoring hasn't done that right, at least it's > not friendly for extending vhost-user to add more devices support. > For example, different virtio devices has its own feature set, while > APIs like rte_vhost_feature_disable(feature_mask) have no option to > tell the device type. Thus, a more proper API should look like: > > rte_vhost_feature_disable(device_type, feature_mask); I wonder if we could also change it to be per-instance, instead of disabling features globally: rte_vhost_feature_disable(vid, device_type, feature_mask); It could be useful for live-migration with different backend versions on the hosts, as it would allow to run instances with different compat modes (like running vhost's DPDK v17.08 with v17.05-only supported features). I made a proposal about cross-version migration, but we are far from a conclusion on the design. > > Besides that, few public files and structures should be renamed, to > not let it bind to virtio-net. Specifically, they are: > > - virtio_net_device_ops --> vhost_device_ops > - rte_virtio_net.h --> rte_vhost.h > > Signed-off-by: Yuanhan Liu Anyway, the change you propose is necessary: Acked-by: Maxime Coquelin Thanks, Maxime