From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: KNI discussion in userspace event Date: Fri, 28 Oct 2016 20:40:50 +0200 Message-ID: <9236278.Tlj3KysXEu@xps13> References: <8c7f9d25-b042-6b7e-b197-7873ea7425ef@intel.com> <31440590.xYOza9ndpd@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, "Yigit, Ferruh" To: Igor Ryzhov Return-path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id C97345686 for ; Fri, 28 Oct 2016 20:40:51 +0200 (CEST) Received: by mail-wm0-f43.google.com with SMTP id p190so29605068wmp.1 for ; Fri, 28 Oct 2016 11:40:51 -0700 (PDT) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2016-10-28 20:29, Igor Ryzhov: > On Fri, Oct 28, 2016 Thomas Monjalon wrote: > > 2016-10-28 15:51, Richardson, Bruce: > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > > > > 2016-10-28 15:31, Ferruh Yigit: > > > > > * Remove ethtool support ? > > > > > > > > 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 first. > > > > > > > > > > > > Still there is some interest, will keep it. But not able to extend it > > > > > to other drivers with current design. > > > > > > > > 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 view having a kernel proxy module as the best path here as it is > > > tool agnostic on the userspace side, rather than trying to make every > > > tool for working with kernel netdevs also have support for dpdk ports. > > > > Yes that's the ultimately best solution. > > But: > > - we need some cooperation of the kernel team > > - ethtool manages a device (what DPDK provides) whereas iproute and others > > manage a TCP/IP stack so is out of control of DPDK. > > That's not true. > iproute can control a lot of things like MAC address, promiscuous, MTU, > etc. that cannot be controlled with ethtool. > Just compare net_device_ops and ethtool_ops to see the difference. Yes you're right. iproute was not a good example :) > And the question is not only about tools, it is also about how Linux kernel > works with network devices. > And it uses net_device_ops, not ethtool_ops. What do you mean exactly? I feel you have something in mind.