From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP; 22 Dec 2016 00:10:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,387,1477983600"; d="scan'208";a="45344093" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga005.jf.intel.com with ESMTP; 22 Dec 2016 00:10:38 -0800 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 22 Dec 2016 00:10:38 -0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 22 Dec 2016 00:10:37 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id 14.03.0248.002; Thu, 22 Dec 2016 16:10:36 +0800 From: "Chen, Jing D" To: Vincent JARDIN , Thomas Monjalon CC: "dev@dpdk.org" , "Yigit, Ferruh" , "Wu, Jingjing" , "Zhang, Helin" Thread-Topic: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on i40e Thread-Index: AQHSV9weDy4lt4qYsUyBxFaIoahiUaEO5YcA///aEoCAAIpJAP//fLqAgAGBf8CAACq7AIADGopQ 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> In-Reply-To: <932774d3-e0f7-7b44-1635-9015b8be6c0e@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on i40e 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 Dec 2016 08:10:41 -0000 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.