From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id D5B3DA05D3 for ; Tue, 21 May 2019 11:35:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3CFB914EC; Tue, 21 May 2019 11:35:08 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 8BB2810BD for ; Tue, 21 May 2019 11:35:06 +0200 (CEST) Received: from us4-mdac16-13.ut7.mdlocal (unknown [10.7.65.237]) by pure.maildistiller.com (PPE Hosted ESMTP Server) with ESMTP id F1BBA8009B; Tue, 21 May 2019 09:35:05 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us2.ppe-hosted.com (us4-filterqueue.mdlocal [10.7.20.246]) by pure.maildistiller.com (PPE Hosted ESMTP Server) with ESMTPS id 7336928004D; Tue, 21 May 2019 09:35:05 +0000 (UTC) Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us2.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id BB9711C005F; Tue, 21 May 2019 09:35:04 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 21 May 2019 10:34:58 +0100 To: Xiao Wang , CC: References: <20190521090321.138062-1-xiao.w.wang@intel.com> From: Andrew Rybchenko Message-ID: <98702cfa-66ed-e13f-a5ae-c85eb6d64c2f@solarflare.com> Date: Tue, 21 May 2019 12:34:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190521090321.138062-1-xiao.w.wang@intel.com> Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24628.001 X-TM-AS-Result: No-11.124000-8.000000-10 X-TMASE-MatchedRID: WMT2WRIkHPM6yy6RAAEPc40SKX5sgI0F69aS+7/zbj+qvcIF1TcLYKOI rKL+ynQk7WucYuPoPlskTiFDx5Ln6b8nFEEdZMCmfid4LSHtIAPujGgmSxndohuuMvCbaQa2eIm lnpvu90DsDHmtNvKzfo9CL1e45ag4tAOuXrON8jZL70jDqgMHfqLwP+jjbL9KR2YNIFh+clFNJL ReVzHnVK5WpPY8SWdyUZOPhy91qnEu+/ZxS0sr+xlJRfzNw8af1Mc6SC5sKVbDra5IbmQvVmtKV MfqNSI2dbJUM32TEJwngSBWaB6DMhYmidDRMooCaDgPZBX/bMuuiAW0p38/t8eILR3BvknvUdfE Kc10rU79hat6Mb3lf+6i+CFG0PeWYcjDoVD2e568yvURlYGCIR98smInoXHLiEiOvN7JAwr9Jff CfgeQQTU3HPhRrRy9/76CM4Z/MGblRxm3A2wKujl/1fD/GopdWQy9YC5qGvz6APa9i04WGLyah9 aCYUCHDNVXzNnNGcsG4mh1FWxwiZV4sOiTNI4GH5HzAEnp3NusYKgtLKLIed6ACDYt7EzMv9/dH hYZxHlppmjNulD7sIJa7Fv0YzwZ X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--11.124000-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24628.001 X-MDID: 1558431305-jytUriBSuUOj Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] mempool: optimize copy in cache get X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 5/21/19 12:03 PM, Xiao Wang wrote: > Use rte_memcpy to improve the pointer array copy. This optimization method > has already been applied to __mempool_generic_put() [1], this patch applies > it to __mempool_generic_get(). Slight performance gain can be observed in > testpmd txonly test. > > [1] 863bfb47449 ("mempool: optimize copy in cache") > > Signed-off-by: Xiao Wang > --- > lib/librte_mempool/rte_mempool.h | 7 +------ > 1 file changed, 1 insertion(+), 6 deletions(-) > > diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h > index 8053f7a04..975da8d22 100644 > --- a/lib/librte_mempool/rte_mempool.h > +++ b/lib/librte_mempool/rte_mempool.h > @@ -1344,15 +1344,11 @@ __mempool_generic_get(struct rte_mempool *mp, void **obj_table, > unsigned int n, struct rte_mempool_cache *cache) > { > int ret; > - uint32_t index, len; > - void **cache_objs; > > /* No cache provided or cannot be satisfied from cache */ > if (unlikely(cache == NULL || n >= cache->size)) > goto ring_dequeue; > > - cache_objs = cache->objs; > - > /* Can this be satisfied from the cache? */ > if (cache->len < n) { > /* No. Backfill the cache first, and then fill from it */ > @@ -1375,8 +1371,7 @@ __mempool_generic_get(struct rte_mempool *mp, void **obj_table, > } > > /* Now fill in the response ... */ > - for (index = 0, len = cache->len - 1; index < n; ++index, len--, obj_table++) > - *obj_table = cache_objs[len]; > + rte_memcpy(obj_table, &cache->objs[cache->len - n], sizeof(void *) * n); > > cache->len -= n; > I think the idea of the loop above is to get objects in reverse order to order to reuse cache top objects (put last) first. It should improve cache hit etc. So, performance effect of the patch could be very different on various CPUs (with different cache sizes) and various work-loads. So, I doubt that it is a step in right direction. Andrew.