From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 165CE56B7 for ; Mon, 6 Jun 2016 10:48:49 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 06 Jun 2016 01:48:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,426,1459839600"; d="scan'208";a="969681358" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by orsmga001.jf.intel.com with ESMTP; 06 Jun 2016 01:48:47 -0700 Date: Mon, 6 Jun 2016 16:49:33 +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: <20160606084933.GA10038@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62bdc1ee-c4a0-cc77-bd2f-a320c46e6bf5@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 08:48:50 -0000 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. > we should take Jiangfeng's solution. > > Also, if implementing a new feature and maintaining Jiangfeng's > virtio-net device are not so hard, As stated, I would assume so. --yliu > we should take his solution. > > I guess this is the point we need to consider. > What do you think? > > Thanks, > Tetsuya > > >> > >> Honestly, I'm OK if my solution is not merged. > >> Thus, it should be decided to let DPDK better. > >> > >> What do you think? > >> Which is better for DPDK? > >> > >> Thanks, > >> Tetsuya > >> > >>> > >>> --yliu > >>>