From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40042.outbound.protection.outlook.com [40.107.4.42]) by dpdk.org (Postfix) with ESMTP id 7B1B75F0F for ; Fri, 3 May 2019 01:33:24 +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=3xOYaUSmwVpIV8lL5YXqvUm9cowzonTrukIPMbsmvhE=; b=MNsOzmV3cK04HHxhd1FkTHoSzdBmLfb3iSziZP9G71CW4y/a0MYmWsQJKZZG83D7Riz39WyGPFzt/ZKbKefmfSxXHS9Ij083JYGK6NlgiX7kDAQeexI7spk0GYSHCVtHZghHy69fVtvAUsTWBAuwpmvMfx0mgLentrmOfgKHx0A= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB4026.eurprd05.prod.outlook.com (52.134.72.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.10; Thu, 2 May 2019 23:33:23 +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:33:23 +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: [dpdk-dev] [EXT] [PATCH 5/6] build: add option for armv8 crypto extension Thread-Index: AQHVAT9uFGdMwcS9fUqWhLlzqjbxqw== Date: Thu, 2 May 2019 23:33:22 +0000 Message-ID: <76A4CB8C-4429-492D-8885-54B30C64165F@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> <926D3AC3-CA01-410A-8E23-4AB6581FA594@mellanox.com> In-Reply-To: <926D3AC3-CA01-410A-8E23-4AB6581FA594@mellanox.com> 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: d7c41e3c-e236-4975-019e-08d6cf569139 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:DB3PR0502MB4026; x-ms-traffictypediagnostic: DB3PR0502MB4026: 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)(396003)(366004)(376002)(136003)(39860400002)(346002)(199004)(189003)(13464003)(25786009)(316002)(6512007)(33656002)(229853002)(102836004)(54906003)(6306002)(99286004)(8936002)(26005)(6916009)(7736002)(6246003)(81166006)(81156014)(76176011)(186003)(68736007)(3846002)(6116002)(966005)(478600001)(36756003)(73956011)(82746002)(5660300002)(476003)(11346002)(66946007)(4326008)(14454004)(53936002)(305945005)(2906002)(486006)(2616005)(83716004)(6486002)(446003)(45080400002)(91956017)(64756008)(66556008)(66446008)(76116006)(256004)(14444005)(86362001)(66476007)(53546011)(66066001)(6436002)(6506007)(71190400001)(71200400001)(6314003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB4026; 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: Xyc2nivP+KO9CtfheB7Td0uSUHTDz23CbhGzWIKPQbLyP5hDB0vCR8KRxLr22RMp/Emwz68iM68yluWvlnuzLsCX3XL7SHug7lbgMP8ZM9ziBYcRkIzUEeURb0D1s04zN2+AzdF+TVzmjMM3vS+/XeMqNUPCJNcYz35iGYWNRxjj5RgjNWhyb4Typ0OfIcL9CJlIP0qF94OB/ytEnhWuvREhSdfRF82xaVTB3/G/cDLrK/bq7eWu7HcjhBhEEO/1agtzhy6EQQKxGATtdJ3HejRv1F8NaGD8DBvjc1BvOtv//uyNmqyIFWGvKVAcYHmkugA/4JABjC+nUIkUxa7jX0K6a9eGg110Tg5NX3ZgOEDxivLvvPcvdAmpIGzIFnLNM4yzamjizq2O2Rvc0ej3+rbkjvmPTjALubV1KoDcZ4c= Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: d7c41e3c-e236-4975-019e-08d6cf569139 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 23:33:22.8942 (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: DB3PR0502MB4026 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: , X-List-Received-Date: Thu, 02 May 2019 23:33:24 -0000 > On May 2, 2019, at 4:08 PM, Yongseok Koh wrote: >=20 >>=20 >> 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 exten= sion >>>=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 sur= e. >>>>>>=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) f= lag 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? >=20 > Right, it sounds to me that we can disable the option without having the = new > config flag until such instructions get needed. According to gcc-8 releas= e note > [1], currently '+crypto' implies '+aes' and '+sha2' while '+sha3' and '+s= m4' are > newly introduced. Given that armv8 crypto PMD uses external binary of Mar= vell. I > don't see any reason to enable '+crypto'. How about simply disable it fro= m armv8 > build configs? >=20 > 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]] >=20 > 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.m= k > 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 >=20 > -MACHINE_CFLAGS +=3D -march=3Darmv8-a+crc+crypto > +MACHINE_CFLAGS +=3D -march=3Darmv8-a+crc >=20 >=20 > [1] https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fg= cc.gnu.org%2Fgcc-8%2Fchanges.html&data=3D02%7C01%7Cyskoh%40mellanox.com= %7C8a0d60c82a11498bf65608d6cf5327c3%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%= 7C0%7C636924353391308162&sdata=3DcuueiNi%2FdBfEJDKa8IFstwctBIrOkfZn0J7x= ojxgfvI%3D&reserved=3D0 Just to make sure, I've run examples/ipsec-secgw on BlueField and it ran we= ll as expected. >>> enabled, compiler can generate 3-way exclusive OR instructions beyond t= he >>> intrinsics. >>=20 >> The very same problem will be applicable for Linux kernel too for distri= bution binary case. >> If the above statement is true about 8.2 crypto and crypto generation wi= thout >> Intrinsics then we need to see how linux kernel handling that and align = our 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 = function >> With crypto instruction then we can generate _alternative_ function for = the same >> With hwcap?.How do we know which function compiler using compiler instru= ctions? >>=20 >>=20 >>> sure on GNU indirect function portability. >>=20 >> We are using HWCAP scheme, So we may not need the very exact GNU indirec= t >> scheme to fix the issue. >>=20 >>>=20 >>> [1] https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fwillnewton.name%2F2013%2F07%2F02%2Fusing-gnu-indirect-functions%2F&dat= a=3D02%7C01%7Cyskoh%40mellanox.com%7C8a0d60c82a11498bf65608d6cf5327c3%7Ca65= 2971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636924353391308162&sdata=3DWcRH= om7k1MFmHzK1LYJEaI5ruMzCvvMxlFo7Ivl%2BOh4%3D&reserved=3D0 >>>=20 >>>>=20 >>>> Thanks >>>> Yongseok 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 2E1D4A0AC5 for ; Fri, 3 May 2019 01:33:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0A7C85F1C; Fri, 3 May 2019 01:33:26 +0200 (CEST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40042.outbound.protection.outlook.com [40.107.4.42]) by dpdk.org (Postfix) with ESMTP id 7B1B75F0F for ; Fri, 3 May 2019 01:33:24 +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=3xOYaUSmwVpIV8lL5YXqvUm9cowzonTrukIPMbsmvhE=; b=MNsOzmV3cK04HHxhd1FkTHoSzdBmLfb3iSziZP9G71CW4y/a0MYmWsQJKZZG83D7Riz39WyGPFzt/ZKbKefmfSxXHS9Ij083JYGK6NlgiX7kDAQeexI7spk0GYSHCVtHZghHy69fVtvAUsTWBAuwpmvMfx0mgLentrmOfgKHx0A= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB4026.eurprd05.prod.outlook.com (52.134.72.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.10; Thu, 2 May 2019 23:33:23 +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:33:23 +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: [dpdk-dev] [EXT] [PATCH 5/6] build: add option for armv8 crypto extension Thread-Index: AQHVAT9uFGdMwcS9fUqWhLlzqjbxqw== Date: Thu, 2 May 2019 23:33:22 +0000 Message-ID: <76A4CB8C-4429-492D-8885-54B30C64165F@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> <926D3AC3-CA01-410A-8E23-4AB6581FA594@mellanox.com> In-Reply-To: <926D3AC3-CA01-410A-8E23-4AB6581FA594@mellanox.com> 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: d7c41e3c-e236-4975-019e-08d6cf569139 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:DB3PR0502MB4026; x-ms-traffictypediagnostic: DB3PR0502MB4026: 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)(396003)(366004)(376002)(136003)(39860400002)(346002)(199004)(189003)(13464003)(25786009)(316002)(6512007)(33656002)(229853002)(102836004)(54906003)(6306002)(99286004)(8936002)(26005)(6916009)(7736002)(6246003)(81166006)(81156014)(76176011)(186003)(68736007)(3846002)(6116002)(966005)(478600001)(36756003)(73956011)(82746002)(5660300002)(476003)(11346002)(66946007)(4326008)(14454004)(53936002)(305945005)(2906002)(486006)(2616005)(83716004)(6486002)(446003)(45080400002)(91956017)(64756008)(66556008)(66446008)(76116006)(256004)(14444005)(86362001)(66476007)(53546011)(66066001)(6436002)(6506007)(71190400001)(71200400001)(6314003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB4026; 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: Xyc2nivP+KO9CtfheB7Td0uSUHTDz23CbhGzWIKPQbLyP5hDB0vCR8KRxLr22RMp/Emwz68iM68yluWvlnuzLsCX3XL7SHug7lbgMP8ZM9ziBYcRkIzUEeURb0D1s04zN2+AzdF+TVzmjMM3vS+/XeMqNUPCJNcYz35iGYWNRxjj5RgjNWhyb4Typ0OfIcL9CJlIP0qF94OB/ytEnhWuvREhSdfRF82xaVTB3/G/cDLrK/bq7eWu7HcjhBhEEO/1agtzhy6EQQKxGATtdJ3HejRv1F8NaGD8DBvjc1BvOtv//uyNmqyIFWGvKVAcYHmkugA/4JABjC+nUIkUxa7jX0K6a9eGg110Tg5NX3ZgOEDxivLvvPcvdAmpIGzIFnLNM4yzamjizq2O2Rvc0ej3+rbkjvmPTjALubV1KoDcZ4c= Content-Type: text/plain; charset="UTF-8" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: d7c41e3c-e236-4975-019e-08d6cf569139 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 23:33:22.8942 (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: DB3PR0502MB4026 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: <20190502233322.ocIkK1vWfWtROKYqBrsUEbssyYiYQfRcpjP2Dcl3ZEM@z> > On May 2, 2019, at 4:08 PM, Yongseok Koh wrote: >=20 >>=20 >> 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 exten= sion >>>=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 sur= e. >>>>>>=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) f= lag 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? >=20 > Right, it sounds to me that we can disable the option without having the = new > config flag until such instructions get needed. According to gcc-8 releas= e note > [1], currently '+crypto' implies '+aes' and '+sha2' while '+sha3' and '+s= m4' are > newly introduced. Given that armv8 crypto PMD uses external binary of Mar= vell. I > don't see any reason to enable '+crypto'. How about simply disable it fro= m armv8 > build configs? >=20 > 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]] >=20 > 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.m= k > 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 >=20 > -MACHINE_CFLAGS +=3D -march=3Darmv8-a+crc+crypto > +MACHINE_CFLAGS +=3D -march=3Darmv8-a+crc >=20 >=20 > [1] https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fg= cc.gnu.org%2Fgcc-8%2Fchanges.html&data=3D02%7C01%7Cyskoh%40mellanox.com= %7C8a0d60c82a11498bf65608d6cf5327c3%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%= 7C0%7C636924353391308162&sdata=3DcuueiNi%2FdBfEJDKa8IFstwctBIrOkfZn0J7x= ojxgfvI%3D&reserved=3D0 Just to make sure, I've run examples/ipsec-secgw on BlueField and it ran we= ll as expected. >>> enabled, compiler can generate 3-way exclusive OR instructions beyond t= he >>> intrinsics. >>=20 >> The very same problem will be applicable for Linux kernel too for distri= bution binary case. >> If the above statement is true about 8.2 crypto and crypto generation wi= thout >> Intrinsics then we need to see how linux kernel handling that and align = our 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 = function >> With crypto instruction then we can generate _alternative_ function for = the same >> With hwcap?.How do we know which function compiler using compiler instru= ctions? >>=20 >>=20 >>> sure on GNU indirect function portability. >>=20 >> We are using HWCAP scheme, So we may not need the very exact GNU indirec= t >> scheme to fix the issue. >>=20 >>>=20 >>> [1] https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fwillnewton.name%2F2013%2F07%2F02%2Fusing-gnu-indirect-functions%2F&dat= a=3D02%7C01%7Cyskoh%40mellanox.com%7C8a0d60c82a11498bf65608d6cf5327c3%7Ca65= 2971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636924353391308162&sdata=3DWcRH= om7k1MFmHzK1LYJEaI5ruMzCvvMxlFo7Ivl%2BOh4%3D&reserved=3D0 >>>=20 >>>>=20 >>>> Thanks >>>> Yongseok