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, 26 Dec 2016 11:59:00 +0000 Message-ID: <4341B239C0EFF9468EE453F9E9F4604D3C5CA3DA@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> <4341B239C0EFF9468EE453F9E9F4604D3C5C6B22@shsmsx102.ccr.corp.intel.com> <7b981a32-9837-5e5c-dc0d-3c4781341aeb@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: Thomas Monjalon , "dev@dpdk.org" , "Yigit, Ferruh" , "Wu, Jingjing" , "Zhang, Helin" To: Vincent JARDIN Return-path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 689AA2B94 for ; Mon, 26 Dec 2016 12:59:05 +0100 (CET) In-Reply-To: <7b981a32-9837-5e5c-dc0d-3c4781341aeb@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" Vincent, Sorry, I missed this reply. >=20 > Le 22/12/2016 =E0 09:10, Chen, Jing D a =E9crit : > > In the meanwhile, we have some test models ongoing to validate > > combination of Linux and DPDK drivers for VF and PF. We'll fully suppor= t > below 4 cases going forward. > > 1. DPDK PF + DPDK VF > > 2. DPDK PF + Linux VF >=20 > + DPDK PF + FreeBSD VF > + DPDK PF + Windows VF > + DPDK PF + OS xyz VF >=20 If all drivers follow same API spec, what's the problem here? What extra DPDK PF effort you observed? > > 3. Linux PF + DPDK VF > > 4. Linux PF + Linux VF (it's not our scope) >=20 > So, you confirm the issue: having DPDK becoming a PF, even if SRIOV proto= col > includes version-ing, it doubles the combinatory cases. If extended functions are needed, the answer is yes. That's not a big problem, right? I have several workarounds/approaches to support extended funcs while following original API spec. I can fix it in t= his release. In order to have a mature solution, I left it here for further imp= lementation. >=20 > > > > After applied this patch, i've done below test without observing > compatibility issue. > > 1. DPDK PF + DPDK VF (middle of 16.11 and 17.02 code base). PF to suppo= rt > API 1.0 while VF > > to support API 1.1/1.0 > > 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 some test activities ongoing. > > > > Finally, please give strong reasons to support your NAC. >=20 > I feel bad because I do recognize the strong and hard work that you have = done > on this PF development, but I feel we need first to assess if DPDK should > become a PF or not. I know ixgbe did open the path and that they are some > historical DPDK PF supports in Intel NICs, but before we generalize it, w= e have > to make sure we are not turning this DataPlane development Kit into a > ControlPlane Driver Kit that we are scared to upstream into Linux kernel.= Even > if "DPDK is not Linux", it does not mean that Linux should be ignored. In= case > of DPDK on other OS, same, their PF could be extended too. >=20 Thanks for the recognition of our work on PF driver. :) > So currently, yes, I do keep a nack't >=20 > Since DPDK PF features can be into Linux PF features too and since Linux = (and > other hypervisors) has already some tools to manage PF (see iproute2, etc= .), > why should we have an other management path with DPDK? > DPDK is aimed to be a Dataplane Development kit, not a management/control > plane driver kit. Before we debated on Dataplane and ControPlane, can you answer me a questio= n, why we have generic filter API? Is it a API for dataplane? I can't imagine that we'll have to say 'you need to use Linux PF' driver wh= en users want to deploy PF + VF cases. Why we can't provide an alternative option. t= hey are not exclusive and users can decide which combination is better for them.=20 The reason why we developed DPDK PF host driver is we have requirements fro= m users. Our motivation is simple, there are requirements, we satisfy them. Sorry, you NACK can't convince me. >=20 > Assuming you want to use DPDK PF for dataplane feature, that could be OK > then, using: > - configure one VF on the hypervisor from Linux's PF, let's name if > VF_forPFtraffic, see http://dpdk.org/doc/guides/howto/flow_bifurcation.ht= ml > - have no (or few IO)s to the PF's queue > - assign the traffic to all VF_forPFtraffic's queues of the hypervisor= , > - run DPDK into the hypervisor's VF_forPFtraffic >=20 > Doing so, we get the same benefit of running DPDK over PF or running DPDK > over VF_forPFtraffic, don't we? It is a benefit of: > http://dpdk.org/doc/guides/howto/flow_bifurcation.html >=20 > Thank you, > Vincent >=20