From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f181.google.com (mail-pf0-f181.google.com [209.85.192.181]) by dpdk.org (Postfix) with ESMTP id 9E6C258CB for ; Mon, 6 Jun 2016 10:33:34 +0200 (CEST) Received: by mail-pf0-f181.google.com with SMTP id z187so10801926pfz.3 for ; Mon, 06 Jun 2016 01:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=igel-co-jp.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=1i3gwvxN6zATJRWNAivVWXrrKeeYvxywDbr2ArSlWHM=; b=hJQf1hoV+l1ibj/iNpkBwB2p0P5I2rTEMiWawXP0ZSSq1ledjfut1Q2Rj0B2XJGZ63 ppdcdvJ5hkjRyXY7FerXqj0gRNUY/jlFafBz6sdyeBJ8IItlyZR5/a8wfOJ8fHXmcsNk rZ7QUVdpZAjim7xgilkqMMvOvVyu/PDrbdM57V8LvVENwRPpavFY1TK40U2QlRRf1NU4 a6wuHujnFvermwGHp+H1LEOPDRIvYr/Ed06+ihY8UeURhz6YiLtYaiPNSnIhbRu81tsz 4DDssqUkxrETMIhMhVoPXnx6qVFc1nWKS3xFr918E8V3TWDsE/v4SN3RmprfWsHXdLdz kl5g== 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=1i3gwvxN6zATJRWNAivVWXrrKeeYvxywDbr2ArSlWHM=; b=IJPt3OecHqBFcrtq3mpTgJ2gkkUZPpPG/wXEWnONSh6hwLKYLFONlLPLkFtsdvAUjP vnkFix5VbMNeU41lJWAXvTdIHGRPNRDUwI+0XaJPahFhDfQ9XUpfPpTzH59+i69JPeae 4HYWzKWxcTuDjC5zUZx1wbjFwWEWpj99qgxclUVJKTCyMzKzYODooOMSlx4lEwhBgtLu Qc8BZRRpkfC+72mwLDiJxWe2MKgK7Ag1VMTr+nIQ9owS+KOQsOagctrZJFvpO9LYcrW6 rKjxKY7vPNR+rkDkLpCByxJFePAIygFIyf1WhTEIYL1mYaO2Q3jL7CwqIKdSDb5uZFEi iFtA== X-Gm-Message-State: ALyK8tKDlKVbx01usjNB1s9ZbnBs947Ba4NQFVB0cp4Pv2dVDtVv03rheRgPSkAaLougBQ== X-Received: by 10.98.23.146 with SMTP id 140mr24370504pfx.122.1465202013837; Mon, 06 Jun 2016 01:33:33 -0700 (PDT) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by smtp.googlemail.com with ESMTPSA id 17sm25517989pfa.59.2016.06.06.01.33.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2016 01:33:33 -0700 (PDT) To: Yuanhan Liu 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> Cc: dev@dpdk.org, jianfeng.tan@intel.com, huawei.xie@intel.com, Thomas Monjalon , David Marchand , "nakajima.yoshihiro@lab.ntt.co.jp" From: Tetsuya Mukawa Message-ID: <62bdc1ee-c4a0-cc77-bd2f-a320c46e6bf5@igel.co.jp> Date: Mon, 6 Jun 2016 17:33:31 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160606072153.GY10038@yliu-dev.sh.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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:33:35 -0000 On 2016/06/06 16:21, Yuanhan Liu wrote: > 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. Sorry, I haven't noticed that ctrl queue has been already enabled. > > 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. 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. > >> 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. > > 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. > > 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. >> 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, we should take Jiangfeng's solution. Also, if implementing a new feature and maintaining Jiangfeng's virtio-net device are not so hard, 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 >>>