From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 1ED504297F;
	Tue, 18 Apr 2023 18:05:39 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id E3E5A410EF;
	Tue, 18 Apr 2023 18:05:38 +0200 (CEST)
Received: from smartserver.smartsharesystems.com
 (smartserver.smartsharesystems.com [77.243.40.215])
 by mails.dpdk.org (Postfix) with ESMTP id 09FDD410EA
 for <dev@dpdk.org>; Tue, 18 Apr 2023 18:05:37 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PATCH] mempool: optimize get objects with constant n
Date: Tue, 18 Apr 2023 18:05:36 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87893@smartserver.smartshare.dk>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [PATCH] mempool: optimize get objects with constant n
Thread-Index: Adlx5eNoMsrPQtOsSqGxW/FbimAxogAAGMbAAAo46cA=
References: <20230411064845.37713-1-mb@smartsharesystems.com>
 <ZD55wqJLvwt1Bq7r@bricha3-MOBL.ger.corp.intel.com> 
From: =?iso-8859-1?Q?Morten_Br=F8rup?= <mb@smartsharesystems.com>
To: "Bruce Richardson" <bruce.richardson@intel.com>
Cc: <olivier.matz@6wind.com>, <andrew.rybchenko@oktetlabs.ru>, <dev@dpdk.org>
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

> From: Morten Br=F8rup
> Sent: Tuesday, 18 April 2023 13.30
>=20
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Tuesday, 18 April 2023 13.07
> >
> > On Tue, Apr 11, 2023 at 08:48:45AM +0200, Morten Br=F8rup wrote:

[...]

> > > +		/*
> > > +		 * 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;
> > > +
> >
> > This loop looks a little awkward to me. Would it be clearer (and
> perhaps
> > easier for compilers to unroll efficiently if it was rewritten as:
> >
> > 	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
> index increments.
>=20
> Regardless, your point here is still valid! I expected that any
> unrolling capable compiler can unroll *dst++ =3D *--src; but I can
> experiment with different compilers on godbolt.org to see if =
dst[index]
> =3D src[-index] is better.

Just for the record... I have now tried experimenting with the =
alternative, and it makes no difference.