From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Jing D" Subject: Re: [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on i40e Date: Mon, 19 Dec 2016 09:01:09 +0000 Message-ID: <4341B239C0EFF9468EE453F9E9F4604D3C5B7FE2@shsmsx102.ccr.corp.intel.com> References: <20161216143919.4909-1-ferruh.yigit@intel.com> <20161216190257.6921-1-ferruh.yigit@intel.com> <5846f66b-9a83-faa6-3de1-c7ae12236201@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "Wu, Jingjing" , "Zhang, Helin" To: Vincent JARDIN , "Yigit, Ferruh" , "dev@dpdk.org" Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 287A0D586 for ; Mon, 19 Dec 2016 10:01:13 +0100 (CET) In-Reply-To: <5846f66b-9a83-faa6-3de1-c7ae12236201@6wind.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi, Vincent, > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Vincent JARDIN > Sent: Saturday, December 17, 2016 4:36 AM > To: Yigit, Ferruh ; dev@dpdk.org > Cc: Wu, Jingjing ; Zhang, Helin > Subject: Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel= VF on > i40e >=20 > Le 16/12/2016 =E0 20:02, Ferruh Yigit a =E9crit : > > As we need to support the scenario kernel PF + DPDK VF, > > DPDK follows the interface between kernel PF + kernel VF. >=20 > Please, it has to be proven that DPDK provides the same interface that > the kernel. It seems insane to duplicate kernel's PF into the DPDK > without a strong guarantee that it is a strict same behaviour. For instan= ce, > - what will happen when the DPDK's PF will have a new feature which > is not into the kernel? > - what will happen when the Kernel's PF will have a feature with > different capabilities that the kernel? >=20 > Please, make it clear before. Currently, for me it is a nack of this seri= e. >=20 Let me try to explain. When we DPDK developed i40e drivers several years ago, we found the API an= d data structures defined in shared code for VF and PF device communication c= an satisfy DPDK's requirements, so we just followed that API. At that time, w= e'll try=20 to satisfy 3 scenarios. 1. Linux PF + Linux VF : it's not our scope. 2. Linux PF + DPDK VF: there is no problems observed since we use same API. 3. DPDK PF + DPDK VF: that's fully under control. The only scenario was not considered is DPDK PF + Linux VF. Since then, both Linux and DPDK keep developing code. Then, we found it's necessary to extend VF capability (Like promiscuous mode). It will be hard = to ask Linux PF to support that service considering upstream effort in Linux w= orld. So, supporting it in scenario of DPDK PF + DPDK VF became best candidate. B= ut=20 how can VF identify who is serving it then decide if extended request can b= e dispatched? So, DPDK PF will send a special version number for this purpose. As time passed by, we realized there some use case for DPDK PF + Linux VF a= nd it's not supported yet. Then, we found our implementation in DPDK PF is not complete= since we only had considered how to serve DPDK VF at that time. So, we need some imp= rovement on the PF host driver. Besides that, 'send a special version' to VF doesn't= work now since Linux VF can't interpret the version info. So, we behave the same as Linux = PF driver with sacrifice of extended function in DPDK VF.=20 Let me summary the chang here. 1. We shared the same interface with Linux driver from beginning.=20 2. This change will support both Linux VF and DPDK VF. 3. We'll find a way for DPDK VF identifying who is serving it so it can use= extended function in future release.