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 ED79F9E7 for ; Thu, 13 Oct 2016 09:54:21 +0200 (CEST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 49D6268804; Thu, 13 Oct 2016 07:54:21 +0000 (UTC) Received: from [10.36.4.21] (vpn1-4-21.ams2.redhat.com [10.36.4.21]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9D7sI82022808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Oct 2016 03:54:19 -0400 To: "Wang, Zhihong" , Yuanhan Liu 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> Cc: Jianbo Liu , Thomas Monjalon , "dev@dpdk.org" From: Maxime Coquelin Message-ID: <76ec0b90-3748-e3c0-abbb-257570086268@redhat.com> Date: Thu, 13 Oct 2016 09:54:18 +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: <8F6C2BD409508844A0EFC19955BE09414E7CDDC7@SHSMSX103.ccr.corp.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.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 13 Oct 2016 07:54:21 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v3 0/5] vhost: optimize enqueue 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: Thu, 13 Oct 2016 07:54:22 -0000 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. Thanks, Maxime