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 BB46742B6F; Mon, 22 May 2023 10:14:32 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 33A0F42D49; Mon, 22 May 2023 10:14:10 +0200 (CEST) Received: from MW2PR02CU001.outbound.protection.outlook.com (mail-westus2azon11012012.outbound.protection.outlook.com [52.101.48.12]) by mails.dpdk.org (Postfix) with ESMTP id E2B60410D1; Mon, 22 May 2023 07:12:27 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=chhVTgseqiQsl4absXD9NNnVtStyJGXqjIOWvQf/yXpuSEVoeRX/vHDgF5PMHAmysDzZYEMwcTMO4/R+QAZFyB0KYQkAo15maWPv4+Xtl2FrA+78l9GoLt3nWZ88OBp79sy3oGAs2gEvuoLpDdYaqh9PHN/YZLK/5J1y4KNxcz5sXxDD05JjyrbgtWvDClazkvUxrlRm9EBpM2aQmPCRYlhFixwtTrxhEtvu7iqijL2u6nXs/A7p4nDpvjBE5CZsCuRyFqDmpNoZ0KQRbONNpYEJI4tLoerVWg/cwSekl1DAL+EVBbWakcz9sAJV+IAgEN8fLElFyjFjAPkoEjG/iA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fvh2zAS2R7nPoqJ0uqF6+E68t8mWZ27T/8gDcDBLoNQ=; b=oW07x+FSclHEE8OgAbeDT37Ct4+7HxLMio78K1FEwhcRR97yjTdAzMhoSgWEJy5YHKDzsPPgKhCR74TS82PYAo+cTy5OFpVi4ol98lES6Y9YO4a9uOwnfhkJX/Vim/YjwU1gqOeSnpt84XeBEGw6AsgZ+0aVD0QV88fFOoY/o+H1gnDaOE3oRiGI9fFgcAotKdN7i0TFtFhDFUfp0eeTR2s+esk1ZqXdlSgpAmkkS42u4rcoiamB1FEsBXZdjkkGnTe1vsA/yFQ7uzTZTT7GEvozBdnWl41EV0s/duY991MMYyEJ8eqW4Oq88R8E9mdfzvqpgnKS0rUIaz9ALC764g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vmware.com; dmarc=pass action=none header.from=vmware.com; dkim=pass header.d=vmware.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmware.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fvh2zAS2R7nPoqJ0uqF6+E68t8mWZ27T/8gDcDBLoNQ=; b=awsggR0HaEoCfnLdNjQTU7LWJH1Mus4dXGKOvqq+WNXxW404RtPlWSRMP1x5AxPiqfgUfRs49VgM0bDmyZAIeP+KLXOqGU6c4EKDD3lH4UYW4NrD8VrnRdZ9tD+9mFcXY9SY5rTKuymsEIFadA/Gv7uSoG78BrNhGR0PR//TZWU= Received: from DM6PR05MB5577.namprd05.prod.outlook.com (2603:10b6:5:c::16) by DM6PR05MB5529.namprd05.prod.outlook.com (2603:10b6:5:5e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6411.27; Mon, 22 May 2023 05:12:25 +0000 Received: from DM6PR05MB5577.namprd05.prod.outlook.com ([fe80::8bba:172c:a1c4:a9fa]) by DM6PR05MB5577.namprd05.prod.outlook.com ([fe80::8bba:172c:a1c4:a9fa%4]) with mapi id 15.20.6411.028; Mon, 22 May 2023 05:12:25 +0000 From: Vipin P R To: "Burakov, Anatoly" CC: "dev@dpdk.org" , "stable@dpdk.org" Subject: Re: [PATCH 2/2] Memory Allocation: Alternative fix for ignore_msk during find_next_n() in fb_array library Thread-Topic: [PATCH 2/2] Memory Allocation: Alternative fix for ignore_msk during find_next_n() in fb_array library Thread-Index: AQHZinFutQGc1fd/tES3FpBF2grpd69lwvA7 Date: Mon, 22 May 2023 05:12:25 +0000 Message-ID: References: <1673615669-21011-1-git-send-email-vipinp@vmware.com> <1673615669-21011-3-git-send-email-vipinp@vmware.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=vmware.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM6PR05MB5577:EE_|DM6PR05MB5529:EE_ x-ms-office365-filtering-correlation-id: c479c6ad-0eda-4402-4347-08db5a832163 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: G24reTPN+E+3YkWHd6Ac9VlN7H7NW48BfaBKF7rR9w+v2D890wdpnk6afIPjLdG2hf+i95JhsBQxXLwY4p4T2eSUVpiptwhaiKJn4PqohbKDe2a7gLu4hSpJ6pKu4k01oqVohHHHZ6vNqklLTO5/i7gwc8rXYcPXlnOKx9NuFGDjK/NaIvpsJbpXcB4MRkuYTFwj50FMI9Sbpz3Czc5GrmQT/WEbFOpu/sFUuuX7nb3vnAzElMOJZHwLUmMqweMBfBK6aGi2IAVvMMyqhbq18+R87jtJxMTSkRrikEPcJEytgllTSjQ3C7Ti40IhjlUvQh7d+Ff2y/Jc57ynj327SaoILbIqtnKOtDB+MrQa7ELL+bvn6vicC4bO1Nv4hfQUXepz7BTvYyleXeZXUL9s6wonJdOFkQMa969F6sMLBT9jaNDT70q3+ebnGXVR/FjtSpmwA9uTVt2ug51/SbL9viSmuUnJ8rHMX6ALC53GHUgu5G39Z6onek3HToSHgKkRkAJZFk3elRNlJ1spT3xNyXJOIhJqgF9+AMIbtJCs8G+63xDEjulL+QdkymPlyHmBBT7Qp1sXpPg4NiQuDV9cfwPSI3ktI147SMKCrh4NKBXnDfvXneelI68pKALsoS59ZNHCTuQlpMoqs4li/+RkiGHFVrmAd02OQ7HxE7Tuk/c= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB5577.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(136003)(396003)(346002)(366004)(376002)(39860400002)(451199021)(53546011)(186003)(316002)(33656002)(86362001)(9686003)(6506007)(71200400001)(2906002)(8676002)(8936002)(55016003)(52536014)(5660300002)(41300700001)(7696005)(478600001)(19627405001)(54906003)(38100700002)(122000001)(66476007)(66446008)(64756008)(4326008)(6916009)(76116006)(91956017)(66946007)(66556008)(38070700005)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?xZ13cVxNoitF3Aq8vOMbh0VksxiK/GjP4pWVpVRZU4XD9nTEEilSdYHXJDdh?= =?us-ascii?Q?OZnGiFgUl9Hspp3SkQAsZ81GUlF8yqxLPWQqyUM6fB+ITDEYi5VPfMpsL7kI?= =?us-ascii?Q?YrkQuesWETKMiBbD0SQ5HRXKBgSBO0AFn6EKMa32sgHMiQBwSSoaBIlpIO2B?= =?us-ascii?Q?8GHbLqPTWq6ClYEDT6naqtyYY74lw2lpdgIx9Z0htPS37u0KXP3ngmAkJu2U?= =?us-ascii?Q?OFs/fa16FpXyRNq5yTo38DcLIw0Dq3kasAOVkXD27uTeh+pOPL6SutUf163A?= =?us-ascii?Q?fjTMRTYOeS7mrRYnZWvVTCd1NrCJWNOr0TBOGZWg638/v843OqqwPO8O+NgN?= =?us-ascii?Q?FdPWxqH/CogwFwh158Z3HW0xBHL14vcfmdfL2/RFrfw/iXL7qS9c656CQSz2?= =?us-ascii?Q?Qc6aklErsgHzXDpZlvWos00FAB7aKEWcpKA9HXg1DkX7rdz9dOeWXNrFvFzo?= =?us-ascii?Q?kf+syCgNUqyQEbn+bZktSRgpH7FgH9JkVKI/0dTfxfpIHNk7GGQ8H+RlG1yv?= =?us-ascii?Q?lUL5pCayTOqepIZxE4v4SVvwBgAKJqHdA94SP8QNOseIadGt6bB4QiOwUyMw?= =?us-ascii?Q?h072CKUN8Mq13G+5UerEKD4Y9eVR6CdR3GJ1fiwebNauX4PJNzxBelcy2kIC?= =?us-ascii?Q?Be0TqfQjKPaHVYCMNlUv0rzglLhgYBMGbyfW3iHrRCaTprula2OguKQoaATz?= =?us-ascii?Q?LRCZiO7zwWq8c204BaVXQz/0sb7Sj3uFUDHq5VovXRH2vc/d/njUudiaa8jA?= =?us-ascii?Q?SInvePdEsuSqzOZcs3jyMbMkY6pGmh924N3T+3JItQU4tey7hyzLshTSOWGU?= =?us-ascii?Q?wwQFWMwFqwcUBRlUet+XDjqHMMAoQTJtiLmLprx8w1tAAI9SlhqNvlsOHDNf?= =?us-ascii?Q?2EZATrbd1e6c7nDp7cT8CE0hQMPT+Cxd5fYmVs2myWk+MUuy6vIhlRAQ7Ljz?= =?us-ascii?Q?C1LbuGETsfK2ZTR4TqGiVQ3nVtzLWBJM2jNZbuwJNM9s3w4ShTzLfcWDVuHz?= =?us-ascii?Q?Suc6DsClqlcRKyeVPfXk9RUYLLdm8NkBeo+RATwOOJ/dNtL3iBfynCzHFifE?= =?us-ascii?Q?IQ2VUqutswA/QZw70csY4rkDUUA3VqoseeWLFwts7mrsI6o8iOmecFSFbN2w?= =?us-ascii?Q?hfHsaCKnaqWO2wAHP9gZOszyHtGmPO/WSeyXGpHalI86gmuZqJ455VzMppey?= =?us-ascii?Q?nhHnYovn4LjePzqJoeZi1m5M+FJw7qYMz/bB0gIE5bZZZ0xG7NgoinqMqE/9?= =?us-ascii?Q?nRLBgm8ey3/7LDal/8l/NDW/LBGkpgIFvAm2+ibX0R0MxCmm7gLWZ6rhCswv?= =?us-ascii?Q?g8qbmkgrrQQi3vdDUo8x7DT/L3zP9IALbqHwF7KI43aG/H0bX++LBhQALiCe?= =?us-ascii?Q?gir7lbhoOIB+oYBVizwHXKmqvj5PhH0OZb9zJo4DG4bfVtieb/A62nUNtRZ/?= =?us-ascii?Q?Ct5js3skzfPhWdDNNJ3IIJWZJpdEsG/9Tux64eJ2U0eX1EnT/3n4XgkvThlv?= =?us-ascii?Q?pkREPAKCSaIP9HJmzEYVQ2z88tLn6/v9gDNd0nzcy1Bi2k1D1iCisFz7T6aR?= =?us-ascii?Q?DQuYeCwr3wRSlG+YlG4glKjGDZFez8rNDzvRfXJokfbFHhf6r5GZDMpiOI5a?= =?us-ascii?Q?ppQsYONnVd2dcpGTm5GqaMs=3D?= Content-Type: multipart/alternative; boundary="_000_DM6PR05MB55776BA803AFD71F6F1A1554B7439DM6PR05MB5577namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB5577.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c479c6ad-0eda-4402-4347-08db5a832163 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2023 05:12:25.0252 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ctCHskzD5CQXojlWgSqvjpFCp1zdocyA4Pkim5vqTihcybxjtxsgu/PObqtmC/Yl4HciN6XqLakXTUBMPMRY6g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5529 X-Mailman-Approved-At: Mon, 22 May 2023 10:14:02 +0200 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 --_000_DM6PR05MB55776BA803AFD71F6F1A1554B7439DM6PR05MB5577namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Burakov, sure, will amend the changeset. currently I'm travelling, will get back by = the end of this week if that's ok. ________________________________ From: Burakov, Anatoly Sent: 19 May 2023 22:15 To: Vipin P R Cc: dev@dpdk.org ; stable@dpdk.org Subject: Re: [PATCH 2/2] Memory Allocation: Alternative fix for ignore_msk = during find_next_n() in fb_array library !! External Email Hi, This is technically not a bug fix but an improvement to the lookahead algorithm, so I don't think this needs a Fixes: tag or a Cc to stable. On 1/13/2023 1:14 PM, Vipin P R wrote: > Ignore mask ignores essential bits WHICH could have been contiguous. > This commit aims to rectify that > Suggested rewording: fbarray: improve lookahead ignore mask handling Currently, when lookahead mask does not have its first bit set but has other bits set, we do not set any ignore masks to avoid potentially ignoring useful bits. We can still ignore some bits, because we can rely on the fact that we're looking for `need` bits, and lookahead mask does give us information about whether there are other potential places we can start looking for runs in the next iteration. Address this by ignoring least significant clear bits in our lookahead mask on next iteration. > Cc: stable@dpdk.org > > Signed-off-by: Vipin P R > Acked-by: Kumara Parameshwaran > --- > Depends-on: 0001-Memory-Allocation-Fixes-ms_idx-jump-lookahead-during.pat= ch > Depends-on: 0002-Memory-Allocation-Fixes-ms_idx-jump-lookbehind-durin.pat= ch > --- > lib/eal/common/eal_common_fbarray.c | 21 ++++++++++++++++++--- > 1 file changed, 18 insertions(+), 3 deletions(-) > > diff --git a/lib/eal/common/eal_common_fbarray.c b/lib/eal/common/eal_com= mon_fbarray.c > index 313681a..29fffb6 100644 > --- a/lib/eal/common/eal_common_fbarray.c > +++ b/lib/eal/common/eal_common_fbarray.c > @@ -138,7 +138,7 @@ find_next_n(const struct rte_fbarray *arr, unsigned i= nt start, unsigned int n, > last_msk =3D ~(UINT64_MAX << last_mod); > > for (msk_idx =3D first; msk_idx < msk->n_masks; msk_idx++) { > - uint64_t cur_msk, lookahead_msk; > + uint64_t cur_msk, lookahead_msk, lookahead_msk_; `lookahead_msk_` doesn't need to be in the outer loop, IMO it can be moved inside the lookahead code. Also, `lookahead_msk_` is not a very informative name. Maybe change it to `lookahead_old` or similar? > unsigned int run_start, clz, left; > bool found =3D false; > /* > @@ -215,12 +215,14 @@ find_next_n(const struct rte_fbarray *arr, unsigned= int start, unsigned int n, > > for (lookahead_idx =3D msk_idx + 1; lookahead_idx < msk->n_= masks; > lookahead_idx++) { > - unsigned int s_idx, need; > + unsigned int s_idx, need, fsb_idx, fcb_idx, ignore_= bits; > lookahead_msk =3D msk->data[lookahead_idx]; > > /* if we're looking for free space, invert the mask= */ > if (!used) > lookahead_msk =3D ~lookahead_msk; > + > + lookahead_msk_ =3D lookahead_msk; > > /* figure out how many consecutive bits we need her= e */ > need =3D RTE_MIN(left, MASK_ALIGN); > @@ -236,10 +238,23 @@ find_next_n(const struct rte_fbarray *arr, unsigned= int start, unsigned int n, > * as well, so skip that on next iteration. > */ > if (!lookahead_msk) { > - /* There aren't "need" number of co= ntiguous bits anywhere in the mask. > + /* There aren't "need" number of co= ntiguous bits anywhere in the mask. > * Ignore these many number of bits= from LSB for the next iteration. > */ > ignore_msk =3D ~((1ULL << need) - 1= ); > + } else { > + /* Find the first clear bit */ > + fcb_idx =3D __builtin_ffsll((~looka= head_msk_)); > + /* clear all bits upto the first cl= ear bit in lookahead_msk_. */ > + lookahead_msk_ =3D lookahead_msk_ &= ((~0ULL) << fcb_idx); > + /* find the first set bit in the mo= dified mask */ > + fsb_idx =3D __builtin_ffsll(lookahe= ad_msk_); > + /* number of bits to ignore from th= e next iteration */ > + ignore_bits =3D fsb_idx - 1; > + /* ignore all bits preceding the fi= rst set bit after the first clear bit > + * starting from LSB of lookahead_m= sk_. > + */ > + ignore_msk =3D ~((1ULL << ignore_bi= ts) - 1); > } I don't quite understand what's happening here. Or rather, I kind of do, but I don't understand why we don't just 1) find first set bit in lookahead mask, and 2) ignore all preceding bits? E.g. something like: /* find first set bit */ fsb_idx =3D __builtin_ffsll(lookahead_msk); /* ignore all preceding bits */ ignore_msk =3D ~((1ULL << fsb_idx) - 1); would be much simpler and achieve the same result, would it not? > msk_idx =3D lookahead_idx - 1; > break; -- Thanks, Anatoly !! External Email: This email originated from outside of the organization. = Do not click links or open attachments unless you recognize the sender. --_000_DM6PR05MB55776BA803AFD71F6F1A1554B7439DM6PR05MB5577namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Burakov,

sure, will amend the changeset. currently I'm travelling, will get back by = the end of this week if that's ok.
From: Burakov, Anatoly <= anatoly.burakov@intel.com>
Sent: 19 May 2023 22:15
To: Vipin P R <vipinp@vmware.com>
Cc: dev@dpdk.org <dev@dpdk.org>; stable@dpdk.org <stable@dp= dk.org>
Subject: Re: [PATCH 2/2] Memory Allocation: Alternative fix for igno= re_msk during find_next_n() in fb_array library
 
!! External Email

Hi,

This is technically not a bug fix but an improvement to the lookahead
algorithm, so I don't think this needs a Fixes: tag or a Cc to stable.

On 1/13/2023 1:14 PM, Vipin P R wrote:
> Ignore mask ignores essential bits WHICH could have been contiguous. > This commit aims to rectify that
>

Suggested rewording:

fbarray: improve lookahead ignore mask handling

Currently, when lookahead mask does not have its first bit set but has
other bits set, we do not set any ignore masks to avoid potentially
ignoring useful bits.

We can still ignore some bits, because we can rely on the fact that
we're looking for `need` bits, and lookahead mask does give us
information about whether there are other potential places we can start
looking for runs in the next iteration.

Address this by ignoring least significant clear bits in our lookahead
mask on next iteration.

> Cc: stable@dpdk.org
>
> Signed-off-by: Vipin P R <vipinp@vmware.com>
> Acked-by: Kumara Parameshwaran <kparameshwar@vmware.com>
> ---
> Depends-on: 0001-Memory-Allocation-Fixes-ms_idx-jump-lookahead-during.= patch
> Depends-on: 0002-Memory-Allocation-Fixes-ms_idx-jump-lookbehind-durin.= patch
> ---
>   lib/eal/common/eal_common_fbarray.c | 21 +++++++++++++++++= +---
>   1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/lib/eal/common/eal_common_fbarray.c b/lib/eal/common/eal_= common_fbarray.c
> index 313681a..29fffb6 100644
> --- a/lib/eal/common/eal_common_fbarray.c
> +++ b/lib/eal/common/eal_common_fbarray.c
> @@ -138,7 +138,7 @@ find_next_n(const struct rte_fbarray *arr, unsigne= d int start, unsigned int n,
>       last_msk =3D ~(UINT64_MAX <<= last_mod);
>
>       for (msk_idx =3D first; msk_idx &l= t; msk->n_masks; msk_idx++) {
> -           &nb= sp; uint64_t cur_msk, lookahead_msk;
> +           &nb= sp; uint64_t cur_msk, lookahead_msk, lookahead_msk_;

`lookahead_msk_` doesn't need to be in the outer loop, IMO it can be
moved inside the lookahead code. Also, `lookahead_msk_` is not a very
informative name. Maybe change it to `lookahead_old` or similar?

>            = ;   unsigned int run_start, clz, left;
>            = ;   bool found =3D false;
>            = ;   /*
> @@ -215,12 +215,14 @@ find_next_n(const struct rte_fbarray *arr, unsig= ned int start, unsigned int n,
>
>            = ;   for (lookahead_idx =3D msk_idx + 1; lookahead_idx < msk-&g= t;n_masks;
>            = ;            &n= bsp;      lookahead_idx++) {
> -           &nb= sp;         unsigned int s_idx, nee= d;
> +           &nb= sp;         unsigned int s_idx, nee= d, fsb_idx, fcb_idx, ignore_bits;
>            = ;           lookahead_msk= =3D msk->data[lookahead_idx];
>
>            = ;           /* if we're l= ooking for free space, invert the mask */
>            = ;           if (!used) >            = ;            &n= bsp;      lookahead_msk =3D ~lookahead_msk;
> +
> +           &nb= sp;         lookahead_msk_ =3D look= ahead_msk;
>
>            = ;           /* figure out= how many consecutive bits we need here */
>            = ;           need =3D RTE_= MIN(left, MASK_ALIGN);
> @@ -236,10 +238,23 @@ find_next_n(const struct rte_fbarray *arr, unsig= ned int start, unsigned int n,
>            = ;            &n= bsp;       * as well, so skip that on next it= eration.
>            = ;            &n= bsp;       */
>            = ;            &n= bsp;      if (!lookahead_msk) {
> -           &nb= sp;            =              /*= There aren't "need" number of contiguous bits anywhere in the ma= sk.
> +           &nb= sp;            =              /*= There aren't "need" number of contiguous bits anywhere in the ma= sk.
>            = ;            &n= bsp;            = ;   * Ignore these many number of bits from LSB for the next iter= ation.
>            = ;            &n= bsp;            = ;   */
>            = ;            &n= bsp;            = ;  ignore_msk =3D ~((1ULL << need) - 1);
> +           &nb= sp;            =      } else {
> +           &nb= sp;            =              /*= Find the first clear bit */
> +           &nb= sp;            =              fc= b_idx =3D __builtin_ffsll((~lookahead_msk_));
> +           &nb= sp;            =              /*= clear all bits upto the first clear bit in lookahead_msk_. */
> +           &nb= sp;            =              lo= okahead_msk_ =3D lookahead_msk_ & ((~0ULL) << fcb_idx);
> +           &nb= sp;            =              /*= find the first set bit in the modified mask */
> +           &nb= sp;            =              fs= b_idx =3D __builtin_ffsll(lookahead_msk_);
> +           &nb= sp;            =              /*= number of bits to ignore from the next iteration */
> +           &nb= sp;            =              ig= nore_bits =3D fsb_idx - 1;
> +           &nb= sp;            =              /*= ignore all bits preceding the first set bit after the first clear bit
> +           &nb= sp;            =             &nb= sp; * starting from LSB of lookahead_msk_.
> +           &nb= sp;            =             &nb= sp; */
> +           &nb= sp;            =              ig= nore_msk =3D ~((1ULL << ignore_bits) - 1);
>            = ;            &n= bsp;      }

I don't quite understand what's happening here. Or rather, I kind of do, but I don't understand why we don't just 1) find first set bit in
lookahead mask, and 2) ignore all preceding bits?

E.g. something like:

/* find first set bit */
fsb_idx =3D __builtin_ffsll(lookahead_msk);
/* ignore all preceding bits */
ignore_msk =3D ~((1ULL << fsb_idx) - 1);

would be much simpler and achieve the same result, would it not?

>            = ;            &n= bsp;      msk_idx =3D lookahead_idx - 1;
>            = ;            &n= bsp;      break;

--
Thanks,
Anatoly


!! External Email: This email originated from outside of the organization. = Do not click links or open attachments unless you recognize the sender.
--_000_DM6PR05MB55776BA803AFD71F6F1A1554B7439DM6PR05MB5577namp_--