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 8B2D142C4A; Wed, 7 Jun 2023 09:51:42 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 64EAF40A84; Wed, 7 Jun 2023 09:51:42 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 8653640695 for ; Wed, 7 Jun 2023 09:51:41 +0200 (CEST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C34075C013F; Wed, 7 Jun 2023 03:51:40 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 07 Jun 2023 03:51:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1686124300; x=1686210700; bh=497a6gRGgL1GLevwZtLtwmR4znzBKGUY8yB Yt+AuQnY=; b=Pw76iXaKaQ6C/HbWu1gRW4s9dJ+RfnGGIEu0AimV+/oUPlqqezx T67hr+G3o60RKH0B1d2YT1mhECf3XCZV8xiCI4/RC0ALFqUvBygnV2m2NHnwWYey 4g2pZoHKPFD/BY714o3+chgdzDUgR41LlexaizgfQ155FAl5xEuOID4gIG5L+W/C 7937/AzJYFK3FHoASnoYPriOPV6ldsQ2LtZtHUPlaWCEKP9UniFbifzgXUVJipFk kG69sjGKiMFDghQ6FITMQrr+GKPogL0jjSRk2x6eZBwCKbKe7VvSJB2kn2HGLCKZ 88PJ2/XhTm2Bgm/cBknITSORDXotbp80cuw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1686124300; x=1686210700; bh=497a6gRGgL1GLevwZtLtwmR4znzBKGUY8yB Yt+AuQnY=; b=TJj1QfCHk+6Dfo5FCFsfdnCjsf2btqtD8AGegWwu5X/fDil2nCV oceYDpeAGgo4n/mp1T+1KtJ511WsfE4Vcww8yQxGlX2YXIILji5BB2pKhzVCBQqa XYCqHplbuWQBVxZchX6xMGoGr2bjVK/l9wUbP4QJyf5VjVFv2V5tnRj488ode5bR tvwX9jDCYU7fiDFKgLxda/rU3+GZpWaIAFysd2PDaMq1zhAxEEb6fzvRxglgMwhX Ejog0EV5+F14Y9yzCOAMuGL65b74y0ZcFpLPytiXxScFsSYz0pSe3P6f9eZcbfKi vB02AVQTufrxb59bKEg7czQqYEntStEXTiA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedtfedgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtudenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeefhfejleeuvdevtddutdeutdevhfeijeethfffueejhfetuddu vedtkedtieekffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 7 Jun 2023 03:51:39 -0400 (EDT) From: Thomas Monjalon To: Morten =?ISO-8859-1?Q?Br=F8rup?= Cc: dev@dpdk.org, olivier.matz@6wind.com, andrew.rybchenko@oktetlabs.ru, Bruce Richardson Subject: Re: [PATCH] mempool: optimize get objects with constant n Date: Wed, 07 Jun 2023 09:51:37 +0200 Message-ID: <1739067.KUTt5R2Mg1@thomas> In-Reply-To: References: <20230411064845.37713-1-mb@smartsharesystems.com> <98CBD80474FA8B44BF855DF32C47DC35D8788D@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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 18/04/2023 14:55, Bruce Richardson: > On Tue, Apr 18, 2023 at 01:29:49PM +0200, Morten Br=F8rup wrote: > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > On Tue, Apr 11, 2023 at 08:48:45AM +0200, Morten Br=F8rup wrote: > > > > + if (__extension__(__builtin_constant_p(n)) && n <=3D cache->len) { > > > > + /* > > > > + * The request size is known at build time, and > > > > + * the entire request can be satisfied from the cache, > > > > + * so let the compiler unroll the fixed length copy loop. > > > > + */ > > > > + cache->len -=3D n; > > > > + for (index =3D 0; index < n; index++) > > > > + *obj_table++ =3D *--cache_objs; > > > > + > > >=20 > > > This loop looks a little awkward to me. Would it be clearer (and perh= aps > > > easier for compilers to unroll efficiently if it was rewritten as: > > >=20 > > > cache->len -=3D n; > > > cache_objs =3D &cache->objs[cache->len]; > > > for (index =3D 0; index < n; index++) > > > obj_table[index] =3D cache_objs[index]; > >=20 > > The mempool cache is a stack, so the copy loop needs get the objects in= decrementing order. I.e. the source index decrements and the destination i= ndex increments. > >=20 >=20 > BTW: Please add this as a comment in the code too, above the loop to avoid > future developers (or even future me), asking this question again! Looks like this request was missed.