From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 7376847CE for ; Tue, 26 Jul 2016 15:19:17 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 26 Jul 2016 06:18:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,424,1464678000"; d="scan'208";a="853747795" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.125]) ([10.237.220.125]) by orsmga003.jf.intel.com with ESMTP; 26 Jul 2016 06:18:06 -0700 To: Andriy Berestovskyy , Jay Rolette References: <1469030873-5966-1-git-send-email-thomas.monjalon@6wind.com> <5790EB36.3000604@intel.com> <7298712.p7zDOZdSxl@xps13> Cc: Thomas Monjalon , DPDK From: Ferruh Yigit Message-ID: <5797630C.3040701@intel.com> Date: Tue, 26 Jul 2016 14:18:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] doc: announce KNI ethtool removal 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: Tue, 26 Jul 2016 13:19:18 -0000 On 7/22/2016 6:20 PM, Andriy Berestovskyy wrote: > Hi folks, > Just to clarify. Thomas is talking about removing just the KNI ethtool > (i.e. lib/librte_eal/linuxapp/kni/ethtool/*). The major functionality > of those 45K lines of code is to get the same MAC address on the KNI > interface and the underlying igb/ixgbe NIC. Yes what we talk here is "KNI ethtool" but its major functionality is NOT getting MAC address from device. Basically it lets issuing ethtool commands to the device via virtual interface. Like for a device that controlled by DPDK, it is possible to read device registers, or read/write eeprom of the device via this feature. So as name suggests, it enables ethtool support for device. > > At the moment the rest of the DPDK eth devices work fine without the > KNI ethtool. Of course, this is an optional feature, drivers doesn't support this feature will work fine. So keeping this feature, doesn't cost any to drivers that doesn't support this feature. > The workaround is very simple: use ifconfig or ip tool to > set the same MAC you have on your NIC. Put it into your network > configuration to make it permanent. > > Examples: > ifconfig vEth0_0 hw ether > or > ip link set vEth0_0 address > or > in /etc/network/interfaces under the "iface vEth0_0" section add the following: > hwaddress > > > Andriy > > On Thu, Jul 21, 2016 at 10:54 PM, Jay Rolette wrote: >> On Thu, Jul 21, 2016 at 3:32 PM, Thomas Monjalon >> wrote: >> >>> 2016-07-21 13:20, Jay Rolette: >>>> On Thu, Jul 21, 2016 at 10:33 AM, Ferruh Yigit >>>> wrote: >>>>> KNI ethtool is functional and maintained, and it may have users! >>>>> >>>>> Why just removing it, specially without providing an alternative? >>>>> Is is good time to discuss KCP again? >>>> >>>> Yes, my product uses it. >>> >>> Your product uses what? KCP? KNI? KNI ethtool? >>> >> >> Sorry, that wasn't very clear. It uses KNI + ifconfig to configure the >> device/interface in Linux. I'm assuming the "ethtool" bits under discussion >> are the same things that make ifconfig work with KNI to the limited extent >> it does. >> >>> Seems like we are back to the same discussion we >>>> had a few months ago about the KNI situation... >>>> >>>> It shouldn't be removed unless there is a replacement, ideally one that >>>> works with the normal Linux tools like every other network device. >>> >>> This ethtool module works only for igb and ixgbe! >>> There is already no replacement for other drivers. >>> Who works on a replacement? >>> >> >> Ferruh submitted KCP previously, but you guys didn't like the fact that it >> was a kernel module. IIRC, one of the gains from that was simplified >> maintenance because you didn't need driver specific support for KNI. >> Assuming he's still willing to beat it into shape, we have something that >> is already most of the way there. >> >> If people are going to continue to block it because it is a kernel module, >> then IMO, it's better to leave the existing support on igx / ixgbe in place >> instead of stepping backwards to zero support for ethtool. >> >>> While the code wasn't ready at the time, it was a definite improvement >>> over what >>>> we have with KNI today. >>> > > >