From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 5C674A0AC5 for ; Fri, 3 May 2019 01:08:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 554664CA6; Fri, 3 May 2019 01:08:47 +0200 (CEST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60072.outbound.protection.outlook.com [40.107.6.72]) by dpdk.org (Postfix) with ESMTP id 6B1E92B9C for ; Fri, 3 May 2019 01:08:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ea5dmpo/56dQ+XUlvO2j/G2W5Uxs8c4iVrdF/IdAqJc=; b=Ae0lPgtU8U1kaYJQRKeWH65uKnVTSS8+vsCRnDMMzCc9DbwFbnaTcqHteEaoTJikOXRydJKyUwbNbEP+7lgZUyqxftqPuzu5IARmFhDaVc7GdzHyGSC525Jpu56zzsx9eff7sIkH1YZcSWo3Ad1h44O+F8VJ4hR79THPXCNzzEk= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB4009.eurprd05.prod.outlook.com (52.134.72.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.11; Thu, 2 May 2019 23:08:43 +0000 Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::e8d5:4aff:902d:6e98]) by DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::e8d5:4aff:902d:6e98%5]) with mapi id 15.20.1856.008; Thu, 2 May 2019 23:08:43 +0000 From: Yongseok Koh To: Jerin Jacob Kollanukkaran CC: Honnappa Nagarahalli , "bruce.richardson@intel.com" , Pavan Nikhilesh Bhagavatula , Shahaf Shuler , "dev@dpdk.org" , Thomas Monjalon , "Gavin Hu (Arm Technology China)" , nd Thread-Topic: [EXT] [PATCH 5/6] build: add option for armv8 crypto extension Thread-Index: AQHU8cm5b8SJPn5CW0moCR+0z+ooT6Y9krUAgAAZAACAAuXVE4ATlfIAgAOUTQCAANibAA== Date: Thu, 2 May 2019 23:08:43 +0000 Message-ID: <926D3AC3-CA01-410A-8E23-4AB6581FA594@mellanox.com> References: <20190412232451.30197-1-yskoh@mellanox.com> <20190412232451.30197-6-yskoh@mellanox.com> <8328F59C-14DF-412E-A8F7-6AA1F5061065@mellanox.com> <3ACFB177-32B1-4AF9-BC60-DE1EBB4EC9C7@mellanox.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; x-originating-ip: [209.116.155.178] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cf7defa7-805d-42f1-4658-08d6cf531f6a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DB3PR0502MB4009; x-ms-traffictypediagnostic: DB3PR0502MB4009: x-ms-exchange-purlcount: 2 x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0025434D2D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(39860400002)(136003)(396003)(13464003)(199004)(189003)(71190400001)(71200400001)(486006)(36756003)(6486002)(53546011)(6506007)(82746002)(8676002)(6436002)(102836004)(76116006)(73956011)(26005)(66946007)(91956017)(476003)(11346002)(2616005)(53936002)(256004)(6116002)(3846002)(478600001)(2906002)(229853002)(305945005)(7736002)(446003)(83716004)(86362001)(81156014)(81166006)(66556008)(66476007)(6916009)(64756008)(66446008)(68736007)(45080400002)(99286004)(54906003)(6306002)(6512007)(14444005)(8936002)(4326008)(6246003)(76176011)(5660300002)(316002)(33656002)(66066001)(966005)(25786009)(14454004)(186003)(6314003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB4009; H:DB3PR0502MB3980.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5Qiuuw64Pf2AW3gnFo7r3tCcu4Pknp/Q5jO2DOaN/fG7I5aFYmJDX9DEnXezp5wnnV76ZMfmbkgY9rEd2BJ7szl/WH9ju+jmwKu6B9pooHNq/oTKc+CRYWgA+/9SniJcw6YcEHyU5DqUwihbnHtUNgiNHJmXzNnZIsG9xShEIxb7H+y0bweTWp/vHQ62GDtuBTHNPnyPAosnO6Wzh1HrPCE0i+OBRQAvswmKMmj7sukV8kPyNl68DA1/TEIXtxC+Rfj5rvf0JZuOEVoKxVCOmB57BuNGdOQFeJbZRC7V0TxMQOhCrZU95uBoAV9E3tHEKTXHDI7in/QVPO8TvKfn/kN9yyIcLIfx7w2N7qqhjpWK1a+/d0WBtwq0wuoEi4MigqP7+murLGeoC4EpO8Nqtq4FAnezdLxD+Nru1XmVD7I= Content-Type: text/plain; charset="UTF-8" Content-ID: <3AC83EC40E78314A8B913D426296D460@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: cf7defa7-805d-42f1-4658-08d6cf531f6a X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 23:08:43.4956 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0502MB4009 Subject: Re: [dpdk-dev] [EXT] [PATCH 5/6] build: add option for armv8 crypto extension 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" Message-ID: <20190502230843.HgYln6HiuoRZ8uqZIdt7-isThfvfQ5XzFwjkqunwb8w@z> > On May 2, 2019, at 3:13 AM, Jerin Jacob Kollanukkaran wrote: >=20 >> -----Original Message----- >> From: Honnappa Nagarahalli >> Sent: Tuesday, April 30, 2019 9:04 AM >> To: yskoh@mellanox.com >> Cc: Jerin Jacob Kollanukkaran ; >> bruce.richardson@intel.com; Pavan Nikhilesh Bhagavatula >> ; Shahaf Shuler ; >> dev@dpdk.org; thomas@monjalon.net; Gavin Hu (Arm Technology China) >> ; Honnappa Nagarahalli >> ; nd ; nd >> Subject: RE: [EXT] [PATCH 5/6] build: add option for armv8 crypto extens= ion >>=20 >>> On Apr 15, 2019, at 1:13 PM, Honnappa Nagarahalli >>> wrote: >>>=20 >>>>>>> Subject: [EXT] [PATCH 5/6] build: add option for armv8 crypto >>>>>>> extension >>>>>>>=20 >>>>>>> CONFIG_RTE_MACHINE=3D"armv8a" >>>>>>> +CONFIG_RTE_ENABLE_ARMV8_CRYPTO=3Dy >>>>>>=20 >>>>>> This approach is not scalable. Even, it is not good for BlueField >>>>>> as you you need to maintain two images. >>>>>>=20 >>>>>> Unlike other CPU flags, arm64's crypto cpu flag is really _optional_= . >>>>>> Access to crypto instructions is always at under runtime check. >>>>>> See the following in rte_armv8_pmd.c >>>>>>=20 >>>>>>=20 >>>>>> /* Check CPU for support for AES instruction set */ >>>>>> if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_AES)) { >>>>>> ARMV8_CRYPTO_LOG_ERR( >>>>>> "AES instructions not supported by CPU"); >>>>>> return -EFAULT; >>>>>> } >>>>>>=20 >>>>>> /* Check CPU for support for SHA instruction set */ >>>>>> if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_SHA1) || >>>>>> !rte_cpu_get_flag_enabled(RTE_CPUFLAG_SHA2)) { >>>>>> ARMV8_CRYPTO_LOG_ERR( >>>>>> "SHA1/SHA2 instructions not supported by CPU"); >>>>>> return -EFAULT; >>>>>> } >>>>>>=20 >>>>>> So In order to avoid one more config flags specific to armv8 in >>>>>> meson and makefile build infra And avoid the need for 6/6 patch. >>>>>> IMO, # Introduce optional CPU flag scheme in eal. Treat armv8 >>>>>> crypto as optional flag # Skip the eal init check for optional flag. >>>>>>=20 >>>>>> Do you see any issues with that approach? >>>>>=20 >>>>> I also thought about that approach and that was my number 1 priority. >>>>> But, I had one question came to my mind. Maybe, arm people can >>>>> confirm it. Is it 100% guaranteed that compiler never makes use of >>>>> any of crypto instructions even if there's no specific >>>>> asm/intrinsic code? The crypto extension has aes, pmull, >>>>> sha1 and sha2. In case of rte_memcpy() for x86, for example, >>>>> compiler may optimize code using avx512f instructions even though >>>>> it is written specifically with avx2 intrinsics (__mm256_*) unless >>>>> avx512f is >>> disabled. >>>>>=20 >>>>> If a complier expert in arm (or anyone else) confirm it is >>>>> completely **optional**, then I'd love to take that approach for sure= . >>>>>=20 >>>>> Copied dpdk-on-arm ML. >>>>>=20 >>>> I do not know the answer, will have to check with the compiler team. >>>> I will get >>> back on this. >>>=20 >>> Any update yet? >> Currently, enabling 'crypto' flag will generate the crypto instructions = only when >> crypto intrinsics are used. However, when 'sha3' (part of 8.2 crypto) fl= ag is >=20 > The default image is 8.1 spec and except octeontx2 every other SoC is 8.1= and > For octeotx2 crypto is supported. If so, Should we worry this case? Right, it sounds to me that we can disable the option without having the ne= w config flag until such instructions get needed. According to gcc-8 release = note [1], currently '+crypto' implies '+aes' and '+sha2' while '+sha3' and '+sm4= ' are newly introduced. Given that armv8 crypto PMD uses external binary of Marve= ll. I don't see any reason to enable '+crypto'. How about simply disable it from = armv8 build configs? diff --git a/config/arm/meson.build b/config/arm/meson.build index 7fa6ed3105..abc8cf346c 100644 --- a/config/arm/meson.build +++ b/config/arm/meson.build @@ -74,7 +74,7 @@ flags_octeontx2_extra =3D [ ['RTE_USE_C11_MEM_MODEL', true]] machine_args_generic =3D [ - ['default', ['-march=3Darmv8-a+crc+crypto']], + ['default', ['-march=3Darmv8-a+crc']], ['native', ['-march=3Dnative']], ['0xd03', ['-mcpu=3Dcortex-a53']], ['0xd04', ['-mcpu=3Dcortex-a35']], diff --git a/mk/machine/armv8a/rte.vars.mk b/mk/machine/armv8a/rte.vars.mk index 8252efbb7b..5e3ffc3adf 100644 --- a/mk/machine/armv8a/rte.vars.mk +++ b/mk/machine/armv8a/rte.vars.mk @@ -28,4 +28,4 @@ # CPU_LDFLAGS =3D # CPU_ASFLAGS =3D -MACHINE_CFLAGS +=3D -march=3Darmv8-a+crc+crypto +MACHINE_CFLAGS +=3D -march=3Darmv8-a+crc [1] https://gcc.gnu.org/gcc-8/changes.html Thanks, Yongseok >> enabled, compiler can generate 3-way exclusive OR instructions beyond th= e >> intrinsics. >=20 > The very same problem will be applicable for Linux kernel too for distrib= ution binary case. > If the above statement is true about 8.2 crypto and crypto generation wit= hout > Intrinsics then we need to see how linux kernel handling that and align o= ur solution > based on that. >=20 >> Compiler team cannot provide a guarantee that other crypto >> instructions will not be used beyond the intrinsics. >>=20 >> The current suggestion is to use GNU indirect function [1] or similar. I= am not >=20 > Not sure how it helps? If we know the compiler is generating a specific f= unction > With crypto instruction then we can generate _alternative_ function for t= he same > With hwcap?.How do we know which function compiler using compiler instruc= tions? >=20 >=20 >> sure on GNU indirect function portability. >=20 > We are using HWCAP scheme, So we may not need the very exact GNU indirect > scheme to fix the issue. >=20 >>=20 >> [1] https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= willnewton.name%2F2013%2F07%2F02%2Fusing-gnu-indirect-functions%2F&data= =3D02%7C01%7Cyskoh%40mellanox.com%7Cda8fb7ed03e7406ded8908d6cee6d759%7Ca652= 971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636923888189316743&sdata=3Dx5XNd= 5WZ3EtiprPMiFzaskvigX8K0AoXA2w%2BKiN156c%3D&reserved=3D0 >>=20 >>>=20 >>> Thanks >>> Yongseok