From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: [RFC] Kernel Control Path (KCP) Date: Fri, 16 Jun 2017 16:27:47 +0100 Message-ID: <7879b121-fca9-995a-0087-12c840fbc47e@intel.com> References: <20170526165228.96919-1-ferruh.yigit@intel.com> <3497879.P1UMQ6Rz4g@xps> <3EB4FA525960D640B5BDFFD6A3D891267BA69B98@IRSMSX108.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: "Dumitrescu, Cristian" , Jay Rolette , Thomas Monjalon , DPDK To: Alex Rosenbaum , "Wiles, Keith" 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) In-Reply-To: Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 >