From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Coquelin Subject: Re: [PATCH v3 0/5] vhost: optimize enqueue Date: Thu, 13 Oct 2016 11:23:44 +0200 Message-ID: <570cc934-590e-8770-9853-f03a1380d181@redhat.com> References: <1471319402-112998-1-git-send-email-zhihong.wang@intel.com> <1471585430-125925-1-git-send-email-zhihong.wang@intel.com> <8F6C2BD409508844A0EFC19955BE09414E7B5581@SHSMSX103.ccr.corp.intel.com> <20160922022903.GJ23158@yliu-dev.sh.intel.com> <20161012025307.GG16751@yliu-dev.sh.intel.com> <8F6C2BD409508844A0EFC19955BE09414E7CD78E@SHSMSX103.ccr.corp.intel.com> <20161013053324.GP16751@yliu-dev.sh.intel.com> <8F6C2BD409508844A0EFC19955BE09414E7CDDC7@SHSMSX103.ccr.corp.intel.com> <76ec0b90-3748-e3c0-abbb-257570086268@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Jianbo Liu , Thomas Monjalon , "dev@dpdk.org" To: "Wang, Zhihong" , Yuanhan Liu Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 1FEC2214A for ; Thu, 13 Oct 2016 11:23:49 +0200 (CEST) In-Reply-To: <76ec0b90-3748-e3c0-abbb-257570086268@redhat.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/13/2016 09:54 AM, Maxime Coquelin wrote: > > > On 10/13/2016 08:02 AM, Wang, Zhihong wrote: >>> > Yes, that's great effort! With your hardwork, we know what the >>> bottleneck >>> > is and how it could be improved. >>> > >>> > However, you don't have to do code refactor (merge two code path to >>> one) >>> > to apply those improvements. From what I know, in this patchset, there >>> > are two factors could improve the performance: >>> > >>> > - copy hdr together with packet data >>> > >>> > - shadow used ring update and update at once >>> > >>> > The overall performance boost I got with your v6 patchset with mrg-Rx >>> > code path is about 27% (in PVP case). And I have just applied the 1st >>> > optimization, it yields about 20% boosts. The left could be covered if >>> > we apply the 2nd optimization (I guess). >>> > >>> > That would be a clean way to optimize vhost mergeable Rx path: >>> > >>> > - you don't touch non-mrg Rx path (well, you may could apply the >>> > shadow_used_ring trick to it as wel) >>> > >>> > This would at least make sure we will have no such performance >>> > regression issue reported by ARM guys. >>> > >>> > - you don't refactor the code >>> > >>> > The rewrite from scratch could introduce other issues, besides the >>> > performance regression. We may just don't know it yet. >>> > >>> > >>> > Make sense to you? If you agree, I think we could still make it in >>> > this release: they would be some small changes after all. For example, >>> > below is the patch applies the 1st optimization tip on top of >>> > dpdk-next-virtio >> >> Thanks for this great idea. I think it's a better way to do it. >> I'll start to make the patch then. >> >> > > I personally find having two paths better for maintenance as it is > easier to understand (IMHO). > So if we can have the performance gain while keeping the two paths, > I definitely support the idea. I was going to re-run some PVP benchmark with 0% pkt loss, as I had some strange results last week. Problem is that your series no more apply cleanly due to next-virtio's master branch history rewrite. Any chance you send me a rebased version so that I can apply the series? Thanks, Maxime