From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Ryzhov Subject: Re: KNI discussion in userspace event Date: Fri, 28 Oct 2016 22:23:01 +0300 Message-ID: References: <8c7f9d25-b042-6b7e-b197-7873ea7425ef@intel.com> <31440590.xYOza9ndpd@xps13> <9236278.Tlj3KysXEu@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "Yigit, Ferruh" To: Thomas Monjalon Return-path: Received: from mail-vk0-f68.google.com (mail-vk0-f68.google.com [209.85.213.68]) by dpdk.org (Postfix) with ESMTP id 47D4A58C5 for ; Fri, 28 Oct 2016 21:23:02 +0200 (CEST) Received: by mail-vk0-f68.google.com with SMTP id 130so3042178vkg.2 for ; Fri, 28 Oct 2016 12:23:02 -0700 (PDT) In-Reply-To: <9236278.Tlj3KysXEu@xps13> 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" On Fri, Oct 28, 2016 at 9:40 PM, Thomas Monjalon wrote: > 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 Monjalo= n > > > > > 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" t= o > work, > > > > etc. I view having a kernel proxy module as the best path here as i= t > is > > > > tool agnostic on the userspace side, rather than trying to make eve= ry > > > > 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. > My main point is that if we want to control DPDK ports from Linux, it should be done with standard utilities. Every standard utility like iproute just uses existing Linux kernel interfaces and kernel in its turn uses net_device_ops to control the device= . For example, you want to set MTU of the network device. Regardless of the utility you use to do that (even if you write your own), there are two options =E2=80=93 ioctl or netlink. And regardless of the method you choose, Linux kernel will then call "ndo_change_mtu".