From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 1B04E2BB9 for ; Fri, 16 Jun 2017 17:27:50 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2017 08:27:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,347,1493708400"; d="scan'208";a="1161333291" 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:27:48 -0700 To: Alex Rosenbaum , "Wiles, Keith" Cc: "Dumitrescu, Cristian" , Jay Rolette , Thomas Monjalon , DPDK References: <20170526165228.96919-1-ferruh.yigit@intel.com> <3497879.P1UMQ6Rz4g@xps> <3EB4FA525960D640B5BDFFD6A3D891267BA69B98@IRSMSX108.ger.corp.intel.com> From: Ferruh Yigit Message-ID: <7879b121-fca9-995a-0087-12c840fbc47e@intel.com> Date: Fri, 16 Jun 2017 16:27:47 +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: 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:27:51 -0000 Hi Alex, On 6/15/2017 1:07 PM, Alex Rosenbaum wrote: > please excuse me if I missed out of the previous conversation and > asking these questions again... > > Why create a new driver instead of improving the existing KNI driver? For control path, KNI uses Linux kernel driver within KNI kernel module. This method works, but may not be best option, and technically not extendable for some drivers. KNI control path currently supports only two drivers, proposed KCP works for all PMDs by default. Overall, KCP is outcome of the effort of improving KNI control path. Initial proposal was (a year ago I guess) introducing two new modules, one for control path and one for data path, and replace KNI completely. But current target is have KCP to have better control path support. Also, KNI handles both data and control path. But both are different functionalities and not need to be in some module. For example an application may not need exception data path to kernel, but may be interested in controlling DPDK interfaces via common Linux tools. > Can you share a table of the differences between the two driver / > approaches [KNI vs KCP]? KCP differences against KNI: - KCP is only for control path - Linux virtual interfaces created automatically, without DPDK application modification. - To create/destroy interfaces KCP uses rtnl, KNI uses ioctl. So technically it is possible to use "ip" tool to create / destroy interfaces supported by KCP. - KCP kernel module and userspace counterpart communicates via netlink, KNI uses ioctl. - KCP works for all PMDs without update on PMDs. > > Why do you want to remove features like data path that is provided by KNI today? There is not intention to remove exception data path, the focus is to improve KNI. > > thanks, > Alex >