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 4A504A0353; Thu, 6 Jan 2022 17:55:33 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DEAB041153; Thu, 6 Jan 2022 17:55:32 +0100 (CET) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) by mails.dpdk.org (Postfix) with ESMTP id 8E05041152 for ; Thu, 6 Jan 2022 17:55:31 +0100 (CET) Received: by mail-io1-f46.google.com with SMTP id e128so3875261iof.1 for ; Thu, 06 Jan 2022 08:55:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OJgoXagcpdMGxdwGpA3W6np1Bh2j/I1vUBwlgJ+QTl8=; b=bGzJUkeRJS85YPF5pkCgDVeTJbB0BKPOMu1zr/FhgW4iS2ibzbJFe6Ud2KxGhPDV7R X2jYUXAoazv7VuADJ6wt8Y2kaj95rNMEGd+Qu2GAjCrBW5y7+mEPvLMlDA6o18Ps6M9X qE2b5KtEad1c8LfAc/BB8c/eFTMuyCn1zaI3cJhRtWB+g3o3AFF4yXcSl4SDGN2gbgGu 3yVkmjvJqqisbVVDT5vnFo0JUsiHUwN5LJNzGWDiGJZU1NDvP0VBYaSphW2XQvavQe8h 9vW5+dlauclV8kTPxYh6tXPTBKSsSY5Q0IBtLMIJk6tCJgmi3PCJgk30nIUu3Pe2PsOI qjlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OJgoXagcpdMGxdwGpA3W6np1Bh2j/I1vUBwlgJ+QTl8=; b=p/MJJY8RRWrCc3XsdO5Zl0gXaWQvlDXMygDm2XGHhPRTeVECszXc/0f6jM8Dk71yBH Ho0z9hPjUbXCkpn8sVax5a8C09b55iw/JZshLHslimQHi5bOmF5Vq/t1f0xo9APPg6Ta 1YYFv6eiRv3/Br+Axb4ftUFB0A+lppeSPOGK6TuvnD66HSjZw+MQ8NGeWZgG7YfA6qgl y87kW6dK4RZnoE2Jznh1rBfx2I7fJJcxjSwLjrFHQ0jfaS7PrH0z1QjPXOZGNtb0JPaF TJgXWgp4AdhdI9u86USI2QXjTlMgEA5DjNW3xP4xzU7pXvbPEo9I7AIjbCi9zYiFUhQX tAqw== X-Gm-Message-State: AOAM530kBTZdldIY61/uFzI+e8OBa/JPUPbL0H9EGlUMawWblFE83GMq wFdeIS4+iE1t/0nPXR8Q966JOBWdi6s+Z3NziHQ= X-Google-Smtp-Source: ABdhPJx6puic630DHcJlXPW7LTySxMCm1yQn4gpbT9B73nefbH3flyFj37/Y1af2Rg+qwJb1veIvm8XYz197tk88/gM= X-Received: by 2002:a5e:da05:: with SMTP id x5mr28235062ioj.25.1641488130816; Thu, 06 Jan 2022 08:55:30 -0800 (PST) MIME-Version: 1.0 References: <98CBD80474FA8B44BF855DF32C47DC35D86DB2@smartserver.smartshare.dk> <20220106122345.82740-1-mb@smartsharesystems.com> In-Reply-To: <20220106122345.82740-1-mb@smartsharesystems.com> From: Jerin Jacob Date: Thu, 6 Jan 2022 22:25:04 +0530 Message-ID: Subject: Re: [PATCH] mempool: optimize incomplete cache handling To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: Olivier Matz , Andrew Rybchenko , dpdk-dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 On Thu, Jan 6, 2022 at 5:54 PM Morten Br=C3=B8rup wrote: > > A flush threshold for the mempool cache was introduced in DPDK version > 1.3, but rte_mempool_do_generic_get() was not completely updated back > then. > > The incompleteness did not cause any functional bugs, so this patch > could be considered refactoring for the purpose of cleaning up. > > This patch completes the update of rte_mempool_do_generic_get() as > follows: > > 1. A few comments were malplaced or no longer correct. > Some comments have been updated/added/corrected. > > 2. The code that initially screens the cache request was not updated. > The initial screening compared the request length to the cache size, > which was correct before, but became irrelevant with the introduction of > the flush threshold. E.g. the cache can hold up to flushthresh objects, > which is more than its size, so some requests were not served from the > cache, even though they could be. > The initial screening has now been corrected to match the initial > screening in rte_mempool_do_generic_put(), which verifies that a cache > is present, and that the length of the request does not overflow the > memory allocated for the cache. > > 3. The code flow for satisfying the request from the cache was weird. > The likely code path where the objects are simply served from the cache > was treated as unlikely; now it is treated as likely. > And in the code path where the cache was backfilled first, numbers were > added and subtracted from the cache length; now this code path simply > sets the cache length to its final value. > > 4. The objects were returned in reverse order. > Returning the objects in reverse order is not necessary, so rte_memcpy() > is now used instead. Have you checked the performance with network workload? IMO, reverse order makes sense(LIFO vs FIFO). The LIFO makes the cache warm as the same buffers are reused frequently.