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 356EEA00C2; Wed, 2 Nov 2022 18:55:40 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BF0FA40694; Wed, 2 Nov 2022 18:55:39 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 6BF5940693 for ; Wed, 2 Nov 2022 18:55:38 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 2EA925184 for ; Wed, 2 Nov 2022 18:55:38 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 2D7FE4CBD; Wed, 2 Nov 2022 18:55:38 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A autolearn=disabled version=3.4.6 X-Spam-Score: -1.5 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 9DBEA4CBC; Wed, 2 Nov 2022 18:55:37 +0100 (CET) Message-ID: <05b0591e-5c88-55bd-e9ad-766f8a860d97@lysator.liu.se> Date: Wed, 2 Nov 2022 18:55:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v2 3/3] mempool: use cache for frequently updated statistics Content-Language: en-US To: =?UTF-8?Q?Morten_Br=c3=b8rup?= , olivier.matz@6wind.com, andrew.rybchenko@oktetlabs.ru, stephen@networkplumber.org, jerinj@marvell.com, bruce.richardson@intel.com, thomas@monjalon.net Cc: dev@dpdk.org References: <20221030115445.2115-1-mb@smartsharesystems.com> <20221031112634.18329-1-mb@smartsharesystems.com> <20221031112634.18329-3-mb@smartsharesystems.com> <5850fa4f-dbc5-b2a6-5927-23adf8ba209f@lysator.liu.se> <98CBD80474FA8B44BF855DF32C47DC35D87474@smartserver.smartshare.dk> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87474@smartserver.smartshare.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 2022-11-02 10:29, Morten Brørup wrote: >> From: Mattias Rönnblom [mailto:hofors@lysator.liu.se] >> Sent: Wednesday, 2 November 2022 09.01 >> >> On 2022-10-31 12:26, Morten Brørup wrote: > > [...] > >>> +++ b/lib/mempool/rte_mempool.h >>> @@ -86,6 +86,21 @@ struct rte_mempool_cache { >>> uint32_t size; /**< Size of the cache */ >>> uint32_t flushthresh; /**< Threshold before we flush excess >> elements */ >>> uint32_t len; /**< Current cache count */ >>> + uint32_t unused0; >>> +#ifdef RTE_LIBRTE_MEMPOOL_STATS >>> + /* >>> + * Alternative location for the most frequently updated mempool >> statistics (per-lcore), >>> + * providing faster update access when using a mempool cache. >>> + */ >>> + struct { >>> + uint64_t put_bulk; /**< Number of puts. */ >>> + uint64_t put_objs; /**< Number of objects >> successfully put. */ >>> + uint64_t get_success_bulk; /**< Successful allocation >> number. */ >>> + uint64_t get_success_objs; /**< Objects successfully >> allocated. */ >>> + } stats; /**< Statistics */ >>> +#else >>> + uint64_t unused1[4]; >> >> Are a particular DPDK version supposed to be ABI compatible with >> itself, >> with different configuration options? E.g., with and without >> RTE_LIBRTE_MEMPOOL_STATS. Is that why you have those 4 unused >> uint64_ts? > > Valid point: There was no ABI compatibility between with and without RTE_LIBRTE_MEMPOOL_STATS before this patch, so there is no need to add partial ABI compatibility here. > > The #else part of this structure should be removed. > > Does anyone disagree? > >>> +#endif > I have no opinion on that matter, but I have another question: if you remove 'unused1', should you also remove the unused0 field?