From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas.monjalon@6wind.com> Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id C3ED92B97 for <dev@dpdk.org>; Mon, 29 Feb 2016 12:07:44 +0100 (CET) Received: by mail-wm0-f43.google.com with SMTP id n186so43589681wmn.1 for <dev@dpdk.org>; Mon, 29 Feb 2016 03:07:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=YlPV3j9j/YEmcIeGy4jtydLHAVUjMDGD6aBTGN/MABQ=; b=unkcUbpOmnlzbYZa/xo90Wb/T3gw0q/ZnrZ8RBMeTNQ6T2naGluYWSuV2yJIrhq0jo mNb713EtoenxdZhiwM8hF4SWuXTMoRf2hIqXNIVGgA81qFLd9dnQVYDMKqen3NbBFYuQ 2gDna5C/v39MKw+FNdTqNVEsQ8/UarV5WPY80RiKm3OnTOzJhJSlhiZdxkbf+OZQrdwS 37ec+U/nwOXHYkiyfZNPppxEYqNjLt2f6od4V+5mLo6o7yBZfW0yotfeKbZTrAMxtaCF grfmKGksAXIm/ZjKNCnY3DB1GhGz7uIHRpmocbE0HCqC5QGloDMYjY0UvPoFQw7uvJd4 FTVA== 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:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding; bh=YlPV3j9j/YEmcIeGy4jtydLHAVUjMDGD6aBTGN/MABQ=; b=mRzpau1w+C/uuxDjtTmxRgBOH1JytU4BV9m++lOpipbHCT+MFc348/bBWmB3f1ancG xTstKFDjzmsE6GdS3pwVtO/9ZI/abTz9swlD0oKC6W2ioHK2JMqZvBQ62fDDQ/c/vXDl ee6qWIP8cKWdX3+hrp5QnZA+bbmbAyHRphvKxTFdzIGasRmwTZmjt3Vq+5s28OgQNfcH dOzdWtqL2poZWZA0SPjcrnjVZjGzWBHpDNfQLVDwYnEw+PnUN0Z2Qzo3Qb2FHPKjTZYM KX7Kb2AzvKkkL4MOhZxm0eSueCYswwFf818Qc3428DdujbPHkCDTvgVQYO5aIindjsCp elpw== X-Gm-Message-State: AD7BkJKfZw6KhN8kGJOSsf4d+Ra2WpY5+Pkml/Q9I+j/NZLKNfj2FOXtFK/IdhdgGdbm1qBM X-Received: by 10.28.51.74 with SMTP id z71mr10477471wmz.15.1456744064618; Mon, 29 Feb 2016 03:07:44 -0800 (PST) Received: from xps13.localnet (171.36.101.84.rev.sfr.net. [84.101.36.171]) by smtp.gmail.com with ESMTPSA id av3sm25457530wjc.44.2016.02.29.03.07.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Feb 2016 03:07:43 -0800 (PST) From: Thomas Monjalon <thomas.monjalon@6wind.com> To: Ferruh Yigit <ferruh.yigit@intel.com> Date: Mon, 29 Feb 2016 12:06:09 +0100 Message-ID: <1945473.Tiatd2m80T@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <56D42462.3020905@scylladb.com> References: <1453911849-16562-1-git-send-email-ferruh.yigit@intel.com> <56D420E5.9010802@intel.com> <56D42462.3020905@scylladb.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org, Avi Kivity <avi@scylladb.com> Subject: Re: [dpdk-dev] [PATCH 1/3] kcp: add kernel control path kernel module X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 29 Feb 2016 11:07:44 -0000 Hi, I totally agree with Avi's comments. This topic is really important for the future of DPDK. So I think we must give some time to continue the discussion and have netdev involved in the choices done. As a consequence, these series should not be merged in the release 16.04. Thanks for continuing the work. 2016-02-29 12:58, Avi Kivity: > On 02/29/2016 12:43 PM, Ferruh Yigit wrote: > > On 2/29/2016 9:43 AM, Avi Kivity wrote: > >> On 02/28/2016 10:16 PM, Ferruh Yigit wrote: > >>> On 2/28/2016 3:34 PM, Avi Kivity wrote: > >>>> On 01/27/2016 06:24 PM, Ferruh Yigit wrote: > >>>>> This kernel module is based on KNI module, but this one is stripped > >>>>> version of it and only for control messages, no data transfer > >>>>> functionality provided. > >>>>> > >>>>> This Linux kernel module helps userspace application create virtual > >>>>> interfaces and when a control command issued into that virtual > >>>>> interface, module pushes the command to the userspace and gets the > >>>>> response back for the caller application. > >>>>> > >>>>> The Linux tools like ethtool/ifconfig/ip can be used on virtual > >>>>> interfaces but not ones for related data, like tcpdump. > >>>>> > >>>>> In long term this patch intends to replace the KNI and KNI will be > >>>>> depreciated. > >>>> Instead of adding yet another out-of-tree kernel module, why not extend > >>>> the existing in-tree tap driver? This will make everyone's life easier. > >>>> > >>>> Since tap also supports data transfer, an application can also forward > >>>> packets not intended to it to the kernel, and forward packets from the > >>>> kernel through the device. > >>>> > >>> Hi Avi, > >>> > >>> KDP (Kernel Data Path) does what you have described, it is implemented > >>> as PMD and it benefits from tap driver to data transfer through the > >>> kernel. It also support custom kernel module for better performance. > >>> > >>> For KCP (Kernel Control Path), network driver forwards control commands > >>> to the userspace driver, I doubt this is something wanted for tun/tap > >>> driver, so extending tun/tap driver like this can be hard to upstream. > >> Have you tried asking? Maybe if you explain it they will be open to the > >> extension. > >> > > Not communicated but tun/tap already doing something different. > > For KCP, created interface is map of the DPDK port. All data interface > > shows coming from DPDK port. For example if you get stats information > > with ifconfig, the values you observe are DPDK port statistics -not > > statistics of data between userspace and kernelspace, statistics of data > > forwarded between DPDK ports. If you down the interface, DPDK port > > stopped, etc... > > > > If you extend the tun/tap, it won't be map of the DPDK port, and if you > > get statistics information from that interface, what do you expect to > > see, the data transferred between kernel and userspace, or underlying > > DPDK port forwarding statistics? > > Good point. But you really have to involve netdev on this, or you'll > live out-of-tree forever. +1 > > Extending tun/tap in a way we want, forwarding all control commands to > > userspace, will break the current tun/tap, this doesn't looks like a > > valid option to me. > > It's possible to enhance it while preserving backwards compatibility, by > enabling a feature flag (statistics from userspace). +1 > > For data path, using tun/tap is OK and we are already doing it, for the > > control path I believe we need a new driver. > > > >> Certainly it will be better to have KCP and KDP use the same kernel > >> interface name; so we'll need to either add data path support to kcp > >> (causing duplication with tap), or add control path support to tap. I > >> think the latter is preferable. > >> > > Why it is better to have same interface? Anyone who is not interested > > with kernel data path may want to control DPDK ports using common tools, > > or want to get some basic information and stats using ethtool or > > ifconfig. Why we need to bind two different functionality together? > > Having two interfaces will be confusing for the user. If I wish to > firewall data packets coming from the dpdk port, do I set firewall rules > on dpdk0 or tap0? +1 > I don't think it matters whether you extend tap, or add a data path to > kcp, but if you want to upstream it, it needs to be blessed by netdev. +1 > >>> We are investigating about adding a native support to Linux kernel for > >>> KCP, but there is no task started for this right now, any support is > >>> welcome.