From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 80005A0350;
	Mon, 11 May 2020 11:46:36 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id C14421C1F4;
	Mon, 11 May 2020 11:46:35 +0200 (CEST)
Received: from mga06.intel.com (mga06.intel.com [134.134.136.31])
 by dpdk.org (Postfix) with ESMTP id 1F9B81C1E5
 for <dev@dpdk.org>; Mon, 11 May 2020 11:46:32 +0200 (CEST)
IronPort-SDR: pS2ZyBQAYYWb7hq4ENV2iQroRsUzPUYSLNTbQ/2jdYI07O2n9LomzUg2L6xHW0jeiYGpajKk5t
 HF+AydfOPevw==
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga007.jf.intel.com ([10.7.209.58])
 by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 11 May 2020 02:46:31 -0700
IronPort-SDR: ufnq4pIpt4DBBPBgdG23rQn3c3mSkXC0Sq3bFaEbb8rh4nKakQ4hb4/j/yd1UscoThFbwPiKjm
 gGrd0eGX/yIQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.73,379,1583222400"; d="scan'208";a="250497198"
Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206])
 by orsmga007.jf.intel.com with ESMTP; 11 May 2020 02:46:31 -0700
Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by
 FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS)
 id 14.3.439.0; Mon, 11 May 2020 02:46:31 -0700
Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by
 FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS)
 id 14.3.439.0; Mon, 11 May 2020 02:46:30 -0700
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.101)
 by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id
 14.3.439.0; Mon, 11 May 2020 02:46:29 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=ce9c54h25SfAuglrpiiA9eR186TJgL1zu+pKCrV9P/9zaBI66QUZvhx7xJ+tj07ixoUdcaVmoNwrp21OVqopOT9vcFA+ZrzForpzWy/vLOVjY8XZMDARm8BVNIpGWYW298/aBGuV4Zid1Zj6G2ur3mOz6cNxZJE8Wx8dXFjAYaudKSNtGAeCyK1BOOqVne3FG+j1itLngXf3LotS4XqtQOrhiyLi3eLsQnXbdiHcssmVWX23TjfOP2SC/Zwxw2PF7kvAdV82L+dXF6JULa/Fb/QFWVTnybb4qtHMPSEc5eTctVTPI7vEvlJTo7da67xytGXlzAylNQVYNxtP5aNg9g==
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-SenderADCheck;
 bh=xLkec5XXIVnTd3gLjPIZYGoVfLH1TgsWHC7vamKmhpM=;
 b=QjnzKNeY4TzOAlrxk3gEa97vfK5gdHGUrRnP4i2QyHxsvFyMaKI1DnxWs0qrlV9xuc0ElWuzJv6hw9UeF6q/Zmx/wcyJEa7f0j0Pboj49eeN01S53t3sk/BppoC6U5j4JQc3U1BHjY9+WVZExOcTltg7L6Tnc3Y8zN+8o0UkQMp/LASq35zSDj+GhgOW2kkwSJtnyDww7ebHIaM3R4Ky6zc+8wpg0b1kFSCpCbZzZkhcBeHqPqWxA7oUoBrtSPgAHXjJoULduDu+0dMoOTB7HUXmfL+1sp8XYXGcap0t+kenXEPxF7VtJsBkP2zHq70UVCeQPudKs/wicd6aMlAi3Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;
 dkim=pass header.d=intel.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; 
 s=selector2-intel-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xLkec5XXIVnTd3gLjPIZYGoVfLH1TgsWHC7vamKmhpM=;
 b=TKnAmzVDUTRj2tbf8WTXiTIkXQooZHJn5S88Pc1GatBn2T/NyCI4HGTM5mzAzxky8X2O1SC7hKQppMMAnpNiQQLbuisX8PV3hxECdxwVaX+X9TxE7VkeoyDLPK95ySIz4/UslIhLVUDSmFo6U/2XSKCprbeAf7vEraEzug0ieWo=
Received: from BYAPR11MB3301.namprd11.prod.outlook.com (2603:10b6:a03:7f::26)
 by BYAPR11MB3365.namprd11.prod.outlook.com (2603:10b6:a03:7e::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.34; Mon, 11 May
 2020 09:46:23 +0000
Received: from BYAPR11MB3301.namprd11.prod.outlook.com
 ([fe80::f8cb:58cd:e958:fff4]) by BYAPR11MB3301.namprd11.prod.outlook.com
 ([fe80::f8cb:58cd:e958:fff4%6]) with mapi id 15.20.2979.033; Mon, 11 May 2020
 09:46:23 +0000
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>, "Jerin Jacob
 Kollanukkaran" <jerinj@marvell.com>, "thomas@monjalon.net"
 <thomas@monjalon.net>, "Wang, Yipeng1" <yipeng1.wang@intel.com>, "Gobriel,
 Sameh" <sameh.gobriel@intel.com>, "Richardson, Bruce"
 <bruce.richardson@intel.com>, Ruifeng Wang <ruifeng.wang@arm.com>
CC: "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [dpdk-dev]  [RFC] hash: unify crc32 API header for x86 and ARM
Thread-Index: AQHWHlDpPeIPCcs0i0ui77Z53FWYRaieMNWwgAPOQICAALYOIA==
Date: Mon, 11 May 2020 09:46:23 +0000
Message-ID: <BYAPR11MB3301F33F0AE517A687A1496D9AA10@BYAPR11MB3301.namprd11.prod.outlook.com>
References: <20200429180515.5704-1-pbhagavatula@marvell.com>
 <BYAPR11MB3301068EFA50ACA315A20A709AA20@BYAPR11MB3301.namprd11.prod.outlook.com>
 <BYAPR18MB2518F63F062EB5D02362457DDEA00@BYAPR18MB2518.namprd18.prod.outlook.com>
In-Reply-To: <BYAPR18MB2518F63F062EB5D02362457DDEA00@BYAPR18MB2518.namprd18.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-reaction: no-action
dlp-version: 11.2.0.6
authentication-results: marvell.com; dkim=none (message not signed)
 header.d=none;marvell.com; dmarc=none action=none header.from=intel.com;
x-originating-ip: [192.198.151.178]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 937f6e7b-4c87-4086-4a53-08d7f5902a79
x-ms-traffictypediagnostic: BYAPR11MB3365:
x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB3365E5FDC0A8FA5113D2AAE29AA10@BYAPR11MB3365.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 04004D94E2
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: tFb8mPEg4S2tVP4iS5vCOoQ7rVtzCaAu51pa5J/nHnp3I3RltkAUwDt43GSPKe3yygTb0cLS+iL+ycmrWnDu7IAwwckK+x4CjfOBpt+C5yx7HtMVtRWTTBM7Z7dBoTxokrU5LwmgCagWYYKQHysnHN+bvPge+EhCVv0LBF3bpDIa3yI1Qz+V3o9Z81tDGvVvLLa6vVmIMXIPi22Ip5KS6nAnxSbJJKwh0W3/nmhmkaMCkS4O6se5KTE7RjYAsMPh/mJg6jQuorZn9XEhSAsyosFoeF9PMMX8U2OFFuCXmzGmRknhy1a0XY9ZLWn/HJexXcm8IZogE0lX4fX3XRmfrIqg9b/GI81RwIXelg7GwtJZYCCcb7R8tsJhbMNn5iYMh/aHfyBaJ8egFqdEGVlID64dHVxDdOIsGfHbIExeAX4HS34MeBOYF+e5JYX2xjHkr6fU4jATsDPwOj3BBKOBW4oStegpka2DHPvttPRDyfch4FG6bm5H12hy6EiC00uh1lvRkomKCcnlakaiKmD/Fbpgs2dICKqhzRVpueErHZY=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:BYAPR11MB3301.namprd11.prod.outlook.com; PTR:; CAT:NONE;
 SFTY:;
 SFS:(396003)(346002)(39860400002)(366004)(376002)(136003)(33430700001)(186003)(9686003)(71200400001)(4326008)(5660300002)(76116006)(66946007)(66446008)(64756008)(66476007)(66556008)(52536014)(55016002)(86362001)(8676002)(2906002)(6506007)(7696005)(33656002)(33440700001)(478600001)(110136005)(8936002)(316002)(26005)(921003);
 DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: G7mXgpiwqt3bJrcOh4ITvVT0IrknvN2LOLD8wh/eHmx5eIdzuMkFHg3PkQRBxGTzw8hBlZW6fCJmQFCnTBmsvGZUg/LGOpCf3Ss6Cgw6/GZnu6p9AkoL0p5pITC4dqomIpt+dg+Y+e7HAx6nGP9BiALwtYqP8FyeErWBw5G6sYPfToXQqW7Nob1Vk+9LQcq9AtirYOIgHFwrzsZn5nQVvcuErB0fmo9u+BKe42PAYFOGC0zHeBh2t9N3DIgppvNASiIy1MqH6ugcYpS3G+UU9xwz7saMjxsfhHdUj52jycC9obsJcrLKZpIdAp3GExATfQgRB9hwKZTJ20RravxZBo1LebPOgHx24CdFvw3KeKWmSu+DSEMAdChjYxV/PZzPSzRIjPK0MNfSHRIqYTQycnjwpTbHm7J9YgWUFi6i9RYUObcj+RURCrzEtEMv23mIxHHE8FiLO8M410aSgzlhMVgQkNkMyfAkMm+uZ+jZvX/Z5v1OLyRg1xoXA3U4yfJ8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 937f6e7b-4c87-4086-4a53-08d7f5902a79
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2020 09:46:23.1023 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2N2MDNyEg/qkS6XBdGDP/Lz0BzBxDzdJXt7b+yM+EorLN6to8qRc7tRznpltn55LVSwwrDBMqYPXag8euBcb6MNiEwpTuzVQAhN6QQdqstA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3365
X-OriginatorOrg: intel.com
Subject: Re: [dpdk-dev] [RFC] hash: unify crc32 API header for x86 and ARM
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
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
Sender: "dev" <dev-bounces@dpdk.org>

> >> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >>
> >> Merge crc32 hash calculation public API headers for x86 and ARM,
> >> split implementations of x86 and ARM into their respective private
> >> headers.
> >> This reduces the ifdef code clutter while keeping current ABI intact.
> >>
> >> Although we install `rte_crc_arm64.h` it is not used in any of the lib=
 or
> >> drivers layers. All the libs and drivers use `rte_hash_crc.h` which fa=
lls
> >> back to SW crc32 calculation for ARM platform.
> >>
> >> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >> ---
> >>
> >>  Currently, if application incorrectly sets CRC32_ARM64 as crc32
> >algorithm
> >>  through `rte_hash_crc_set_alg()` on x86 or vice-versa we fallback to
> >algorithm
> >>  set previously via `rte_hash_crc_set_alg()` instead of setting the be=
st
> >>  available.
> >>  This behaviour should probably change to setting the best available
> >algorithm
> >>  and is up for discussion.
> >>
> >>  app/test/test_hash.c            |   6 +
> >>  lib/librte_hash/Makefile        |   5 -
> >>  lib/librte_hash/crc_arm64.h     |  67 +++++++++++
> >>  lib/librte_hash/crc_x86.h       |  68 +++++++++++
> >>  lib/librte_hash/meson.build     |   3 +-
> >>  lib/librte_hash/rte_crc_arm64.h | 183 ------------------------------
> >>  lib/librte_hash/rte_hash_crc.h  | 193 +++++++++++++------------------
> >-
> >>  7 files changed, 219 insertions(+), 306 deletions(-)
> >>  create mode 100644 lib/librte_hash/crc_arm64.h
> >>  create mode 100644 lib/librte_hash/crc_x86.h
> >>  delete mode 100644 lib/librte_hash/rte_crc_arm64.h
> >>
> >> diff --git a/app/test/test_hash.c b/app/test/test_hash.c
> >> index afa3a1a3c..7bd457dac 100644
> >> --- a/app/test/test_hash.c
> >> +++ b/app/test/test_hash.c
> >> @@ -195,7 +195,13 @@ test_crc32_hash_alg_equiv(void)
> >>  	}
> >>
> >>  	/* Resetting to best available algorithm */
> >> +#if defined RTE_ARCH_X86
> >>  	rte_hash_crc_set_alg(CRC32_SSE42_x64);
> >> +#elif defined RTE_ARCH_ARM64
> >> +	rte_hash_crc_set_alg(CRC32_ARM64);
> >> +#else
> >> +	rte_hash_crc_set_alg(CRC32_SW);
> >> +#endif
> >>
> >>  	if (i =3D=3D CRC32_ITERATIONS)
> >>  		return 0;
> >> diff --git a/lib/librte_hash/Makefile b/lib/librte_hash/Makefile
> >> index ec9f86499..f640afc42 100644
> >> --- a/lib/librte_hash/Makefile
> >> +++ b/lib/librte_hash/Makefile
> >> @@ -19,11 +19,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_HASH) +=3D
> >rte_fbk_hash.c
> >>  # install this header file
> >>  SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include :=3D rte_hash.h
> >>  SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include +=3D rte_hash_crc.h
> >> -ifeq ($(CONFIG_RTE_ARCH_ARM64),y)
> >> -ifneq ($(findstring RTE_MACHINE_CPUFLAG_CRC32,$(CFLAGS)),)
> >> -SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include +=3D rte_crc_arm64.h
> >> -endif
> >> -endif
> >>  SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include +=3D rte_jhash.h
> >>  SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include +=3D rte_thash.h
> >>  SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include +=3D rte_fbk_hash.h
> >> diff --git a/lib/librte_hash/crc_arm64.h b/lib/librte_hash/crc_arm64.h
> >> new file mode 100644
> >> index 000000000..8e75f8297
> >
> >Wouldn't that break 'make  install T=3D...'?
>=20
> My bad I verified with meson and it was building fine.
>=20
> >As now rte_hash_crc.h includes not public headers (crc_x86.h, etc.).
> >Same question about external apps, where they would get from these
> >headers?
>=20
> I think in the next version we can directly have the arch specific functi=
ons
> Implemented in rte_hash_crc.h. Since its pretty stable code and overhead =
of extra
> ~120 lines.

Ok... but why not then just leave arch specific headers, as they are right =
now?
What is wrong with current approach?