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: Sun, 28 May 2017 16:55:11 +0000
Message-ID: <1A6BF4F7-AD63-4888-99B1-796B31C274DB@intel.com>
References: <20170526165228.96919-1-ferruh.yigit@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: DPDK <dev@dpdk.org>, "Walker, Benjamin" <benjamin.walker@intel.com>
To: "Yigit, Ferruh" <ferruh.yigit@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120])
 by dpdk.org (Postfix) with ESMTP id E878C28EE
 for <dev@dpdk.org>; Sun, 28 May 2017 18:55:13 +0200 (CEST)
In-Reply-To: <20170526165228.96919-1-ferruh.yigit@intel.com>
Content-Language: en-US
Content-ID: <5C952BC8386C4D409BDEDB366FA2C6EB@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 May 26, 2017, at 11:52 AM, Ferruh Yigit <ferruh.yigit@intel.com> wrote=
:
>=20
> 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
> This work can be done in multiple steps:
>=20
> - At first step virtual interfaces can be read-only, and can be used
>  to get stats / information from DPDK ports.
>=20
> - Second step can be controlling the DPDK interfaces in a common way
>  like Linux interfaces.
>=20
> It is good to remind that KCP is only for control path, and no data
> traffic will be available on those interfaces, meaning not able to use
> tcpdump or similar tools on those interfaces.
>=20
> I would like to hear about comments, requirements and objection about
> the idea?
>=20
> Also the name "Kernel Control Path" can be too broad, I am open to a
> name change, any comments on naming is welcome.

Using kernel in the name is not very useful, but netlink is the real part t=
hat makes sense.

How about one of these:
- DNI =3D DPDK Netlink Interface
- DNC =3D DPDK Netlink Control
- NCI =3D Netlink Control Interface

Being able to control DPDK interfaces via Netlink is one of the customer ne=
eds I have heard of late.

>=20
>=20
> [1]
> http://dpdk.org/ml/archives/dev/2016-March/035139.html
>=20
> [2]
> Updates planned to the latest version sent:
> - Create control interfaces without requiring an API call from user
>  application, this will let DPDK applications have this support
>  without any modification.
> - Default enabled interfaces will be read-only.
> - Possible rename.
>=20
>=20
> Thanks,
> ferruh
>=20
>=20
> Ferruh Yigit (4):
>  ethtool: move from sample folder to lib folder
>  kcp: add kernel control path kernel module
>  rte_ctrl_if: add control interface library
>  ethdev: add control interface support
>=20
> --=20
> 2.9.3
>=20

Regards,
Keith