From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com [209.85.192.171]) by dpdk.org (Postfix) with ESMTP id D0583377C for ; Mon, 6 Jun 2016 11:30:03 +0200 (CEST) Received: by mail-pf0-f171.google.com with SMTP id y124so5684695pfy.0 for ; Mon, 06 Jun 2016 02:30:03 -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=B5CXOqO8g4+0sAjP4xfC6Kt8B4R2q0o24E9g2dlHSVc=; b=zXAK6e0gwfIa6weFxonX1oCXGFLu9CThhmpLAto0FPvkDIBkn8f6mmp1Vg7O4AuxEb O07SHJgc8rPl01I7HOlRbORjo37Pt+9q1dK5DV6Jw8QpmxbhgV3arvdG0JAGmRiTc17S 175S2WVS/fNMjSFynzoKXVummWqtZa3bONU0wITJUHV9gw5tojW9M+YednVN3Hib/wQC LMrGSu5KNBUTfO+WKw2I+PsxHMoS8mOrxv9IGhHSYo/62OZSfrK5gyn5dHJSYIbnHtfp qtbUbQR7biTLlzylNpkkpIuUD3ZCBWPdD8RuRQ011V9iT+Lbv+a6Uvq4DyB4takPnU3z Urtw== 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=B5CXOqO8g4+0sAjP4xfC6Kt8B4R2q0o24E9g2dlHSVc=; b=ARE/iiLg9Tmr6I0pNQSHLKMI7nEC00cmpjTSi991nGQdhB+RBShtXjtOjc8F08bIZU LmNo8VMNiFQbfCmbE6T3I8ozo9plEdhHg1H9QeYB2665MGHXh44VqjXZnRVs5fUtOzDe 4O+mScvyzpq4bqiBObaow2NUW53GCF0SNfOzFILYPTfgWg7sYaK9ncmQmZG42ZsSKjnG Ab6T/ZfK8BHDoasZv9HnrLzKCXjBo3YlUGpZ7i46B7kNZ7/hlNoP3WuIh8X98PGoZuN1 aAM3Zh72lYvdDs6MlWirPn7R5/8XHf/gNPMj2anRB84HOzf6QOMLnYqzouB+53QuFqjQ iyjg== X-Gm-Message-State: ALyK8tJeZsFbPCt2mRvqU+5ZcCD5aFZV28EmV5dcUAJnjOdvWFbXxgJ7Ie2lIlH+fNfrCQ== X-Received: by 10.98.73.214 with SMTP id r83mr24276287pfi.114.1465205403078; Mon, 06 Jun 2016 02:30:03 -0700 (PDT) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by smtp.googlemail.com with ESMTPSA id vb6sm23643089pac.16.2016.06.06.02.30.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2016 02:30:02 -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> <62bdc1ee-c4a0-cc77-bd2f-a320c46e6bf5@igel.co.jp> <20160606084933.GA10038@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: <7663e753-e7c6-6aec-e6a3-6039bdbfecff@igel.co.jp> Date: Mon, 6 Jun 2016 18:30:00 +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: <20160606084933.GA10038@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 09:30:04 -0000 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?) Thanks, Tetsuya > >> 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 >>>>>