From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 1E4CD2BF2 for ; Sat, 29 Oct 2016 01:09:48 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id 140so96554437wmv.0 for ; Fri, 28 Oct 2016 16:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:date:message-id:in-reply-to:references:user-agent :subject:mime-version:content-transfer-encoding; bh=2nvJQkox6UKUlI1l/z1St1a8MCwM327zkOGXxSM4oRM=; b=Fw1dVmng7BPr/x3LJT8ItawlX+pmTJRYQy15j2W30hbnqCWRyRWfyuv3HJD5buDS/7 agOrcEtc+QJ458U4eI22sh04n86x2B3mcKVC7mP6kXrwjkf8MNUs5TBahAZwBoqI9GRT Q93M6AohXgspvEAGBWXbjiLxeV3VLMKHUAPqqNX/joKiiCGTRLiyRnm0hVAmv93DieYY cYjU3chTN7CXFZPQlTeyi0sFJl1HpuZTOxw6+9WjQduj1Xtp/L3BCvGF/dB/9mhatkv8 B+fr05j8r/kkASA/3Yugmmn2d90ykIfljGpFpg6J8KG0ebNNoEJIXzw4hOiplk+VbjiV 7trA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:date:message-id:in-reply-to :references:user-agent:subject:mime-version :content-transfer-encoding; bh=2nvJQkox6UKUlI1l/z1St1a8MCwM327zkOGXxSM4oRM=; b=M50MBMCpu06+VCspGBnmOWPAwkhtFpB4KcBijiSta940QS1HT53VQMyU4CdXYDsIC/ QHz0WOpG1g2hvdwWZCRxPnb55W2RipbjWh7pPKVqQmghE+kC68R6NvOnr/ZrsExk6Orf 0Aqtr3J2yP53PTyAB70dpD116lvetE/fOsq9uvr01DLt8DHA1r7PEq8foYikwdu9/lEP OIFmuJVXUNO9a0x1P+h6oGD2mIPhg57jhfMQHV+P9y2Shpnmh7txec/5wSZ4U8pCsZWU 0qTY9NQL9GVurVDDWSPiwGiD3M2c1FgTlTbNC0evNxqBhj9GmZRwQmtbE0W9gksQ0huD QTAA== X-Gm-Message-State: ABUngvchbYatxMrJQanycvsd5nDpNLrlFHpSKDTaNuQEH9GKuBznmCs8qxH0vX5qsyANwPIk X-Received: by 10.28.227.4 with SMTP id a4mr762563wmh.84.1477696187836; Fri, 28 Oct 2016 16:09:47 -0700 (PDT) Received: from [10.90.105.33] ([80.214.66.187]) by smtp.gmail.com with ESMTPSA id l130sm11134612wmb.18.2016.10.28.16.09.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Oct 2016 16:09:47 -0700 (PDT) From: Vincent Jardin To: Igor Ryzhov , Thomas Monjalon Date: Sat, 29 Oct 2016 01:09:45 +0200 Message-ID: <1580d8e62a8.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> In-Reply-To: References: <8c7f9d25-b042-6b7e-b197-7873ea7425ef@intel.com> <31440590.xYOza9ndpd@xps13> <9236278.Tlj3KysXEu@xps13> User-Agent: AquaMail/1.6.2.9 (build: 27000209) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: dev@dpdk.org, "Yigit, Ferruh" 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 23:09:48 -0000 Le 28 octobre 2016 9:23:06 PM Igor Ryzhov a écrit : > 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 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. >> > > 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 – ioctl or netlink. > And regardless of the method you choose, Linux kernel will then call > "ndo_change_mtu". DPDK runs on non Linux too (FreeBSD, maybe Windows some days). So we should avoid creating such dependencies. I do like the kind of bifurcated models (à la RDMA like mlx PMDs) so port management is still done using plain OS drivers of the kernel. We should rather push toward proper bifurcated drivers: - so we decrease maintenance and avoid code duplication - we benefit of kernel's interface management I am not expert of RDMA on FreeBSD and Windows but it seems available.