From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id E878C28EE for ; Sun, 28 May 2017 18:55:13 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 May 2017 09:55:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,410,1491289200"; d="scan'208";a="106425619" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga005.jf.intel.com with ESMTP; 28 May 2017 09:55:12 -0700 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 28 May 2017 09:55:12 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.162]) by fmsmsx156.amr.corp.intel.com ([169.254.13.192]) with mapi id 14.03.0319.002; Sun, 28 May 2017 09:55:12 -0700 From: "Wiles, Keith" To: "Yigit, Ferruh" CC: DPDK , "Walker, Benjamin" Thread-Topic: [dpdk-dev] [RFC] Kernel Control Path (KCP) Thread-Index: AQHS1kCLQoSPQtJRbEmdYPJ7t9WAKKIKbywA 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> In-Reply-To: <20170526165228.96919-1-ferruh.yigit@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.13.215] Content-Type: text/plain; charset="us-ascii" Content-ID: <5C952BC8386C4D409BDEDB366FA2C6EB@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] Kernel Control Path (KCP) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 16:55:14 -0000 > On May 26, 2017, at 11:52 AM, Ferruh Yigit 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