From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00086.outbound.protection.outlook.com [40.107.0.86]) by dpdk.org (Postfix) with ESMTP id 99AF6B62 for ; Fri, 3 May 2019 05:54:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3AAPJkoSqskMDdClUyf33VHJZrqtpkP6j44ygzJ8Q4U=; b=Cjmg3+VWbNm9R7ztd1wf95rUBU5FXz5l/ZYlnB7hwfq1GzXiuHl5/2NT0KEa3s3d3mt6Xx4LDORLuqOPeXveIMOSuP15Bnjw95va7fnEAx5O7NOH8rTdFaJA9uxP6SyJaGNRKh69BdOAZAuPcgwaxxnDBmyBWmrQYSLVhyVGTuI= Received: from VE1PR08MB5149.eurprd08.prod.outlook.com (20.179.30.152) by VE1PR08MB4976.eurprd08.prod.outlook.com (10.255.158.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.11; Fri, 3 May 2019 03:54:09 +0000 Received: from VE1PR08MB5149.eurprd08.prod.outlook.com ([fe80::f5e3:39bc:e7d9:dfea]) by VE1PR08MB5149.eurprd08.prod.outlook.com ([fe80::f5e3:39bc:e7d9:dfea%5]) with mapi id 15.20.1856.012; Fri, 3 May 2019 03:54:09 +0000 From: Honnappa Nagarahalli To: "yskoh@mellanox.com" , "jerinj@marvell.com" CC: "bruce.richardson@intel.com" , Pavan Nikhilesh Bhagavatula , Shahaf Shuler , "dev@dpdk.org" , "thomas@monjalon.net" , "Gavin Hu (Arm Technology China)" , nd , Honnappa Nagarahalli , nd Thread-Topic: [EXT] [PATCH 5/6] build: add option for armv8 crypto extension Thread-Index: AQHU87skDqGgIb5/akCGo940k1lIHaY9pwyQgALmmoCAEyNQcIAEBvAAgADYnICAADrIEA== Date: Fri, 3 May 2019 03:54:09 +0000 Message-ID: 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=Honnappa.Nagarahalli@arm.com; x-originating-ip: [217.140.111.135] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5fa3ad8b-e769-45ff-7b6d-08d6cf7aff43 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:VE1PR08MB4976; x-ms-traffictypediagnostic: VE1PR08MB4976: x-ms-exchange-purlcount: 2 x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr nodisclaimer: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0026334A56 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(366004)(39860400002)(136003)(376002)(189003)(199004)(6246003)(8936002)(9686003)(3846002)(6116002)(66946007)(53936002)(4326008)(52536014)(76116006)(2501003)(66066001)(25786009)(5660300002)(316002)(66446008)(73956011)(64756008)(7736002)(6436002)(66476007)(14444005)(33656002)(476003)(81156014)(8676002)(66556008)(110136005)(76176011)(54906003)(99286004)(81166006)(446003)(55016002)(11346002)(6306002)(229853002)(7696005)(26005)(966005)(71190400001)(71200400001)(186003)(102836004)(14454004)(486006)(6506007)(256004)(53546011)(68736007)(72206003)(305945005)(45080400002)(74316002)(2906002)(508600001)(86362001)(6314003); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR08MB4976; H:VE1PR08MB5149.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Dbkmx59wAKX7FbCwYWi7IOTvba82E/K/yn/dZrtkBc0sDeENAq8E768DXhfJWQ+QVZlx5EG8CIBpzL4pBB1QlsoNx29uEDnIgLeZGfPLwrqcmtWDw924iV9wxfWztjCenLEDWd8CLtkngAua1zpxN0gKEEBhyoR15u3P2xMbPiK1JCbdRONIE70P9AjRxnmZSG7zZ4laDiULQ76tZ1bmxvIEZPPpJfBkq70r3qeDInCf08g/4wP/QmTezcOSi5xNDgpPy5fUAsjsaY7Id3uzrQa/VA7nNt+6Pmo4ojCkR/RjqBbWdDBPqSrTgSTLd0TpODKWaWf9dxMOr5Ma9GslHadbzzUQeRr14rzT7NvCCpsKVPQdVcOwfFrLt1vPUcoIUT2fXunvi/5lSvmGSLk5wHGKoqmxgagccxsgz09BS4A= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5fa3ad8b-e769-45ff-7b6d-08d6cf7aff43 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2019 03:54:09.4065 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB4976 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: Fri, 03 May 2019 03:54:11 -0000 > >>> On Apr 15, 2019, at 1:13 PM, Honnappa Nagarahalli > >>> wrote: > >>> > >>>>>>> Subject: [EXT] [PATCH 5/6] build: add option for armv8 crypto > >>>>>>> extension > >>>>>>> > >>>>>>> CONFIG_RTE_MACHINE=3D"armv8a" > >>>>>>> +CONFIG_RTE_ENABLE_ARMV8_CRYPTO=3Dy > >>>>>> > >>>>>> This approach is not scalable. Even, it is not good for BlueField > >>>>>> as you you need to maintain two images. > >>>>>> > >>>>>> Unlike other CPU flags, arm64's crypto cpu flag is really _optiona= l_. > >>>>>> Access to crypto instructions is always at under runtime check. > >>>>>> See the following in rte_armv8_pmd.c > >>>>>> > >>>>>> > >>>>>> /* 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; > >>>>>> } > >>>>>> > >>>>>> /* 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; > >>>>>> } > >>>>>> > >>>>>> 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 fla= g. > >>>>>> > >>>>>> Do you see any issues with that approach? > >>>>> > >>>>> I also thought about that approach and that was my number 1 priorit= y. > >>>>> 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. > >>>>> > >>>>> If a complier expert in arm (or anyone else) confirm it is > >>>>> completely **optional**, then I'd love to take that approach for su= re. > >>>>> > >>>>> Copied dpdk-on-arm ML. > >>>>> > >>>> I do not know the answer, will have to check with the compiler team. > >>>> I will get > >>> back on this. > >>> > >>> 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) flag is > > > > The default image is 8.1 spec and except octeontx2 every other SoC is I am not following this. I think the default image is 8.0. > > 8.1 and For octeotx2 crypto is supported. If so, Should we worry this c= ase? I assume we all are talking about the distro/binary portable build. IMO, we= should not just look at the existing SoCs. The CPU specific builds have the freedom to compile as per their correspond= ing support. >=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 > Marvell. I don't see any reason to enable '+crypto'. How about simply dis= able > it from armv8 build configs? I think it should be fine. But, this alone is not enough. The run time dete= ction of the crypto feature and hooking up the correct pointers needs to be= added. >=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.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 >=20 > -MACHINE_CFLAGS +=3D -march=3Darmv8-a+crc+crypto > +MACHINE_CFLAGS +=3D -march=3Darmv8-a+crc >=20 >=20 > [1] https://gcc.gnu.org/gcc-8/changes.html >=20 > Thanks, > Yongseok >=20 > >> enabled, compiler can generate 3-way exclusive OR instructions beyond > >> the intrinsics. > > > > The very same problem will be applicable for Linux kernel too for > distribution binary case. > > If the above statement is true about 8.2 crypto and crypto generation > > without Intrinsics then we need to see how linux kernel handling that > > and align our solution based on that. Yes, the compiler team cited Linux kernel example, I have not verified it m= yself. > > > >> Compiler team cannot provide a guarantee that other crypto > >> instructions will not be used beyond the intrinsics. > >> > >> The current suggestion is to use GNU indirect function [1] or > >> similar. I am not > > > > 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 instructions? This feature is similar to using function pointers and choosing which funct= ion pointer to use at run time. If this feature is used, the function point= er to use is decided during dynamic linking stage. Either ways, we need to have 2 sets of crypto PMD drivers. One that impleme= nts the actual functionality using crypto intrinsics/assembly. Only, this c= ode needs to be compiled with '+crypto'. Second driver that implements just= stubs and returns error. This code will be compiled without '+crypto'. At = run time, depending on the HWCAP, the correct driver/function pointers need= to be hooked up. > > > > > >> sure on GNU indirect function portability. > > > > We are using HWCAP scheme, So we may not need the very exact GNU > > indirect scheme to fix the issue. Agree, using indirect functions is not a must. > > > >> > >> [1] > >> https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwi= l > >> lnewton.name%2F2013%2F07%2F02%2Fusing-gnu-indirect- > functions%2F&d > >> > ata=3D02%7C01%7Cyskoh%40mellanox.com%7Cda8fb7ed03e7406ded8908d6c > ee6d759 > >> %7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C63692388818 > 9316743& > >> > sdata=3Dx5XNd5WZ3EtiprPMiFzaskvigX8K0AoXA2w%2BKiN156c%3D&res > erved=3D0 > >> > >>> > >>> 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 D6168A0AC5 for ; Fri, 3 May 2019 05:54:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9E6A92986; Fri, 3 May 2019 05:54:13 +0200 (CEST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00086.outbound.protection.outlook.com [40.107.0.86]) by dpdk.org (Postfix) with ESMTP id 99AF6B62 for ; Fri, 3 May 2019 05:54:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3AAPJkoSqskMDdClUyf33VHJZrqtpkP6j44ygzJ8Q4U=; b=Cjmg3+VWbNm9R7ztd1wf95rUBU5FXz5l/ZYlnB7hwfq1GzXiuHl5/2NT0KEa3s3d3mt6Xx4LDORLuqOPeXveIMOSuP15Bnjw95va7fnEAx5O7NOH8rTdFaJA9uxP6SyJaGNRKh69BdOAZAuPcgwaxxnDBmyBWmrQYSLVhyVGTuI= Received: from VE1PR08MB5149.eurprd08.prod.outlook.com (20.179.30.152) by VE1PR08MB4976.eurprd08.prod.outlook.com (10.255.158.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.11; Fri, 3 May 2019 03:54:09 +0000 Received: from VE1PR08MB5149.eurprd08.prod.outlook.com ([fe80::f5e3:39bc:e7d9:dfea]) by VE1PR08MB5149.eurprd08.prod.outlook.com ([fe80::f5e3:39bc:e7d9:dfea%5]) with mapi id 15.20.1856.012; Fri, 3 May 2019 03:54:09 +0000 From: Honnappa Nagarahalli To: "yskoh@mellanox.com" , "jerinj@marvell.com" CC: "bruce.richardson@intel.com" , Pavan Nikhilesh Bhagavatula , Shahaf Shuler , "dev@dpdk.org" , "thomas@monjalon.net" , "Gavin Hu (Arm Technology China)" , nd , Honnappa Nagarahalli , nd Thread-Topic: [EXT] [PATCH 5/6] build: add option for armv8 crypto extension Thread-Index: AQHU87skDqGgIb5/akCGo940k1lIHaY9pwyQgALmmoCAEyNQcIAEBvAAgADYnICAADrIEA== Date: Fri, 3 May 2019 03:54:09 +0000 Message-ID: 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=Honnappa.Nagarahalli@arm.com; x-originating-ip: [217.140.111.135] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5fa3ad8b-e769-45ff-7b6d-08d6cf7aff43 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:VE1PR08MB4976; x-ms-traffictypediagnostic: VE1PR08MB4976: x-ms-exchange-purlcount: 2 x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr nodisclaimer: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0026334A56 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(366004)(39860400002)(136003)(376002)(189003)(199004)(6246003)(8936002)(9686003)(3846002)(6116002)(66946007)(53936002)(4326008)(52536014)(76116006)(2501003)(66066001)(25786009)(5660300002)(316002)(66446008)(73956011)(64756008)(7736002)(6436002)(66476007)(14444005)(33656002)(476003)(81156014)(8676002)(66556008)(110136005)(76176011)(54906003)(99286004)(81166006)(446003)(55016002)(11346002)(6306002)(229853002)(7696005)(26005)(966005)(71190400001)(71200400001)(186003)(102836004)(14454004)(486006)(6506007)(256004)(53546011)(68736007)(72206003)(305945005)(45080400002)(74316002)(2906002)(508600001)(86362001)(6314003); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR08MB4976; H:VE1PR08MB5149.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Dbkmx59wAKX7FbCwYWi7IOTvba82E/K/yn/dZrtkBc0sDeENAq8E768DXhfJWQ+QVZlx5EG8CIBpzL4pBB1QlsoNx29uEDnIgLeZGfPLwrqcmtWDw924iV9wxfWztjCenLEDWd8CLtkngAua1zpxN0gKEEBhyoR15u3P2xMbPiK1JCbdRONIE70P9AjRxnmZSG7zZ4laDiULQ76tZ1bmxvIEZPPpJfBkq70r3qeDInCf08g/4wP/QmTezcOSi5xNDgpPy5fUAsjsaY7Id3uzrQa/VA7nNt+6Pmo4ojCkR/RjqBbWdDBPqSrTgSTLd0TpODKWaWf9dxMOr5Ma9GslHadbzzUQeRr14rzT7NvCCpsKVPQdVcOwfFrLt1vPUcoIUT2fXunvi/5lSvmGSLk5wHGKoqmxgagccxsgz09BS4A= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5fa3ad8b-e769-45ff-7b6d-08d6cf7aff43 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2019 03:54:09.4065 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB4976 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: <20190503035409.g3TKGejJfniPQgyiCrGKkbo0loyZ8KVOjeJwFuCAIiE@z> > >>> On Apr 15, 2019, at 1:13 PM, Honnappa Nagarahalli > >>> wrote: > >>> > >>>>>>> Subject: [EXT] [PATCH 5/6] build: add option for armv8 crypto > >>>>>>> extension > >>>>>>> > >>>>>>> CONFIG_RTE_MACHINE=3D"armv8a" > >>>>>>> +CONFIG_RTE_ENABLE_ARMV8_CRYPTO=3Dy > >>>>>> > >>>>>> This approach is not scalable. Even, it is not good for BlueField > >>>>>> as you you need to maintain two images. > >>>>>> > >>>>>> Unlike other CPU flags, arm64's crypto cpu flag is really _optiona= l_. > >>>>>> Access to crypto instructions is always at under runtime check. > >>>>>> See the following in rte_armv8_pmd.c > >>>>>> > >>>>>> > >>>>>> /* 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; > >>>>>> } > >>>>>> > >>>>>> /* 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; > >>>>>> } > >>>>>> > >>>>>> 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 fla= g. > >>>>>> > >>>>>> Do you see any issues with that approach? > >>>>> > >>>>> I also thought about that approach and that was my number 1 priorit= y. > >>>>> 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. > >>>>> > >>>>> If a complier expert in arm (or anyone else) confirm it is > >>>>> completely **optional**, then I'd love to take that approach for su= re. > >>>>> > >>>>> Copied dpdk-on-arm ML. > >>>>> > >>>> I do not know the answer, will have to check with the compiler team. > >>>> I will get > >>> back on this. > >>> > >>> 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) flag is > > > > The default image is 8.1 spec and except octeontx2 every other SoC is I am not following this. I think the default image is 8.0. > > 8.1 and For octeotx2 crypto is supported. If so, Should we worry this c= ase? I assume we all are talking about the distro/binary portable build. IMO, we= should not just look at the existing SoCs. The CPU specific builds have the freedom to compile as per their correspond= ing support. >=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 > Marvell. I don't see any reason to enable '+crypto'. How about simply dis= able > it from armv8 build configs? I think it should be fine. But, this alone is not enough. The run time dete= ction of the crypto feature and hooking up the correct pointers needs to be= added. >=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.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 >=20 > -MACHINE_CFLAGS +=3D -march=3Darmv8-a+crc+crypto > +MACHINE_CFLAGS +=3D -march=3Darmv8-a+crc >=20 >=20 > [1] https://gcc.gnu.org/gcc-8/changes.html >=20 > Thanks, > Yongseok >=20 > >> enabled, compiler can generate 3-way exclusive OR instructions beyond > >> the intrinsics. > > > > The very same problem will be applicable for Linux kernel too for > distribution binary case. > > If the above statement is true about 8.2 crypto and crypto generation > > without Intrinsics then we need to see how linux kernel handling that > > and align our solution based on that. Yes, the compiler team cited Linux kernel example, I have not verified it m= yself. > > > >> Compiler team cannot provide a guarantee that other crypto > >> instructions will not be used beyond the intrinsics. > >> > >> The current suggestion is to use GNU indirect function [1] or > >> similar. I am not > > > > 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 instructions? This feature is similar to using function pointers and choosing which funct= ion pointer to use at run time. If this feature is used, the function point= er to use is decided during dynamic linking stage. Either ways, we need to have 2 sets of crypto PMD drivers. One that impleme= nts the actual functionality using crypto intrinsics/assembly. Only, this c= ode needs to be compiled with '+crypto'. Second driver that implements just= stubs and returns error. This code will be compiled without '+crypto'. At = run time, depending on the HWCAP, the correct driver/function pointers need= to be hooked up. > > > > > >> sure on GNU indirect function portability. > > > > We are using HWCAP scheme, So we may not need the very exact GNU > > indirect scheme to fix the issue. Agree, using indirect functions is not a must. > > > >> > >> [1] > >> https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwi= l > >> lnewton.name%2F2013%2F07%2F02%2Fusing-gnu-indirect- > functions%2F&d > >> > ata=3D02%7C01%7Cyskoh%40mellanox.com%7Cda8fb7ed03e7406ded8908d6c > ee6d759 > >> %7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C63692388818 > 9316743& > >> > sdata=3Dx5XNd5WZ3EtiprPMiFzaskvigX8K0AoXA2w%2BKiN156c%3D&res > erved=3D0 > >> > >>> > >>> Thanks > >>> Yongseok