From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2AB21A034E; Sun, 26 Dec 2021 16:35:21 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DD07E40140; Sun, 26 Dec 2021 16:35:19 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 643454013F for ; Sun, 26 Dec 2021 16:35:18 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [RFC] mempool: rte_mempool_do_generic_get optimizations Date: Sun, 26 Dec 2021 16:34:37 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D86DB2@smartserver.smartshare.dk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC] mempool: rte_mempool_do_generic_get optimizations Thread-Index: Adf6bhdohzUW2Q6yT42XxsBvjQNdwg== From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Olivier Matz" , "Andrew Rybchenko" , X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org While going through the mempool code for potential optimizations, I = found two details in rte_mempool_do_generic_get(), which are easily = improved. Any comments or alternative suggestions? 1. The objects are returned in reverse order. This is silly, and should = be optimized. rte_mempool_do_generic_get() line 1493: /* Now fill in the response ... */ - for (index =3D 0, len =3D cache->len - 1; index < n; ++index, len--, = obj_table++) - *obj_table =3D cache_objs[len]; + rte_memcpy(obj_table, &cache_objs[cache->len - n], sizeof(void *) * = n); 2. The initial screening in rte_mempool_do_generic_get() differs from = the initial screening in rte_mempool_do_generic_put(). For reference, rte_mempool_do_generic_put() line 1343: /* No cache provided or if put would overflow mem allocated for cache = */ if (unlikely(cache =3D=3D NULL || n > RTE_MEMPOOL_CACHE_MAX_SIZE)) goto ring_enqueue; Notice how this uses RTE_MEMPOOL_CACHE_MAX_SIZE to determine the maximum = burst size into the cache. Now, rte_mempool_do_generic_get() line 1466: /* No cache provided or cannot be satisfied from cache */ if (unlikely(cache =3D=3D NULL || n >=3D cache->size)) goto ring_dequeue; cache_objs =3D cache->objs; /* Can this be satisfied from the cache? */ if (cache->len < n) { /* No. Backfill the cache first, and then fill from it */ uint32_t req =3D n + (cache->size - cache->len); First of all, there might already be up to cache->flushthresh - 1 = objects in the cache, which is 50 % more than cache->size, so screening = for n >=3D cache->size would not serve those from the cache! Second of all, the next step is to check if the cache holds sufficient = objects. So the initial screening should only do initial screening. = Therefore, I propose changing the initial screening to also use = RTE_MEMPOOL_CACHE_MAX_SIZE to determine the maximum burst size from the = cache, like in rte_mempool_do_generic_put(). rte_mempool_do_generic_get() line 1466: - /* No cache provided or cannot be satisfied from cache */ - if (unlikely(cache =3D=3D NULL || n >=3D cache->size)) + /* No cache provided or if get would overflow mem allocated for cache = */ + if (unlikely(cache =3D=3D NULL || n > RTE_MEMPOOL_CACHE_MAX_SIZE)) goto ring_dequeue; Med venlig hilsen / Kind regards, -Morten Br=F8rup