From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com [209.85.192.173]) by dpdk.org (Postfix) with ESMTP id 36BF22BD1 for ; Fri, 16 Jun 2017 18:48:42 +0200 (CEST) Received: by mail-pf0-f173.google.com with SMTP id x63so24791334pff.3 for ; Fri, 16 Jun 2017 09:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=JfgptfuSr4tTbGspd9KANo38BbLBPoZ34a2b1tGqlfU=; b=XhPS6+SNaYcJSHkzqJA8oIYfYNgFuS04kdk8Y1lekpn8u7Ez97fSFQnQkxcu7ZaV0J 4JWXVOUqQ97Znrrw7zlwktO4WNVAWaCTz76D9pGGcU6J1huLeOivK4tndkG2MYrUs1At nAFTipVrIs39tayEwfCCZ88/0tlor8lTgt7BCLah4MYXVAENuD/whOuQBjz4mToq483i tkWwY9fKfFGwVYXoLShq2Bb5MOLyTm+rI6iIDKxUxgefWJPmJREWyjQBGaBLZ0P7dw8T Hp7kXeT4hrlWb0Ku8CwMjQ9045YYH834DmaeOeWVgWlTxmsxTksLSJzatxndVQQyXRpl 3RFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=JfgptfuSr4tTbGspd9KANo38BbLBPoZ34a2b1tGqlfU=; b=lR6baUzyVeYYZ29If92Spgj7PPj1wqcGeQFPrTUF2OYu5du2J52lOB621BzMTvYAcA iGUr216XeP64M6M7ihCt/zC3Sy23yzm4vesvTIJV+EsQY/B6jFl1S4k1Lq/aOyzNJvg8 Ch0bGuDXkyoLqA9ZNjsmgcj19L2sIN6dW3os/A0LfjNY/WwnxRXzLa4YdOz2t5yenWaZ /8pmMLxcEtb1BsOiXthlAOWriMz9RwptvxgyoBzr1TB/19GhUn1Y7SCqN3XuerQXYBxM BARdLe65OUSfQ4TdxcglDYE5VtgB4gLhcONGwzG0atX0HE6SwePsi/ZV4FhcejWd6dT4 xp9g== X-Gm-Message-State: AKS2vOwkuR5g9H0gNePwFPSTHtX9rWif2y6yjV1ymiYwxb1BpFtguwX7 vqVaWVycSvrPP4tO X-Received: by 10.101.90.6 with SMTP id y6mr12559775pgs.252.1497631721429; Fri, 16 Jun 2017 09:48:41 -0700 (PDT) Received: from xeon-e3 (76-14-207-240.or.wavecable.com. [76.14.207.240]) by smtp.gmail.com with ESMTPSA id 73sm5986127pfx.93.2017.06.16.09.48.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 16 Jun 2017 09:48:41 -0700 (PDT) Date: Fri, 16 Jun 2017 09:48:33 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: Alex Rosenbaum , "Wiles, Keith" , "Dumitrescu, Cristian" , Jay Rolette , Thomas Monjalon , DPDK Message-ID: <20170616094833.701cfb28@xeon-e3> In-Reply-To: <7879b121-fca9-995a-0087-12c840fbc47e@intel.com> References: <20170526165228.96919-1-ferruh.yigit@intel.com> <3497879.P1UMQ6Rz4g@xps> <3EB4FA525960D640B5BDFFD6A3D891267BA69B98@IRSMSX108.ger.corp.intel.com> <7879b121-fca9-995a-0087-12c840fbc47e@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 16:48:42 -0000 On Fri, 16 Jun 2017 16:27:47 +0100 Ferruh Yigit wrote: > 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 > > > Hopefully KCP can be submitted for upstream kernel, and therefore be supportable over the long term. KNI in its current form is not acceptable upstream for a number of reasons: style, use of ioctl, races with control operations, etc.