From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id A865B3DC for ; Fri, 16 Jun 2017 17:54:09 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2017 08:54:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,347,1493708400"; d="scan'208";a="1161341934" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.91]) ([10.237.220.91]) by fmsmga001.fm.intel.com with ESMTP; 16 Jun 2017 08:54:05 -0700 To: "Wiles, Keith" Cc: DPDK , "Walker, Benjamin" References: <20170526165228.96919-1-ferruh.yigit@intel.com> <1A6BF4F7-AD63-4888-99B1-796B31C274DB@intel.com> From: Ferruh Yigit Message-ID: <2a912709-969c-bd23-dbca-c495560f97d9@intel.com> Date: Fri, 16 Jun 2017 16:54:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <1A6BF4F7-AD63-4888-99B1-796B31C274DB@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Fri, 16 Jun 2017 15:54:10 -0000 On 5/28/2017 5:55 PM, Wiles, Keith wrote: > >> On May 26, 2017, at 11:52 AM, Ferruh Yigit wrote: >> >> 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. >> >> This work can be done in multiple steps: >> >> - At first step virtual interfaces can be read-only, and can be used >> to get stats / information from DPDK ports. >> >> - Second step can be controlling the DPDK interfaces in a common way >> like Linux interfaces. >> >> 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. >> >> I would like to hear about comments, requirements and objection about >> the idea? >> >> 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 that makes sense. > > How about one of these: > - DNI = DPDK Netlink Interface > - DNC = DPDK Netlink Control > - NCI = Netlink Control Interface > > Being able to control DPDK interfaces via Netlink is one of the customer needs I have heard of late. My concern is this name my create a miss understanding that DPDK is providing a netlink interface for other applications that they can use to control DPDK application / interfaces. Here although netlink sockets used to communicate between kernel and userspace, DPDK application connects to the netlink socket provided by kernel module, and DPDK interfaces controlled using virtual Linux network interfaces, independent from what kind of communication method used between kernel and userspace. > >> >> >> [1] >> http://dpdk.org/ml/archives/dev/2016-March/035139.html >> >> [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. >> >> >> Thanks, >> ferruh >> >> >> 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 >> >> -- >> 2.9.3 >> > > Regards, > Keith >