From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 22DFC2B92 for ; Tue, 23 Aug 2016 18:41:05 +0200 (CEST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9343064370; Tue, 23 Aug 2016 16:41:04 +0000 (UTC) Received: from [10.36.4.245] (vpn1-4-245.ams2.redhat.com [10.36.4.245]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7NGf2gg007743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2016 12:41:03 -0400 To: Yuanhan Liu References: <1471939839-29778-1-git-send-email-yuanhan.liu@linux.intel.com> <7eeb0acd-e98d-1dcd-793f-0b5f4b74874c@redhat.com> <20160823144211.GP30752@yliu-dev.sh.intel.com> <20160823145322.GR30752@yliu-dev.sh.intel.com> Cc: dev@dpdk.org From: Maxime Coquelin Message-ID: <67343933-17b0-6dc9-47cf-0ee04ec1b6c3@redhat.com> Date: Tue, 23 Aug 2016 18:41:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160823145322.GR30752@yliu-dev.sh.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 23 Aug 2016 16:41:04 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 0/6] vhost: add Tx zero copy support 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: Tue, 23 Aug 2016 16:41:05 -0000 On 08/23/2016 04:53 PM, Yuanhan Liu wrote: > BTW, I really appreicate your efforts on reviewing this patchset. > > It would be great if you could take some time to review my another > patchset :) > > [PATCH 0/7] vhost: vhost-cuse removal and code path refactoring > > It touchs a large of code base, that I wish I could apply it ASAP. > So that the chance a later patch will introduce conflicts is small. Sure, I will try to review it by tomorrow morning (CET). REgards, Maxime > > --yliu > > On Tue, Aug 23, 2016 at 10:42:11PM +0800, Yuanhan Liu wrote: >> On Tue, Aug 23, 2016 at 04:18:40PM +0200, Maxime Coquelin wrote: >>> >>> >>> On 08/23/2016 10:10 AM, Yuanhan Liu wrote: >>>> This patch set enables vhost Tx zero copy. The majority work goes to >>>> patch 4: vhost: add Tx zero copy. >>>> >>>> The basic idea of Tx zero copy is, instead of copying data from the >>>> desc buf, here we let the mbuf reference the desc buf addr directly. >>>> >>>> The major issue behind that is how and when to update the used ring. >>>> You could check the commit log of patch 4 for more details. >>>> >>>> Patch 5 introduces a new flag, RTE_VHOST_USER_TX_ZERO_COPY, to enable >>>> Tx zero copy, which is disabled by default. >>>> >>>> Few more TODOs are left, including handling a desc buf that is across >>>> two physical pages, updating release note, etc. Those will be fixed >>>> in later version. For now, here is a simple one that hopefully it >>>> shows the idea clearly. >>>> >>>> I did some quick tests, the performance gain is quite impressive. >>>> >>>> For a simple dequeue workload (running rxonly in vhost-pmd and runnin >>>> txonly in guest testpmd), it yields 40+% performance boost for packet >>>> size 1400B. >>>> >>>> For VM2VM iperf test case, it's even better: about 70% boost. >>> >>> This is indeed impressive. >>> Somewhere else, you mention that there is a small regression with small >>> packets. Do you have some figures to share? >> >> It could be 15% drop for PVP case with 64B packet size. The test topo is: >> >> nic 0 --> VM Rx --> VM Tx --> nic 0 >> >> Put simply, I run vhost-switch example in the host and run testpmd in >> the guest. >> >> Though the number looks big, I don't think it's an issue. First of all, >> it's disabled by default. Secondly, if you want to enable it, you should >> be certain that the packet size is normally big, otherwise, you should >> not bother to try with zero copy. >> >>> Also, with this feature OFF, do you see some regressions for both small >>> and bigger packets? >> >> Good question. I didn't check it on purpose, but I did try when it's >> disabled, the number I got is pretty the same as the one I got without >> this feature. So, I would say I don't see regressions. Anyway, I could >> do more tests to make sure. >> >> --yliu