> On Jun 13, 2017, at 1:04 PM, Dumitrescu, Cristian > <cristian.dumitre...@intel.com> wrote: > > > >> -----Original Message----- >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jay Rolette >> Sent: Tuesday, June 13, 2017 7:00 PM >> To: Yigit, Ferruh <ferruh.yi...@intel.com> >> Cc: Thomas Monjalon <tho...@monjalon.net>; DPDK <dev@dpdk.org> >> Subject: Re: [dpdk-dev] [RFC] Kernel Control Path (KCP) >> >> On Tue, Jun 13, 2017 at 12:21 PM, Ferruh Yigit <ferruh.yi...@intel.com> >> wrote: >> >>> 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]. >>>>> >>>>> Mainly this is an usability improvement for DPDK. >>>>> >>>>> And a quick reminder about what KCP is: >>>>> >>>>> "KCP is Linux virtual network interface that can control DPDK ports". >>>>> >>>>> So DPDK interfaces, somehow will be visible and it will be possible to >>>>> use common Linux tools on DPDK interfaces. >>>> >>>> Reminder: the Mellanox PMDs live with their upstream kernel modules, >>>> allowing such features. >>>> >>>> The best model would be to have control path in kernel for every PMDs. >>> >>> That is the intention with this feature. >>> >>>> >>>> Anyway, do you think KCP (or NCI) could be upstreamed in any way? >>> >>> Unfortunately I believe the answer is same, it may not be possible to >>> upsteam this kernel module. Should this fact block the feature? >>> >> >> Upstream is better, but KCP is a nice quality-of-life feature that I'd like >> to see go in regardless. Anything that helps make DPDK less "foreign" to >> normal port configuration and status tools is goodness. >> >> Jay > > +1
+1 > > Let's not block this feature based on Linux kernel upstream reasons. Regards, Keith
