> -----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 Let's not block this feature based on Linux kernel upstream reasons.
