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 755562B86 for ; Mon, 6 Jun 2016 09:21:24 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP; 06 Jun 2016 00:21:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,426,1459839600"; d="scan'208";a="822424938" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by orsmga003.jf.intel.com with ESMTP; 06 Jun 2016 00:21:08 -0700 Date: Mon, 6 Jun 2016 15:21:53 +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: <20160606072153.GY10038@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17d81002-b582-f866-100d-3f8ea5068089@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 07:21:25 -0000 On Mon, Jun 06, 2016 at 02:10:46PM +0900, Tetsuya Mukawa wrote: > Hi Yuanhan, > > Sorry for late replying. Never mind. > > On 2016/06/03 13:17, Yuanhan Liu wrote: > > On Thu, Jun 02, 2016 at 06:30:18PM +0900, Tetsuya Mukawa wrote: > >> Hi Yuanhan, > >> > >> On 2016/06/02 16:31, Yuanhan Liu wrote: > >>> But still, I'd ask do we really need 2 virtio for container solutions? > >> > >> I appreciate your comments. > > > > No, I appreciate your effort for contributing to DPDK! vhost-pmd stuff > > is just brilliant! > > > >> Let me have time to discuss it with our team. > > > > I'm wondering could we have one solution only. IMO, the drawback of > > having two (quite different) solutions might outweighs the benefit > > it takes. Say, it might just confuse user. > > I agree with this. > If we have 2 solutions, it would confuse the DPDK users. > > > > > OTOH, I'm wondering could you adapt to Jianfeng's solution? If not, > > what's the missing parts, and could we fix it? I'm thinking having > > one unified solution will keep ours energy/focus on one thing, making > > it better and better! Having two just splits the energy; it also > > introduces extra burden for maintaining. > > Of course, I adopt Jiangeng's solution basically. > Actually, his solution is almost similar I tried to implement at first. > > I guess here is pros/cons of 2 solutions. > > [Jianfeng's solution] > - Pros > Don't need to invoke QEMU process. > - Cons > If virtio-net specification is changed, we need to implement it by > ourselves. Also, LSC interrupt and control queue functions are not > supported yet. Jianfeng have made and sent out the patch to enable ctrl queue and multiple queue support. For the LSC part, no much idea yet so far. But I'm assuming it will not take too much effort, either. > I agree both functions may not be so important, and if we need it > we can implement them, but we need to pay energy to implement them. > > [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. > 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. 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. 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. --yliu > Anyway, we can choose one of belows. > 1. Take advantage of invoking less processes. > 2. Take advantage of maintainability of virtio-net device. > > 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 > >