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 3837AA04A8; Mon, 24 Jan 2022 16:39:10 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2594C41158; Mon, 24 Jan 2022 16:39:10 +0100 (CET) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by mails.dpdk.org (Postfix) with ESMTP id 246AB40040 for ; Mon, 24 Jan 2022 16:39:08 +0100 (CET) Received: by mail-wr1-f46.google.com with SMTP id s18so14341269wrv.7 for ; Mon, 24 Jan 2022 07:39:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=YxQ6GnOgvpTwt5Xz7tOZzNqMkekuSHAK0LQIpkILABc=; b=U176o5R1FV5KEGOBg1AqOq6Ql3YXP2cUjOHKAiJK+SJbqnopAuoQaVgkJmAfHe8Y6Z wHSnhw81ngl4wJEJB+p5dvFi+o1Imgp0UtiMWZ4RYfuoJQUf0yqOpIcJTjzBnjHcEKGA t9qAf3oHGb6R7C+xVsnrOQVW0seKj+gSxjgfhBzNOyFLDMamqNcRGKt2h/T0OyIOD2OU IxO0xo/8ImnOlkGTxK0ld6Cfzum47kF90CWxopXemPVtkzE5EL2I+s12zv4yGIzALniQ iqxvTvve53fByEh1neD06VGqXp0aoTrVHOHLOiHquA2Uv5ZhGnNjX9UbbpDkern2y0su uinA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=YxQ6GnOgvpTwt5Xz7tOZzNqMkekuSHAK0LQIpkILABc=; b=HMrQUXzPDZVnBeK2Nv3RxDyzw1TyvUl2Y/wtM6Jjb6qhPAuXQPcbdlh4JFPFdlJPwV WyMTDlOVgB9cI3QjG1gh+EVijGTLEs8rIENIX2glfvU8jbjN5S7SNsrZH+F2S57cFsjR EPmVXCB3Euiwx6U/Lgl3KK8Q7WnVK6QZdvIcDaIfNImBZmW3danBAs6olaNzaQLHINFX nfHugaJ62YglNbWfoHkjcCEXFxzRajfSqZP8dkeVQjR9H+dEGY35xsVbtBoUfDo3u0Xj GbOFo8pZ+1EPZPAIzkGqPvU5n6X87QeN3kSE02Hme6H1S6DPncyO1Y8GOGf1ehWv9Kb3 MVcA== X-Gm-Message-State: AOAM533sg4Yk8GnAdU9sqMWjkIRdHqq3JSfNCi+0sPl0EDpqHalFAFPI WCjwq0k6vbS/CdWw8+mmgF785g== X-Google-Smtp-Source: ABdhPJwH9InZMzje84M9PVuU+hfy/uEN4H/c0CnctjWufI2sBzHRv67jMotUQtw0x4YyeE0+WcWYvw== X-Received: by 2002:adf:9148:: with SMTP id j66mr15117207wrj.434.1643038747864; Mon, 24 Jan 2022 07:39:07 -0800 (PST) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id m17sm19508515wmq.35.2022.01.24.07.39.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jan 2022 07:39:07 -0800 (PST) Date: Mon, 24 Jan 2022 16:39:06 +0100 From: Olivier Matz To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: andrew.rybchenko@oktetlabs.ru, bruce.richardson@intel.com, jerinjacobk@gmail.com, dev@dpdk.org Subject: Re: [PATCH v3] mempool: fix put objects to mempool with cache Message-ID: References: <98CBD80474FA8B44BF855DF32C47DC35D86DB2@smartserver.smartshare.dk> <20220119150301.42583-1-mb@smartsharesystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220119150301.42583-1-mb@smartsharesystems.com> 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 Hi Morten, On Wed, Jan 19, 2022 at 04:03:01PM +0100, Morten Brørup wrote: > mempool: fix put objects to mempool with cache > > This patch optimizes the rte_mempool_do_generic_put() caching algorithm, > and fixes a bug in it. I think we should avoid grouping fixes and optimizations in one patch. The main reason is that fixes aims to be backported, which is not the case of optimizations. > The existing algorithm was: > 1. Add the objects to the cache > 2. Anything greater than the cache size (if it crosses the cache flush > threshold) is flushed to the ring. > > Please note that the description in the source code said that it kept > "cache min value" objects after flushing, but the function actually kept > "size" objects, which is reflected in the above description. > > Now, the algorithm is: > 1. If the objects cannot be added to the cache without crossing the > flush threshold, flush the cache to the ring. > 2. Add the objects to the cache. > > This patch changes these details: > > 1. Bug: The cache was still full after flushing. > In the opposite direction, i.e. when getting objects from the cache, the > cache is refilled to full level when it crosses the low watermark (which > happens to be zero). > Similarly, the cache should be flushed to empty level when it crosses > the high watermark (which happens to be 1.5 x the size of the cache). > The existing flushing behaviour was suboptimal for real applications, > because crossing the low or high watermark typically happens when the > application is in a state where the number of put/get events are out of > balance, e.g. when absorbing a burst of packets into a QoS queue > (getting more mbufs from the mempool), or when a burst of packets is > trickling out from the QoS queue (putting the mbufs back into the > mempool). > NB: When the application is in a state where put/get events are in > balance, the cache should remain within its low and high watermarks, and > the algorithms for refilling/flushing the cache should not come into > play. > Now, the mempool cache is completely flushed when crossing the flush > threshold, so only the newly put (hot) objects remain in the mempool > cache afterwards. I'm not sure we should call this behavior a bug. What is the impact on applications, from a user perspective? Can it break a use-case, or have an important performance impact? > 2. Minor bug: The flush threshold comparison has been corrected; it must > be "len > flushthresh", not "len >= flushthresh". > Reasoning: Consider a flush multiplier of 1 instead of 1.5; the cache > would be flushed already when reaching size elements, not when exceeding > size elements. > Now, flushing is triggered when the flush threshold is exceeded, not > when reached. Same here, we should ask ourselves what is the impact before calling it a bug. > 3. Optimization: The most recent (hot) objects are flushed, leaving the > oldest (cold) objects in the mempool cache. > This is bad for CPUs with a small L1 cache, because when they get > objects from the mempool after the mempool cache has been flushed, they > get cold objects instead of hot objects. > Now, the existing (cold) objects in the mempool cache are flushed before > the new (hot) objects are added the to the mempool cache. > > 4. Optimization: Using the x86 variant of rte_memcpy() is inefficient > here, where n is relatively small and unknown at compile time. > Now, it has been replaced by an alternative copying method, optimized > for the fact that most Ethernet PMDs operate in bursts of 4 or 8 mbufs > or multiples thereof. For these optimizations, do you have an idea of what is the performance gain? Ideally (I understand it is not always possible), each optimization is done separately, and its impact is measured. > v2 changes: > > - Not adding the new objects to the mempool cache before flushing it > also allows the memory allocated for the mempool cache to be reduced > from 3 x to 2 x RTE_MEMPOOL_CACHE_MAX_SIZE. > However, such this change would break the ABI, so it was removed in v2. > > - The mempool cache should be cache line aligned for the benefit of the > copying method, which on some CPU architectures performs worse on data > crossing a cache boundary. > However, such this change would break the ABI, so it was removed in v2; > and yet another alternative copying method replaced the rte_memcpy(). OK, we may want to keep this in mind for the next abi breakage. > > v3 changes: > > - Actually remove my modifications of the rte_mempool_cache structure. > > Signed-off-by: Morten Brørup > --- > lib/mempool/rte_mempool.h | 51 +++++++++++++++++++++++++++++---------- > 1 file changed, 38 insertions(+), 13 deletions(-) > > diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h > index 1e7a3c1527..7b364cfc74 100644 > --- a/lib/mempool/rte_mempool.h > +++ b/lib/mempool/rte_mempool.h > @@ -1334,6 +1334,7 @@ static __rte_always_inline void > rte_mempool_do_generic_put(struct rte_mempool *mp, void * const *obj_table, > unsigned int n, struct rte_mempool_cache *cache) > { > + uint32_t index; > void **cache_objs; > > /* increment stat now, adding in mempool always success */ > @@ -1344,31 +1345,56 @@ rte_mempool_do_generic_put(struct rte_mempool *mp, void * const *obj_table, > if (unlikely(cache == NULL || n > RTE_MEMPOOL_CACHE_MAX_SIZE)) > goto ring_enqueue; > > - cache_objs = &cache->objs[cache->len]; > + /* If the request itself is too big for the cache */ > + if (unlikely(n > cache->flushthresh)) > + goto ring_enqueue; > > /* > * The cache follows the following algorithm > - * 1. Add the objects to the cache > - * 2. Anything greater than the cache min value (if it crosses the > - * cache flush threshold) is flushed to the ring. > + * 1. If the objects cannot be added to the cache without > + * crossing the flush threshold, flush the cache to the ring. > + * 2. Add the objects to the cache. > */ > > - /* Add elements back into the cache */ > - rte_memcpy(&cache_objs[0], obj_table, sizeof(void *) * n); > + if (cache->len + n <= cache->flushthresh) { > + cache_objs = &cache->objs[cache->len]; > > - cache->len += n; > + cache->len += n; > + } else { > + cache_objs = cache->objs; > > - if (cache->len >= cache->flushthresh) { > - rte_mempool_ops_enqueue_bulk(mp, &cache->objs[cache->size], > - cache->len - cache->size); > - cache->len = cache->size; > +#ifdef RTE_LIBRTE_MEMPOOL_DEBUG > + if (rte_mempool_ops_enqueue_bulk(mp, cache_objs, cache->len) < 0) > + rte_panic("cannot put objects in mempool\n"); > +#else > + rte_mempool_ops_enqueue_bulk(mp, cache_objs, cache->len); > +#endif > + cache->len = n; > + } > + > + /* Add the objects to the cache. */ > + for (index = 0; index < (n & ~0x3); index += 4) { > + cache_objs[index] = obj_table[index]; > + cache_objs[index + 1] = obj_table[index + 1]; > + cache_objs[index + 2] = obj_table[index + 2]; > + cache_objs[index + 3] = obj_table[index + 3]; > + } > + switch (n & 0x3) { > + case 3: > + cache_objs[index] = obj_table[index]; > + index++; /* fallthrough */ > + case 2: > + cache_objs[index] = obj_table[index]; > + index++; /* fallthrough */ > + case 1: > + cache_objs[index] = obj_table[index]; > } > > return; > > ring_enqueue: > > - /* push remaining objects in ring */ > + /* Put the objects into the ring */ > #ifdef RTE_LIBRTE_MEMPOOL_DEBUG > if (rte_mempool_ops_enqueue_bulk(mp, obj_table, n) < 0) > rte_panic("cannot put objects in mempool\n"); > @@ -1377,7 +1403,6 @@ rte_mempool_do_generic_put(struct rte_mempool *mp, void * const *obj_table, > #endif > } > > - > /** > * Put several objects back in the mempool. > * > -- > 2.17.1 >