From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 9A4C2379E for ; Mon, 6 Jun 2016 10:03:20 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 06 Jun 2016 01:03:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,426,1459839600"; d="scan'208";a="714545951" Received: from shwdeisgchi083.ccr.corp.intel.com (HELO [10.239.67.193]) ([10.239.67.193]) by FMSMGA003.fm.intel.com with ESMTP; 06 Jun 2016 01:03:18 -0700 To: Tetsuya Mukawa , 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> Cc: dev@dpdk.org, huawei.xie@intel.com, Thomas Monjalon , David Marchand , "nakajima.yoshihiro@lab.ntt.co.jp" From: "Tan, Jianfeng" Message-ID: <292d8c0b-7979-1173-243b-62adaf3cb353@intel.com> Date: Mon, 6 Jun 2016 16:03:18 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <17d81002-b582-f866-100d-3f8ea5068089@igel.co.jp> Content-Type: text/plain; charset=windows-1252; format=flowed 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:03:21 -0000 Hi, On 6/6/2016 1:10 PM, Tetsuya Mukawa wrote: > Hi Yuanhan, > > Sorry for late replying. > > 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. It will barely introduce any change when virtio-net specification is changed as far as I can see. The only part we care is the how desc, avail, used distribute on memory, which is a very small part. It's true that my solution now seriously depend on vhost-user protocol, which is defined in QEMU. I cannot see a big problem there so far. > Also, LSC interrupt and control queue functions are not > supported yet. > 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. LSC is really less important than rxq interrupt (IMO). We don't know how long will rxq interrupt of virtio be available for QEMU, but we can accelerate it if we avoid using QEMU. Actually, if the vhost backend is vhost-user (the main use case), current qemu have limited control queue support, because it needs the support from the vhost user backend. Add one more con of my solution: - Need to write another logic to support other virtio device (say virtio-scsi), if it's easier of Tetsuya's solution to do that? > > [My solution] > - Pros > Basic principle of my implementation is not to reinvent the wheel. > 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. Two more possible cons: a) This solution also needs to maintain qtest utility, right? b) There's still address arrange restriction, right? Although we can use "--base-virtaddr=0x400000000" to relieve this question, but how about if there are 2 or more devices? (By the way, is there still address arrange requirement for 32 bit system) c) Actually, IMO this solution is sensitive to any virtio spec change (io port, pci configuration space). > > > 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. Yes, agreed. Thanks, Jianfeng > > What do you think? > Which is better for DPDK? > > Thanks, > Tetsuya > >> --yliu >>