From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by dpdk.org (Postfix) with ESMTP id 42FCE56A8 for ; Fri, 28 Oct 2016 19:29:05 +0200 (CEST) Received: by mail-vk0-f44.google.com with SMTP id x186so1250014vkd.1 for ; Fri, 28 Oct 2016 10:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nfware-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a/a+U0g7aQz+KRM9ohgio8UEhP6M8fasd2RysM/weNk=; b=u1oyGSt/KdhjFmdpc+JBq+qMD1hgZt/5K/gbzz2XdMVC32Yl9ryaPe1UU4Z+VcjCAi fuZ/cYqsWQMPUr6uLcD5Ptp3bWLX94R1VCzkqyPRNexrOpc/klty8rBhB4F3shfLFXxl f85nEG3IT+XcVqk9sQvwoqdJ7TnD5AWFsVNfdE2lc4JnrImOMxyLlo2nhXS93HGuV2yX xlyOewkquV5SaVL5wUyzJCeLbfy7x0sgnkKJV1KBjEc7Nesjun4ZJyhoB/3++zHnqKRM pzWKoPvHam+5ii84GVovWWwXD+iarB8WzOWFM8kc7ze6ts4WrGco4m66p6xbpmOEfQsv UEHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a/a+U0g7aQz+KRM9ohgio8UEhP6M8fasd2RysM/weNk=; b=O5Nse1Irl38BmngUr+IUPLpxHWmSzsDPGDjr1EwaDQKG2ZGKLBqYL53wR+/tWB6wU/ RzfBZYYEItWXfBocNv4pZcpMRawqeRDhKosiRUdz3pTfXicoftrLyCjpiyP1gIU6UErM DzCuvxF3sQEjU6IOE2kKJvk2D7ir019ikTFlhsunH7BlrRrAg5kz5PgNpOnN2VdBYgcx sStdI9Rkrya/hkimd09c7oWPkkPY9YFU8xXMX8Gn55pNFTH+5vgz1cd2QNG/jeWphg4t wdNYkYG7vZcVY1volgDHAcRQO4VaDb40qT7cV7kuE4q59mBbbQmIm8Et+WP47ivj7LB7 WDjg== X-Gm-Message-State: ABUngveRdUj53s8JRmYejsJnR1y91S9htigruPUvQJEeN7Ga8jTIt/bri7cw+zylsG+SkTKcfUD7sUgtj41mXg== X-Received: by 10.31.88.197 with SMTP id m188mr13693111vkb.156.1477675744590; Fri, 28 Oct 2016 10:29:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.168 with HTTP; Fri, 28 Oct 2016 10:29:04 -0700 (PDT) X-Originating-IP: [95.182.74.2] In-Reply-To: <31440590.xYOza9ndpd@xps13> References: <8c7f9d25-b042-6b7e-b197-7873ea7425ef@intel.com> <16238883.tkNBRrfWjK@xps13> <59AF69C657FD0841A61C55336867B5B035B31F7F@IRSMSX103.ger.corp.intel.com> <31440590.xYOza9ndpd@xps13> From: Igor Ryzhov Date: Fri, 28 Oct 2016 20:29:04 +0300 Message-ID: To: Thomas Monjalon Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 17:29:05 -0000 On Fri, Oct 28, 2016 at 7:13 PM, 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: > > > > * 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. > > > > > > 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 > performance, there will be demand for KNI to stick around. > > The "control path" is the ethtool part, to get stats and do operations > on the NIC using command-line tools. > > > > > > > > > * 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. 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. > > > > 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 wait! Also, it doesn't work for virtio ports, for pcap ports, or any > other ports 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. > > Yes, very good point. > > > > > *KNI PMD > > > > Patch is in the mail list, missing comments. If it gets some > > > > interest/comments/acks it may go in to next release. > > > > > > I'm not against KNI PMD but it looks strange to add more support to an > old > > > dying approach. > > > > I think the main idea here is to clean up the API - at least for the > data path. There is no reason why we need special KNI RX/TX functions, when > ethdev RX/TX functions could do the job. However, at a higher level, the > more basic 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. > > Yes I agree to unifiy (and reduce) API. > Why this PMD is not more commented? > KNI users should be interested to review it. > Please dear community, we need more reviews! >