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 7C700A0679 for ; Tue, 30 Apr 2019 05:33:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A8CB95F72; Tue, 30 Apr 2019 05:33:55 +0200 (CEST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60040.outbound.protection.outlook.com [40.107.6.40]) by dpdk.org (Postfix) with ESMTP id CDE445F44 for ; Tue, 30 Apr 2019 05:33:54 +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=979AEQadK+DqUEXJqY1HSUQj8s+q3tUs946mJdXQvjw=; b=hwO0o4WvJyVo2STJKi2mr8y0ucfaZ6cf0Gz68uGB78r+dKM/SH3svW+vIq5CboL4kcQq3sz39ClyLi0lioJmpw6ntD62MxpzWNHtEHRFaJtrKtIAKjgP5h9iKtTybPyWOtD/pDe1klgN7h7KqTjz+yC7R7C9GYh3D9cUXMH7v0k= Received: from VE1PR08MB5149.eurprd08.prod.outlook.com (20.179.30.152) by VE1PR08MB5182.eurprd08.prod.outlook.com (20.179.31.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.13; Tue, 30 Apr 2019 03:33:52 +0000 Received: from VE1PR08MB5149.eurprd08.prod.outlook.com ([fe80::9b6:3403:4386:78]) by VE1PR08MB5149.eurprd08.prod.outlook.com ([fe80::9b6:3403:4386:78%2]) with mapi id 15.20.1835.018; Tue, 30 Apr 2019 03:33:52 +0000 From: Honnappa Nagarahalli To: "yskoh@mellanox.com" CC: "jerinj@marvell.com" , "bruce.richardson@intel.com" , Pavan Nikhilesh Bhagavatula , Shahaf Shuler , "dev@dpdk.org" , "thomas@monjalon.net" , "Gavin Hu (Arm Technology China)" , Honnappa Nagarahalli , nd , nd Thread-Topic: [EXT] [PATCH 5/6] build: add option for armv8 crypto extension Thread-Index: AQHU87skDqGgIb5/akCGo940k1lIHaY9pwyQgALmmoCAEyNQcA== Date: Tue, 30 Apr 2019 03:33:52 +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> In-Reply-To: <3ACFB177-32B1-4AF9-BC60-DE1EBB4EC9C7@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: 78f322e9-9e2d-4a05-d479-08d6cd1caa8b 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:VE1PR08MB5182; x-ms-traffictypediagnostic: VE1PR08MB5182: x-ms-exchange-purlcount: 1 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: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(39860400002)(396003)(136003)(346002)(199004)(189003)(5660300002)(93886005)(229853002)(476003)(2906002)(33656002)(81166006)(81156014)(1730700003)(3846002)(6116002)(8936002)(2501003)(7696005)(8676002)(6436002)(5640700003)(74316002)(68736007)(53546011)(97736004)(6506007)(305945005)(6916009)(25786009)(99286004)(486006)(26005)(4326008)(2351001)(76176011)(102836004)(7736002)(14454004)(66066001)(9686003)(55016002)(6306002)(446003)(11346002)(53936002)(66946007)(52536014)(966005)(54906003)(72206003)(478600001)(186003)(76116006)(316002)(66476007)(64756008)(86362001)(66446008)(73956011)(66556008)(14444005)(71190400001)(71200400001)(256004)(6246003)(6314003); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR08MB5182; H:VE1PR08MB5149.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: LIEYBF1VB3X86xiv227Vg7dCFkkdPfLMJlbXx9y4vBrhypQhLhc+4cXjM/bzUYUN5mwM7cFNcNgzRya/fd1Rx8Z1lX0Kj1dhNdvD3357NydLjOf0CXI8GdZf4yzYHQAwXFeCYzmHshYW9tTj9nQBLmdkA7oaCMV4mRcmwpB2gXVabvJbs0GHVHHuT4QvOm01dsbyFzVSqzUxMW07zeRfjZr1HAByqjC4MyN98cLCISvqXs8Bbogb4YgTICCGWZEc7P2Tjh49H8vrqOj6vLrzDrG2plcC4U/5lPhqgfdawiNSd5DBHtn6EnRGMqEnhk/7Wl9Sn9V2g/2+1ucG92Ltcd1Q0SZvDnwmvMyjyNF6ZVd7rNuSvPZtrrW6/YLPRd76NK1yHJPwqF4zKV+eI/MUCDB3xovi4aMo7rxP6ywT+VU= 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: 78f322e9-9e2d-4a05-d479-08d6cd1caa8b X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2019 03:33:52.2502 (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: VE1PR08MB5182 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: <20190430033352.CjiH4gSSq3fbZeqLF_qjXN4V7JJN2_ndRnjQF8H7jmc@z> > On Apr 15, 2019, at 1:13 PM, Honnappa Nagarahalli > wrote: >=20 > >>>> 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 _optional_. > >>> 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 flag. > >>> > >>> Do you see any issues with that approach? > >> > >> 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. > >> > >> If a complier expert in arm (or anyone else) confirm it is completely > >> **optional**, then I'd love to take that approach for sure. > >> > >> 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. >=20 > Any update yet? Currently, enabling 'crypto' flag will generate the crypto instructions onl= y when crypto intrinsics are used. However, when 'sha3' (part of 8.2 crypto= ) flag is enabled, compiler can generate 3-way exclusive OR instructions be= yond the intrinsics. Compiler team cannot provide a guarantee that other cr= ypto instructions will not be used beyond the intrinsics. The current suggestion is to use GNU indirect function [1] or similar. I am= not sure on GNU indirect function portability. [1] https://willnewton.name/2013/07/02/using-gnu-indirect-functions/ >=20 > Thanks > Yongseok