From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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" To: Pavan Nikhilesh Bhagavatula , "Jerin Jacob Kollanukkaran" , "thomas@monjalon.net" , "Wang, Yipeng1" , "Gobriel, Sameh" , "Richardson, Bruce" , Ruifeng Wang CC: "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: References: <20200429180515.5704-1-pbhagavatula@marvell.com> In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > >> From: Pavan Nikhilesh > >> > >> 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 > >> --- > >> > >> 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?