From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 24FC829CB for ; Mon, 6 Jun 2016 11:58:13 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP; 06 Jun 2016 02:58:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,426,1459839600"; d="scan'208";a="996061596" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga002.fm.intel.com with ESMTP; 06 Jun 2016 02:58:10 -0700 Date: Mon, 6 Jun 2016 17:58:56 +0800 From: Yuanhan Liu To: Tetsuya Mukawa Cc: dev@dpdk.org, jianfeng.tan@intel.com, huawei.xie@intel.com, Thomas Monjalon , David Marchand , "nakajima.yoshihiro@lab.ntt.co.jp" Message-ID: <20160606095856.GB10038@yliu-dev.sh.intel.com> References: <1457512409-24403-12-git-send-email-mukawa@igel.co.jp> <1464838185-21751-1-git-send-email-mukawa@igel.co.jp> <20160602073105.GS10038@yliu-dev.sh.intel.com> <687ff542-f97b-8706-5f96-0727dfcdf174@igel.co.jp> <20160603041748.GW10038@yliu-dev.sh.intel.com> <17d81002-b582-f866-100d-3f8ea5068089@igel.co.jp> <20160606072153.GY10038@yliu-dev.sh.intel.com> <62bdc1ee-c4a0-cc77-bd2f-a320c46e6bf5@igel.co.jp> <20160606084933.GA10038@yliu-dev.sh.intel.com> <7663e753-e7c6-6aec-e6a3-6039bdbfecff@igel.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7663e753-e7c6-6aec-e6a3-6039bdbfecff@igel.co.jp> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v5 0/6] Virtio-net PMD: QEMU QTest extension for container 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, 06 Jun 2016 09:58:14 -0000 On Mon, Jun 06, 2016 at 06:30:00PM +0900, Tetsuya Mukawa wrote: > On 2016/06/06 17:49, Yuanhan Liu wrote: > > On Mon, Jun 06, 2016 at 05:33:31PM +0900, Tetsuya Mukawa wrote: > >>>> [My solution] > >>>> - Pros > >>>> Basic principle of my implementation is not to reinvent the wheel. > >>> > >>> Yes, that's a good point. However, it's not that hard as we would have > >>> thought in the first time: the tough part that dequeue/enqueue packets > >>> from/to vring is actually offloaded to DPDK vhost-user. That means we > >>> only need re-implement the control path of virtio-net device, plus the > >>> vhost-user frontend. If you have a detailed look of your patchset as > >>> well Jianfeng's, you might find that the two patchset are actually with > >>> same code size. > >> > >> Yes, I know this. > >> So far, the amount of code is almost same, but in the future we may need > >> to implement more, if virtio-net specification is revised. > > > > It didn't take too much effort to implement from scratch, I doubt it > > will for future revise. And, virtio-net spec is unlikely revised, or > > to be precisely, unlikely revised quite often. Therefore, I don't see > > big issues here. > > > >>>> We can use a virtio-net device of QEMU implementation, it means we don't > >>>> need to maintain virtio-net device by ourselves, and we can use all of > >>>> functions supported by QEMU virtio-net device. > >>>> - Cons > >>>> Need to invoke QEMU process. > >>> > >>> Another thing is that it makes the usage a bit harder: look at the > >>> long qemu cli options of your example usage. It also has some traps, > >>> say, "--enable-kvm" is not allowed, which is a default option used > >>> with QEMU. > >> > >> Probably a kind of shell script will help the users. > > > > Yeah, that would help. But if we have a choice to make it simpler in the > > beginning, why not then? :-) > > > >>> > >>> And judging that we actually don't take too much effort to implement > >>> a virtio device emulation, I'd prefer it slightly. I guess something > >>> light weight and easier for use is more important here. > >> > >> This is very important point. > >> If so, we don't need much effort when virtio-spec is changed. > > > > I'd assume so. > > > >>> Actually, I have foreseen another benefit of adding virtio-user device > >>> emulation: we now might be able to add a rte_vhost_dequeue/enqueue_burst() > >>> unit test case. We simply can't do it before, since we depend on QEMU > >>> for testing, which is not acceptable for a unit test case. Making it > >>> be a unit test case would help us spotting any bad changes that would > >>> introduce bugs easily and automatically. > >> > >> As you mentioned above, QEMU process is not related with > >> dequeuing/enqueuing. > >> So I guess we may have a testing for rte_vhost_dequeue/enqueue_burst() > >> regardless of choice. > > > > Yes, we don't need the dequeue/enqueue part, but we need the vhost-user > > initialization part from QEMU vhost-user. Now that we have vhost-user > > frontend from virtio-user, we have no dependency on QEMU any more. > > > >>>> Anyway, we can choose one of belows. > >>>> 1. Take advantage of invoking less processes. > >>>> 2. Take advantage of maintainability of virtio-net device. > >> > >> If container usage that DPDK assumes is to invoke hundreds containers in > >> one host, > > > > I barely know about container, but I would assume that's not rare. > > Hi Yuanhan, > > It's great to hear it's not so hard to maintain Jiangfeng's virtio-net > device features. > > Please let me make sure how we can invoke many DPDK applications in > hundreds containers. > (Do we have a way to do? Or, will we have it in the future?) One thing that I have thought of is that we should remove the huge page dependency of current usage: huge page would be a very limited resource. Note that I don't mean to remove support of huge page; DPDK supports that by default and support it well after all. What I mean is to make it work for the non-hugepage cases as well, so that it could fit for the hundreds of containers case. --yliu