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

[Wiles, Keith]

> On Jun 13, 2017, at 1:04 PM, Dumitrescu, Cristian <cristian.dumitrescu at intel.com> wrote:
> 
> 
> 
>> -----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

+1

> 
> Let's not block this feature based on Linux kernel upstream reasons.

Regards,
Keith