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 2C2E22BD1 for ; Fri, 28 Oct 2016 17:51:47 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP; 28 Oct 2016 08:51:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,410,1473145200"; d="scan'208";a="25206290" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by orsmga004.jf.intel.com with ESMTP; 28 Oct 2016 08:51:44 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.190]) by IRSMSX108.ger.corp.intel.com ([169.254.11.210]) with mapi id 14.03.0248.002; Fri, 28 Oct 2016 16:51:44 +0100 From: "Richardson, Bruce" To: Thomas Monjalon , "Yigit, Ferruh" Thread-Topic: [dpdk-dev] KNI discussion in userspace event Thread-Index: AQHSMSgPo5DdE0G9/U6IUmIksuw+k6C96JKAgAAZZ1A= Date: Fri, 28 Oct 2016 15:51:43 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B035B31F7F@IRSMSX103.ger.corp.intel.com> References: <8c7f9d25-b042-6b7e-b197-7873ea7425ef@intel.com> <16238883.tkNBRrfWjK@xps13> In-Reply-To: <16238883.tkNBRrfWjK@xps13> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiN2E0OWQ2MGMtYTM1YS00OGUwLTkyNjgtYTg0ZmY4Njk1MDA1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IktlU0tOMjRjNkVaSWFNeFEwaHBkK0x0UkJId0ZoMjEzbXhlZTdhQU1nU2M9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] KNI discussion in userspace event X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 15:51:47 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > Sent: Friday, October 28, 2016 4:13 PM > To: Yigit, Ferruh > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] KNI discussion in userspace event >=20 > 2016-10-28 15:31, Ferruh Yigit: > > * virtio-user + vhost-net > > This can be valid alternative, removes the out of tree kernel module > > need. But missing control path. Proof of concept work will be done. >=20 > That's probably a smart alternative for packet injection. > What do you mean exactly by "missing control path"? We'll have to see how it performs - which is the key gap for data path that= KNI fills. Until we get an alternative with (nearly) equivalent performanc= e, there will be demand for KNI to stick around. The "control path" is the ethtool part, to get stats and do operations on t= he NIC using command-line tools. >=20 > > * Remove ethtool support ? >=20 > That's the other part of KNI. > It works only for e1000/ixgbe. That's a niche. Yes, it's something we need to remove, but again, we need an alternative fi= rst. >=20 > > Still there is some interest, will keep it. But not able to extend it > > to other drivers with current design. >=20 > It should be removed one day. > We must seriously think about a generic alternative. > Either we add DPDK support in ethtool or we create a dpdk-ethtool. > (or at least a library as the one in examples/). I don't view that as a great path forward. Sure, we can do our own ethtool,= but then people will look for ifconfig to work, and "ip" to work, etc. I v= iew having a kernel proxy module as the best path here as it is tool agnost= ic on the userspace side, rather than trying to make every tool for working= with kernel netdevs also have support for dpdk ports. > Or we do nothing and wait to have more hardware like Mellanox supporting = a > kernel bifurcated driver approach. Given the lack of other NICs supporting that, I think it could be quite a w= ait! Also, it doesn't work for virtio ports, for pcap ports, or any other p= orts which don't have physical hardware backing them. No reason you shouldn= 't be able to pull stats from all your dpdk ethdevs, not just the ones with= physical hardware. The same ethdev APIs work for them, so should the same = tools. >=20 > > *KNI PMD > > Patch is in the mail list, missing comments. If it gets some > > interest/comments/acks it may go in to next release. >=20 > I'm not against KNI PMD but it looks strange to add more support to an ol= d > dying approach. I think the main idea here is to clean up the API - at least for the data p= ath. There is no reason why we need special KNI RX/TX functions, when ethde= v RX/TX functions could do the job. However, at a higher level, the more ba= sic requirement is that whatever solution for the data-path to kernel from = dpdk is, it needs to appear as an ethdev, and not as a special library with= different APIs, as KNI is now. /Bruce