From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wiles, Keith" Subject: Re: [RFC] Kernel Control Path (KCP) Date: Tue, 13 Jun 2017 18:18:15 +0000 Message-ID: References: <20170526165228.96919-1-ferruh.yigit@intel.com> <3497879.P1UMQ6Rz4g@xps> <3EB4FA525960D640B5BDFFD6A3D891267BA69B98@IRSMSX108.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Jay Rolette , "Yigit, Ferruh" , Thomas Monjalon , DPDK To: "Dumitrescu, Cristian" Return-path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 59E5D7CAA for ; Tue, 13 Jun 2017 20:18:18 +0200 (CEST) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891267BA69B98@IRSMSX108.ger.corp.intel.com> Content-Language: en-US Content-ID: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > On Jun 13, 2017, at 1:04 PM, Dumitrescu, Cristian wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jay Rolette >> Sent: Tuesday, June 13, 2017 7:00 PM >> To: Yigit, Ferruh >> Cc: Thomas Monjalon ; DPDK >> Subject: Re: [dpdk-dev] [RFC] Kernel Control Path (KCP) >>=20 >> On Tue, Jun 13, 2017 at 12:21 PM, Ferruh Yigit >> wrote: >>=20 >>> On 5/30/2017 11:55 AM, Thomas Monjalon wrote: >>>> 26/05/2017 18:52, Ferruh Yigit: >>>>> We are looking for re-sending [1] the Kernel Control Path (KCP) >>>>> with some updates [2]. >>>>>=20 >>>>> Mainly this is an usability improvement for DPDK. >>>>>=20 >>>>> And a quick reminder about what KCP is: >>>>>=20 >>>>> "KCP is Linux virtual network interface that can control DPDK ports". >>>>>=20 >>>>> So DPDK interfaces, somehow will be visible and it will be possible t= o >>>>> use common Linux tools on DPDK interfaces. >>>>=20 >>>> Reminder: the Mellanox PMDs live with their upstream kernel modules, >>>> allowing such features. >>>>=20 >>>> The best model would be to have control path in kernel for every PMDs. >>>=20 >>> That is the intention with this feature. >>>=20 >>>>=20 >>>> Anyway, do you think KCP (or NCI) could be upstreamed in any way? >>>=20 >>> Unfortunately I believe the answer is same, it may not be possible to >>> upsteam this kernel module. Should this fact block the feature? >>>=20 >>=20 >> Upstream is better, but KCP is a nice quality-of-life feature that I'd l= ike >> to see go in regardless. Anything that helps make DPDK less "foreign" to >> normal port configuration and status tools is goodness. >>=20 >> Jay >=20 > +1 +1 >=20 > Let's not block this feature based on Linux kernel upstream reasons. Regards, Keith