[dpdk-dev] [RFC] Kernel Control Path (KCP)

[Dumitrescu, Cristian]

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jay Rolette
> Sent: Tuesday, June 13, 2017 7:00 PM
> To: Yigit, Ferruh <ferruh.yigit at intel.com>
> Cc: Thomas Monjalon <thomas at monjalon.net>; DPDK <dev at dpdk.org>
> Subject: Re: [dpdk-dev] [RFC] Kernel Control Path (KCP)
> 
> On Tue, Jun 13, 2017 at 12:21 PM, Ferruh Yigit <ferruh.yigit at 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.