From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <jianfeng.tan@intel.com> Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 8847A20F for <dev@dpdk.org>; Tue, 10 Jan 2017 09:46:04 +0100 (CET) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP; 10 Jan 2017 00:46:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,343,1477983600"; d="scan'208";a="52089615" Received: from shwdeisgchi083.ccr.corp.intel.com (HELO [10.239.67.193]) ([10.239.67.193]) by fmsmga006.fm.intel.com with ESMTP; 10 Jan 2017 00:46:02 -0800 To: Bruce Richardson <bruce.richardson@intel.com> References: <1480689075-66977-1-git-send-email-jianfeng.tan@intel.com> <1483502366-140154-1-git-send-email-jianfeng.tan@intel.com> <20170109140634.GA94516@bricha3-MOBL3.ger.corp.intel.com> Cc: dev@dpdk.org, yuanhan.liu@linux.intel.com, ferruh.yigit@intel.com, cunming.liang@intel.com From: "Tan, Jianfeng" <jianfeng.tan@intel.com> Message-ID: <4ccef511-e368-fda9-1ed1-a66c57f27617@intel.com> Date: Tue, 10 Jan 2017 16:46:02 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170109140634.GA94516@bricha3-MOBL3.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 0/7] virtio_user as an alternative exception path X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <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: Tue, 10 Jan 2017 08:46:06 -0000 On 1/9/2017 10:06 PM, Bruce Richardson wrote: > On Wed, Jan 04, 2017 at 03:59:19AM +0000, Jianfeng Tan wrote: >> v3: >> - Drop the patch to postpone driver ok sending patch, superseded it >> with a bug fix to disable all virtqueues and re-init the device. >> (you might wonder why not just send reset owner msg. Under my test, >> it causes spinlock deadlock problem when killing the program). >> - Avoid compiling error on 32-bit system for pointer convert. >> - Fix a bug in patch "abstract virtio user backend ops", vhostfd is >> not properly assigned. >> - Fix a "MQ cannot be used" bug in v2, which is related to strip >> some feature bits that vhost kernel does not recognize. >> - Update release note. >> >> v2: (Lots of them are from yuanhan's comment) >> - Add offloding feature. >> - Add multiqueue support. >> - Add a new patch to postpone the sending of driver ok notification. >> - Put fix patch ahead of the whole patch series. >> - Split original 0001 patch into 0003 and 0004 patches. >> - Remove the original vhost_internal design, just add those into >> struct virtio_user_dev for simplicity. >> - Reword "control" to "send_request". >> - Reword "host_features" to "device_features". >> >> In v16.07, we upstreamed a virtual device, virtio_user (with vhost-user >> as the backend). The path to go with a vhost-kernel backend has been >> dropped for bad performance comparing to vhost-user and code simplicity. >> >> But after a second thought, virtio_user + vhost-kernel is a good >> candidate as an exceptional path, such as KNI, which exchanges packets >> with kernel networking stack. >> - maintenance: vhost-net (kernel) is upstreamed and extensively used >> kernel module. We don't need any out-of-tree module like KNI. >> - performance: as with KNI, this solution would use one or more >> kthreads to send/receive packets from user space DPDK applications, >> which has little impact on user space polling thread (except that >> it might enter into kernel space to wake up those kthreads if >> necessary). >> - features: vhost-net is born to be a networking solution, which has >> lots of networking related featuers, like multi queue, tso, multi-seg >> mbuf, etc. >> >> Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com> >> > Sounds great. However, I think we'll need a how-to doc for this to help > people get it up and running as a KNI replacement for packets to/from > the kernel. Any plans to draw up such a doc? It would be good to include > it in this patchset. I was planning to do that in separate patchset. But I agree with you that it's better to do that in this patchset. Thanks, Jianfeng > > /Bruce