From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by dpdk.org (Postfix) with ESMTP id A7C2F2C36 for ; Thu, 22 Mar 2018 15:18:50 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 976B6722C0; Thu, 22 Mar 2018 14:18:49 +0000 (UTC) Received: from [10.36.112.17] (ovpn-112-17.ams2.redhat.com [10.36.112.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8F99D2166BAE; Thu, 22 Mar 2018 14:18:46 +0000 (UTC) To: "Wang, Zhihong" , "dev@dpdk.org" Cc: "Tan, Jianfeng" , "Bie, Tiwei" , "yliu@fridaylinux.org" , "Liang, Cunming" , "Wang, Xiao W" , "Daly, Dan" References: <1517614137-62926-1-git-send-email-zhihong.wang@intel.com> <20180227101342.18521-1-zhihong.wang@intel.com> <20180227101342.18521-4-zhihong.wang@intel.com> <8F6C2BD409508844A0EFC19955BE09415140BA2B@SHSMSX103.ccr.corp.intel.com> From: Maxime Coquelin Message-ID: <95a2dde0-494f-1fd4-2d4b-4b717fd83cc4@redhat.com> Date: Thu, 22 Mar 2018 15:18:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <8F6C2BD409508844A0EFC19955BE09415140BA2B@SHSMSX103.ccr.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 22 Mar 2018 14:18:49 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 22 Mar 2018 14:18:49 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'maxime.coquelin@redhat.com' RCPT:'' Subject: Re: [dpdk-dev] [PATCH v3 3/5] vhost: add apis for datapath configuration 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: Thu, 22 Mar 2018 14:18:50 -0000 Hi, On 03/22/2018 09:22 AM, Wang, Zhihong wrote: > > >> -----Original Message----- >> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] >> Sent: Thursday, March 22, 2018 5:08 AM >> To: Wang, Zhihong ; dev@dpdk.org >> Cc: Tan, Jianfeng ; Bie, Tiwei >> ; yliu@fridaylinux.org; Liang, Cunming >> ; Wang, Xiao W ; Daly, >> Dan >> Subject: Re: [PATCH v3 3/5] vhost: add apis for datapath configuration >> >> >> >> On 02/27/2018 11:13 AM, Zhihong Wang wrote: >>> This patch adds APIs for datapath configuration. The eid and did of the >>> vhost-user socket can be configured to identify the actual device. >>> >>> When the default software datapath is used, eid and did are set to -1. >>> When alternative datapath is used, eid and did are set by app to specify >>> which device to use. Each vhost-user socket can have only 1 connection in >>> this case. >>> >>> Signed-off-by: Zhihong Wang >>> --- >>> lib/librte_vhost/rte_vhost.h | 70 >> ++++++++++++++++++++++++++++++++++ >>> lib/librte_vhost/rte_vhost_version.map | 6 +++ >>> lib/librte_vhost/socket.c | 65 >> +++++++++++++++++++++++++++++++ >>> lib/librte_vhost/vhost.c | 50 ++++++++++++++++++++++++ >>> lib/librte_vhost/vhost.h | 10 +++++ >>> 5 files changed, 201 insertions(+) >>> >> >> Isn't the notion of EID & DID Intel specifics? >> At vhost API level, shouldn't we only care of the offload device ID? > > It's not vendor specific: Engine id refers to an engine which is a device > on a bus, the engine could have multiple queue pairs or virtual functions. > The driver can manage them to present multiple vhost ports with vDPA to > application, so logically the concept of device id exists. > > In a lot of acceleration cases, application needs to be able to choose the > exact port to use instead of letting the driver to decide (because it does > make a difference), therefore it's necessary to expose the device id here. Yes, but if I understood correctly with the IFCVF driver, we could pass directly the virtual function to the vhost-user lib, no need to specify the engine. We would just need to register one device per VF, but that looks like the right think to do looking at how IFCVF manages MAC addresses and link status for example. Thanks, Maxime