From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 79111C672 for ; Fri, 24 Jun 2016 18:04:45 +0200 (CEST) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bGTdM-0005ks-73; Fri, 24 Jun 2016 18:07:09 +0200 To: Jerin Jacob References: <1464101442-10501-1-git-send-email-jerin.jacob@caviumnetworks.com> <1464250025-9191-1-git-send-email-jerin.jacob@caviumnetworks.com> <574BFD97.2010505@6wind.com> <20160531125822.GA10995@localhost.localdomain> <574DFC9A.2050304@6wind.com> <20160601070018.GA26922@localhost.localdomain> <574FE202.2060306@6wind.com> <20160602093936.GB6794@localhost.localdomain> <5750A220.6040804@6wind.com> <20160603070202.GA6153@localhost.localdomain> <5763D397.8060900@6wind.com> Cc: dev@dpdk.org, thomas.monjalon@6wind.com, bruce.richardson@intel.com, konstantin.ananyev@intel.com From: Olivier Matz Message-ID: <576D5A15.9030705@6wind.com> Date: Fri, 24 Jun 2016 18:04:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <5763D397.8060900@6wind.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] mempool: replace c memcpy code semantics with optimized rte_memcpy 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: Fri, 24 Jun 2016 16:04:45 -0000 On 06/17/2016 12:40 PM, Olivier Matz wrote: > Hi Jerin, > > On 06/03/2016 09:02 AM, Jerin Jacob wrote: >> On Thu, Jun 02, 2016 at 11:16:16PM +0200, Olivier MATZ wrote: >> Hi Olivier, >> >>> This is probably more a measure of the pure CPU cost of the mempool >>> function, without considering the memory cache aspect. So, of course, >>> a real use-case test should be done to confirm or not that it increases >>> the performance. I'll manage to do a test and let you know the result. >> >> OK >> >> IMO, put rte_memcpy makes sense(this patch) as their no behavior change. >> However, if get rte_memcpy with behavioral changes makes sense some platform >> then we can enable it on conditional basics(I am OK with that) >> >>> >>> By the way, not all drivers are allocating or freeing the mbufs by >>> bulk, so this modification would only affect these ones. What driver >>> are you using for your test? >> >> I have tested with ThunderX nicvf pmd(uses the bulk mode). >> Recently sent out driver in ml for review > > Just to let you know I do not forget this. I still need to > find some time to do a performance test. Quoting from the other thread [1] too to save this in patchwork: [1] http://dpdk.org/ml/archives/dev/2016-June/042701.html > On 06/24/2016 05:56 PM, Hunt, David wrote: >> Hi Jerin, >> >> I just ran a couple of tests on this patch on the latest master head on >> a couple of machines. An older quad socket E5-4650 and a quad socket >> E5-2699 v3 >> >> E5-4650: >> I'm seeing a gain of 2% for un-cached tests and a gain of 9% on the >> cached tests. >> >> E5-2699 v3: >> I'm seeing a loss of 0.1% for un-cached tests and a gain of 11% on the >> cached tests. >> >> This is purely the autotest comparison, I don't have traffic generator >> results. But based on the above, I don't think there are any performance >> issues with the patch. >> > > Thanks for doing the test on your side. I think it's probably enough > to integrate Jerin's patch . > > About using a rte_memcpy() in the mempool_get(), I don't think I'll have > the time to do a more exhaustive test before the 16.07, so I'll come > back with it later. > > I'm sending an ack on the v2 thread. Acked-by: Olivier Matz