From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Wiles, Keith" <keith.wiles@intel.com>
Subject: Re: [RFC] Kernel Control Path (KCP)
Date: Tue, 13 Jun 2017 18:17:57 +0000
Message-ID: <C7F78190-E36C-4521-9B5F-DB6DB85C588E@intel.com>
References: <20170526165228.96919-1-ferruh.yigit@intel.com>
 <3497879.P1UMQ6Rz4g@xps> <d97a5127-3585-3f1d-62b6-d3460400621c@intel.com>
 <CADNuJVo0hN2YPfTHjHL36bZkZb1S+Kz1noVNfXUqAq4F3BHDwQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "Yigit, Ferruh" <ferruh.yigit@intel.com>, Thomas Monjalon
 <thomas@monjalon.net>, DPDK <dev@dpdk.org>
To: Jay Rolette <rolette@infinite.io>
Return-path: <dev-bounces@dpdk.org>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by dpdk.org (Postfix) with ESMTP id 97B8658F6
 for <dev@dpdk.org>; Tue, 13 Jun 2017 20:18:03 +0200 (CEST)
In-Reply-To: <CADNuJVo0hN2YPfTHjHL36bZkZb1S+Kz1noVNfXUqAq4F3BHDwQ@mail.gmail.com>
Content-Language: en-US
Content-ID: <8A2C38DC6E3BEB47953F0460CCDEC2A8@intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>


> On Jun 13, 2017, at 1:00 PM, Jay Rolette <rolette@infinite.io> wrote:
>=20
> On Tue, Jun 13, 2017 at 12:21 PM, Ferruh Yigit <ferruh.yigit@intel.com>
> 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 to
>>>> 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 li=
ke
> to see go in regardless. Anything that helps make DPDK less "foreign" to
> normal port configuration and status tools is goodness.

+1

>=20
> Jay

Regards,
Keith