From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50065.outbound.protection.outlook.com [40.107.5.65]) by dpdk.org (Postfix) with ESMTP id 6C4CA374 for ; Thu, 2 May 2019 03:54:37 +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=sA648ddRAj8N4fQ7TyUfvKI0/8PqxcONRqemXMk1tec=; b=mqY+PbzCTYpvA8H/EgmoCGvtl+Q7oMcHAw5sH153R5uu3ilDbD5SBC3NPCxGxcul+vn/hvN/mV4ywyyR1K98TvQR2x/8zN7TsHn8ggBLqvV1npJNS1Kl34kMUSccw9O/z1cFZy1UI2nnR2vQBnLlkgaU7eGB2JQkLtKsoEOwB+k= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB3948.eurprd05.prod.outlook.com (52.134.72.19) 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 01:54:35 +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 01:54:36 +0000 From: Yongseok Koh To: Honnappa Nagarahalli CC: "jerinj@marvell.com" , "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+ooT6Y9krUAgAAZAACAAuXVE4ATlfIAgAMI6wA= Date: Thu, 2 May 2019 01:54:35 +0000 Message-ID: <0B9F2C32-4530-4A7E-AE63-657361771001@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: af65a4d8-4eb8-43d7-d423-08d6cea1211d 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:DB3PR0502MB3948; x-ms-traffictypediagnostic: DB3PR0502MB3948: x-ms-exchange-purlcount: 1 x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0025434D2D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(136003)(376002)(39860400002)(366004)(51914003)(189003)(199004)(54906003)(486006)(316002)(68736007)(6436002)(64756008)(11346002)(53936002)(82746002)(3846002)(14454004)(6246003)(99286004)(5660300002)(305945005)(76176011)(86362001)(7736002)(2906002)(4326008)(36756003)(25786009)(478600001)(446003)(45080400002)(83716004)(6306002)(6512007)(966005)(71190400001)(6116002)(14444005)(33656002)(53546011)(102836004)(6506007)(186003)(2616005)(26005)(476003)(256004)(71200400001)(6916009)(6486002)(66476007)(66446008)(81166006)(81156014)(8936002)(66556008)(229853002)(66066001)(76116006)(8676002)(91956017)(73956011)(66946007)(6314003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB3948; H:DB3PR0502MB3980.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 4LQFBy5nX2d+bHodi7LdLbgsqxosMJFQZpL1JcWRrUqn/MXW4k8h1Gtr14Kdo6XAGCF0BKvVkhLNRfS00YyPBXVrO7UgxkMcnSYVK+sUgUu10++QldzC0ksaV4kmL6q3Enrr8XCMkstuymz7k09DirBWuSNMylzXQi/V2Glyryphh8FBJgXMSmufkNsUR4OtNFOGxHbWN6v6oCiysQ7uw3xOdzLuvITbjWv7MfbjSk9f+sG9OqwsbeGEQiyNcfV3/2m0gOr4yCWNmN/nDx2k85nMWwsiMtz0gpquXxiSORbjcj4RCdXOxsfeEKgjOrUdnKScxQw8Y2Ig+0jBhg7IGHUMrjotRNPJqlbrT1TbaYa6lFmcG3uAsA48GaRWcE2PnO5ZOFgYJmuwtrO/3KdkrPjs+ggZIhDPIOvehhzp33U= 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: af65a4d8-4eb8-43d7-d423-08d6cea1211d X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 01:54:35.8732 (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: DB3PR0502MB3948 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 01:54:37 -0000 > On Apr 29, 2019, at 8:33 PM, Honnappa Nagarahalli wrote: >=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 i= s >> 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 o= nly when crypto intrinsics are used. However, when 'sha3' (part of 8.2 cryp= to) flag is enabled, compiler can generate 3-way exclusive OR instructions = beyond the intrinsics. 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 sure on GNU indirect function portability. >=20 > [1] https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= illnewton.name%2F2013%2F07%2F02%2Fusing-gnu-indirect-functions%2F&data= =3D02%7C01%7Cyskoh%40mellanox.com%7Ce8738c4f725a4ca608ea08d6cd1cac03%7Ca652= 971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636921920373635167&sdata=3Dkuq6d= bpTBfRgokrv2L%2FV4BIM0q1k%2FiL1JaMqCHUc2c0%3D&reserved=3D0 Thanks for the update, Then, I think the original patch to have build config is currently okay. Will submit it again. 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 AB554A0AC5 for ; Thu, 2 May 2019 03:54:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8F2B2B62; Thu, 2 May 2019 03:54:38 +0200 (CEST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50065.outbound.protection.outlook.com [40.107.5.65]) by dpdk.org (Postfix) with ESMTP id 6C4CA374 for ; Thu, 2 May 2019 03:54:37 +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=sA648ddRAj8N4fQ7TyUfvKI0/8PqxcONRqemXMk1tec=; b=mqY+PbzCTYpvA8H/EgmoCGvtl+Q7oMcHAw5sH153R5uu3ilDbD5SBC3NPCxGxcul+vn/hvN/mV4ywyyR1K98TvQR2x/8zN7TsHn8ggBLqvV1npJNS1Kl34kMUSccw9O/z1cFZy1UI2nnR2vQBnLlkgaU7eGB2JQkLtKsoEOwB+k= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB3948.eurprd05.prod.outlook.com (52.134.72.19) 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 01:54:35 +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 01:54:36 +0000 From: Yongseok Koh To: Honnappa Nagarahalli CC: "jerinj@marvell.com" , "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+ooT6Y9krUAgAAZAACAAuXVE4ATlfIAgAMI6wA= Date: Thu, 2 May 2019 01:54:35 +0000 Message-ID: <0B9F2C32-4530-4A7E-AE63-657361771001@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: af65a4d8-4eb8-43d7-d423-08d6cea1211d 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:DB3PR0502MB3948; x-ms-traffictypediagnostic: DB3PR0502MB3948: x-ms-exchange-purlcount: 1 x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0025434D2D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(136003)(376002)(39860400002)(366004)(51914003)(189003)(199004)(54906003)(486006)(316002)(68736007)(6436002)(64756008)(11346002)(53936002)(82746002)(3846002)(14454004)(6246003)(99286004)(5660300002)(305945005)(76176011)(86362001)(7736002)(2906002)(4326008)(36756003)(25786009)(478600001)(446003)(45080400002)(83716004)(6306002)(6512007)(966005)(71190400001)(6116002)(14444005)(33656002)(53546011)(102836004)(6506007)(186003)(2616005)(26005)(476003)(256004)(71200400001)(6916009)(6486002)(66476007)(66446008)(81166006)(81156014)(8936002)(66556008)(229853002)(66066001)(76116006)(8676002)(91956017)(73956011)(66946007)(6314003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB3948; H:DB3PR0502MB3980.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 4LQFBy5nX2d+bHodi7LdLbgsqxosMJFQZpL1JcWRrUqn/MXW4k8h1Gtr14Kdo6XAGCF0BKvVkhLNRfS00YyPBXVrO7UgxkMcnSYVK+sUgUu10++QldzC0ksaV4kmL6q3Enrr8XCMkstuymz7k09DirBWuSNMylzXQi/V2Glyryphh8FBJgXMSmufkNsUR4OtNFOGxHbWN6v6oCiysQ7uw3xOdzLuvITbjWv7MfbjSk9f+sG9OqwsbeGEQiyNcfV3/2m0gOr4yCWNmN/nDx2k85nMWwsiMtz0gpquXxiSORbjcj4RCdXOxsfeEKgjOrUdnKScxQw8Y2Ig+0jBhg7IGHUMrjotRNPJqlbrT1TbaYa6lFmcG3uAsA48GaRWcE2PnO5ZOFgYJmuwtrO/3KdkrPjs+ggZIhDPIOvehhzp33U= 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: af65a4d8-4eb8-43d7-d423-08d6cea1211d X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 01:54:35.8732 (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: DB3PR0502MB3948 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: <20190502015435.-P1R2LrrzhHFuIpRvKKr7k5Mf_2B3VVRbe-gUDDOT0M@z> > On Apr 29, 2019, at 8:33 PM, Honnappa Nagarahalli wrote: >=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 i= s >> 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 o= nly when crypto intrinsics are used. However, when 'sha3' (part of 8.2 cryp= to) flag is enabled, compiler can generate 3-way exclusive OR instructions = beyond the intrinsics. 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 sure on GNU indirect function portability. >=20 > [1] https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= illnewton.name%2F2013%2F07%2F02%2Fusing-gnu-indirect-functions%2F&data= =3D02%7C01%7Cyskoh%40mellanox.com%7Ce8738c4f725a4ca608ea08d6cd1cac03%7Ca652= 971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636921920373635167&sdata=3Dkuq6d= bpTBfRgokrv2L%2FV4BIM0q1k%2FiL1JaMqCHUc2c0%3D&reserved=3D0 Thanks for the update, Then, I think the original patch to have build config is currently okay. Will submit it again. thanks Yongseok