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 287A0D586 for ; Mon, 19 Dec 2016 10:01:13 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP; 19 Dec 2016 01:01:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,372,1477983600"; d="scan'208";a="41418173" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga004.jf.intel.com with ESMTP; 19 Dec 2016 01:01:12 -0800 Received: from fmsmsx118.amr.corp.intel.com (10.18.116.18) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 19 Dec 2016 01:01:12 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by fmsmsx118.amr.corp.intel.com (10.18.116.18) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 19 Dec 2016 01:01:12 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.54]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.11]) with mapi id 14.03.0248.002; Mon, 19 Dec 2016 17:01:10 +0800 From: "Chen, Jing D" To: Vincent JARDIN , "Yigit, Ferruh" , "dev@dpdk.org" CC: "Wu, Jingjing" , "Zhang, Helin" Thread-Topic: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on i40e Thread-Index: AQHSV9weDy4lt4qYsUyBxFaIoahiUaEO5YcA 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> In-Reply-To: <5846f66b-9a83-faa6-3de1-c7ae12236201@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: Mon, 19 Dec 2016 09:01:14 -0000 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.