From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 4AE69685C for ; Mon, 29 Feb 2016 11:58:45 +0100 (CET) Received: by mail-wm0-f41.google.com with SMTP id l68so31201193wml.0 for ; Mon, 29 Feb 2016 02:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scylladb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=mFd11HuPbrXLtVj55t/mLt0AOxnyZ7RfOi1kzHKQwKQ=; b=1+7YultPyyCZHqRVGPO4ZuX3C3i/KhMc54YSDuW/kTjYKlnL6E+TfT0bjg5L337y3e mDG3/+Morg1fhoVarE5GD7Dq2vkWZmGUGzUPSfqJ8kkGynzpXNFdQmu3Ny3a5FnAF18h dbcW1XJQJcQfsnB6vEHaJE1dnQoOoH7vd2pzdGJXv2fLd6CWZpTDcxZcgwITxaikTurn /AqggJ/7mOr0SksMMQm+VxR8RoK4WvA6X4qTPw9ll4tyeQ/6D80nGOIAV750zO8phuZa 8fjnOr0AuRCykOALHc0cTJFibcv39e/izBmZAg7FC2XY2AL5Cup9nDxbnuid4J+E8yE3 LifA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=mFd11HuPbrXLtVj55t/mLt0AOxnyZ7RfOi1kzHKQwKQ=; b=URhlbH4goe5M86dfir+OhGuMbqTCumqcPa42nV8IDAoCFhQJqWedba/+t+kDcqyXN8 kA4Xh0TdvE2iI04zFc4VldCXVykCbpZiisKHRv7kBM/9aSXuje9fKhe3qy9+w76wkVcE PGHl6zAIi+tiLuvTmqiUKv14rTBxjpwTsz1ppHXRJEa28pCKmIgZ3wvynfYJudU95laH +09U+i6Ce3QzSnBh4Genih4eqndwin+4scaxPwniqkVhmDpljjpuOwd2PQ82m/pAE+Oz JeOQrIZG2G/8ysSndhhEzwCo/iv0O+GHQYLwYU3J/nR4GDxpBsqvRg5LPBrSLFXgPhGA CyAA== X-Gm-Message-State: AD7BkJInw73iVrd3DlqZO0bTszbTgODsU7c/pC9V+JS8Ul28FgcHCX1H5WwjFgXFphz4GQ== X-Received: by 10.194.19.5 with SMTP id a5mr14470902wje.46.1456743525086; Mon, 29 Feb 2016 02:58:45 -0800 (PST) Received: from avi.cloudius-systems.com ([37.142.229.250]) by smtp.googlemail.com with ESMTPSA id k4sm15786337wmc.12.2016.02.29.02.58.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Feb 2016 02:58:44 -0800 (PST) To: Ferruh Yigit , dev@dpdk.org References: <1453911849-16562-1-git-send-email-ferruh.yigit@intel.com> <1453911849-16562-2-git-send-email-ferruh.yigit@intel.com> <56D3137D.1090106@scylladb.com> <56D3559F.2000100@intel.com> <56D412C2.5050806@scylladb.com> <56D420E5.9010802@intel.com> From: Avi Kivity Message-ID: <56D42462.3020905@scylladb.com> Date: Mon, 29 Feb 2016 12:58:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D420E5.9010802@intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 10:58:45 -0000 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. > 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). > 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? 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. > >>> 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. >>> >>>