From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id E19A92B94 for ; Mon, 26 Dec 2016 13:17:20 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP; 26 Dec 2016 04:17:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,404,1477983600"; d="scan'208";a="802390485" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by FMSMGA003.fm.intel.com with ESMTP; 26 Dec 2016 04:17:19 -0800 Received: from fmsmsx121.amr.corp.intel.com (10.18.125.36) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 26 Dec 2016 04:17:18 -0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx121.amr.corp.intel.com (10.18.125.36) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 26 Dec 2016 04:17:18 -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; Mon, 26 Dec 2016 20:17:16 +0800 From: "Chen, Jing D" To: Vincent JARDIN , "dev@dpdk.org" CC: "Yigit, Ferruh" , "Wu, Jingjing" Thread-Topic: [PATCH 0/4] enhancement to i40e PF host driver Thread-Index: AQHSXOoOfy13uei6s0258c4Qecxx26EU9vAAgAUyp7A= Date: Mon, 26 Dec 2016 12:17:16 +0000 Message-ID: <4341B239C0EFF9468EE453F9E9F4604D3C5CA480@shsmsx102.ccr.corp.intel.com> References: <1482476332-21376-1-git-send-email-jing.d.chen@intel.com> <64ddfd77-e71e-298e-687a-a9991f8c64ee@6wind.com> In-Reply-To: <64ddfd77-e71e-298e-687a-a9991f8c64ee@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZGE2YzNmZTgtNzg3MC00ZDU4LThlOTUtNTM1YjdmM2IwMWI4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjBNWHBCV1BZRHNhbzVoYmlLU2hKeW5xa0ZGeXNIQ2ROT0tudER1WjFzNk09In0= x-ctpclassification: CTP_IC 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 0/4] enhancement to i40e PF host driver 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, 26 Dec 2016 12:17:21 -0000 Hi, Vincent, Since original patch set are split into 2 different patches, can we discuss in this thread? Attach original discussion below. Sorry for top-post. >=20 > Le 22/12/2016 =E0 09:10, Chen, Jing D a =E9crit : > > In the meanwhile, we have some test models ongoing to validate=20 > > combination of Linux and DPDK drivers for VF and PF. We'll fully=20 > > support > 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=20 > protocol 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 s= upport extended funcs while following original API spec. I can fix it in th= is release. In order to have a mature solution, I left it here for further = implementation. >=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=20 > > support > 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=20 > > support 1.1/1.0 > > > > Linux PF + DPDK VF has been tested with 1.0 API long time ago. There=20 > > 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=20 > have done on this PF development, but I feel we need first to assess=20 > if DPDK should become a PF or not. I know ixgbe did open the path and=20 > that they are some historical DPDK PF supports in Intel NICs, but=20 > before we generalize it, we have to make sure we are not turning this=20 > DataPlane development Kit into a ControlPlane Driver Kit that we are=20 > scared to upstream into Linux kernel. Even if "DPDK is not Linux", it=20 > 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=20 > Linux (and other hypervisors) has already some tools to manage PF (see=20 > iproute2, etc.), why should we have an other management path with DPDK? > DPDK is aimed to be a Dataplane Development kit, not a=20 > 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. they are not exclusive and users can decide which combination is be= tter 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=20 > OK then, using: > - configure one VF on the hypervisor from Linux's PF, let's name if=20 > 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=20 > 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 > > -----Original Message----- > From: Vincent JARDIN [mailto:vincent.jardin@6wind.com] > Sent: Friday, December 23, 2016 8:53 PM > To: Chen, Jing D ; dev@dpdk.org > Cc: Yigit, Ferruh ; Wu, Jingjing > > Subject: Re: [PATCH 0/4] enhancement to i40e PF host driver >=20 > Thanks for this update. >=20 > Still, I would like to get good arguments why DPDK should be a PF because= it > creates fragmentations. Please, first, let's reply to: > http://dpdk.org/ml/archives/dev/2016-December/053107.html >=20 > Having both Linux and DPDK being PF, it means that we double the > combinations so we double the issues. >=20 > The following should be used instead: assuming you want to use DPDK PF fo= r > dataplane feature, an alternative is, > - 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.html > - have no (or few IOs) to the PF's queue > - assign the traffic to all VF_forPFtraffic's queues of the hyperviso= r, > - run DPDK into the hypervisor's VF_forPFtraffic >=20 > Thank you, > Vincent