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: Thu, 22 Dec 2016 08:10:35 +0000 Message-ID: <4341B239C0EFF9468EE453F9E9F4604D3C5C6B22@shsmsx102.ccr.corp.intel.com> References: <20161216143919.4909-1-ferruh.yigit@intel.com> <5846f66b-9a83-faa6-3de1-c7ae12236201@6wind.com> <4341B239C0EFF9468EE453F9E9F4604D3C5B7FE2@shsmsx102.ccr.corp.intel.com> <7801511.7yxptAly8J@xps13> <4341B239C0EFF9468EE453F9E9F4604D3C5B8459@shsmsx102.ccr.corp.intel.com> <42c7689f-a827-aa3c-777b-cfc78107d63e@6wind.com> <4341B239C0EFF9468EE453F9E9F4604D3C5B8BD7@shsmsx102.ccr.corp.intel.com> <932774d3-e0f7-7b44-1635-9015b8be6c0e@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "Yigit, Ferruh" , "Wu, Jingjing" , "Zhang, Helin" To: Vincent JARDIN , Thomas Monjalon Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 9D16310CF7 for ; Thu, 22 Dec 2016 09:10:39 +0100 (CET) In-Reply-To: <932774d3-e0f7-7b44-1635-9015b8be6c0e@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: Vincent JARDIN [mailto:vincent.jardin@6wind.com] > Sent: Tuesday, December 20, 2016 11:19 PM > To: Chen, Jing D ; Thomas Monjalon > > Cc: dev@dpdk.org; Yigit, Ferruh ; Wu, Jingjing > ; Zhang, Helin > Subject: Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel= VF on > i40e >=20 > Le 20/12/2016 =E0 05:48, Chen, Jing D a =E9crit : > > That's a collaboration with another team. we'll follow-up that but not = guarantee > > it will happen. > > May I ask if my reply make it clear? Still NAC for this patch? >=20 > Yes still nack, I am not confident with this PF approach since you are > breaking Linux PF behavior. It does not provide guarantees with PF. > Something is missing to guarantee the compatibilities. Let me introduce the rationale of API between PF and VF. There is a common head file visible to both PF and VF, which includes a set= of command and data structures, which is managed by a version number. Below is an exam= ple. Major_verion=3D1 Minor_verion=3D1 enum i40e_virtchnl_ops { CMD_GET_VERSION, CMD_RESET_VF, ...... } struct i40e_virtchnl_version_info { u32 major; u32 minor; }; ...... So, both PF and VF strictly follow the spec. VF send request with expected = command and=20 data structures to PF host. PF do sanity check and configure, finally appli= ed to HW.=20 As developing the code, it's possible to have multiple version of API occur= red with 'major_verion' or 'minor_version' changed. So, at the initialization stage, VF and PF will= use a command=20 'CMD_GET_VERSION' to negotiate what language (what version of API) they sho= uld use and setup conversation.=20 So, from my perspective, there is no issue here. In the meanwhile, we have some test models ongoing to validate combination = of Linux and=20 DPDK drivers for VF and PF. We'll fully support below 4 cases going forward= . 1. DPDK PF + DPDK VF=20 2. DPDK PF + Linux VF 3. Linux PF + DPDK VF=20 4. Linux PF + Linux VF (it's not our scope) After applied this patch, i've done below test without observing compatibil= ity issue. 1. DPDK PF + DPDK VF (middle of 16.11 and 17.02 code base). PF to support A= PI 1.0 while VF to support API 1.1/1.0=09 2. DPDK PF + Linux VF 1.5.14. PF to support 1.0, while Linux to support 1.1= /1.0 Linux PF + DPDK VF has been tested with 1.0 API long time ago. There is som= e test activities ongoing. Finally, please give strong reasons to support your NAC.