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 B490FA0AC5 for ; Thu, 2 May 2019 12:13:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 825BC2C4F; Thu, 2 May 2019 12:13:35 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id EBC1E29CB for ; Thu, 2 May 2019 12:13:33 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x42A65ih002521; Thu, 2 May 2019 03:13:30 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=RxV9SruJ1HE7fbDsa8ZBmHS5eGMqtWbzwtn/vtlAD5A=; b=VNhsSnzQXWNKDhuUZyDOIXVYyY0/Tk5sYKB6MvhUm2R/VYRdSjhDKKoNatckcZnJPfrb RBXX52nml91jCBANVeYBQ9Y3NsQHHfEC7/ETarkTd3/hAYxeq/FqxqNtbvrLPyPCaTSt up9W6clpExmAiyZxAsdztUfCFDj4xIt0Hg/t8pdukVIeoITfwRH9M4ZgApJ0vWiuyg5c gmbDbfwMbrdLdshfnX9JZtSmjwt5Dl7HDbQ+94+tMFix/foq4rChR3W8NFc2/v+P9X+o ycs/n3gdIy6l9y2TvxqoW4ydMqKOKgqWSXP67c3ay4FFtONcXm0blb6/BbUJMbFeI20+ mA== Received: from sc-exch04.marvell.com ([199.233.58.184]) by mx0b-0016f401.pphosted.com with ESMTP id 2s7k3ba4f2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 02 May 2019 03:13:30 -0700 Received: from SC-EXCH02.marvell.com (10.93.176.82) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 2 May 2019 03:13:28 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (104.47.33.52) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 2 May 2019 03:13:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RxV9SruJ1HE7fbDsa8ZBmHS5eGMqtWbzwtn/vtlAD5A=; b=MQA0Lxrq4pl1SVdBa7o46qtbFIxXVYO33J6PltMXx+qGL9Z/nY+ecT0wd+m/Vt2KYvb/qbMEKyzWAxzKkec9+CzUZVmPSLADjEpQCm9FuVlLlETkLr1x1V0c3gwLBZQfcE/r60nacH9HLmRATRI9MXEGmQPG8XQyXo/AdzZRae4= Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by BYAPR18MB2744.namprd18.prod.outlook.com (20.179.56.202) 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 10:13:26 +0000 Received: from BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::5827:68d1:b66c:bd2d]) by BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::5827:68d1:b66c:bd2d%3]) with mapi id 15.20.1856.008; Thu, 2 May 2019 10:13:26 +0000 From: Jerin Jacob Kollanukkaran To: Honnappa Nagarahalli , "yskoh@mellanox.com" CC: "bruce.richardson@intel.com" , "Pavan Nikhilesh Bhagavatula" , Shahaf Shuler , "dev@dpdk.org" , "thomas@monjalon.net" , "Gavin Hu (Arm Technology China)" , nd , nd Thread-Topic: [EXT] [PATCH 5/6] build: add option for armv8 crypto extension Thread-Index: AQHU8YcCJBMTHcCzhkWYreJI0p1ieaY5q2zggAPnzwCAABj/AIAC5dWAgBOV8gCAA5D2wA== Date: Thu, 2 May 2019 10:13:26 +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: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.68.105.47] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c3ba0a3f-33b5-4419-37bf-08d6cee6d112 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR18MB2744; x-ms-traffictypediagnostic: BYAPR18MB2744: x-ms-exchange-purlcount: 1 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)(39860400002)(136003)(346002)(376002)(13464003)(189003)(199004)(14444005)(55016002)(6306002)(81166006)(256004)(6436002)(6246003)(81156014)(8676002)(76116006)(53936002)(229853002)(5660300002)(73956011)(2906002)(68736007)(66946007)(64756008)(86362001)(4326008)(71200400001)(52536014)(66556008)(66446008)(71190400001)(8936002)(66476007)(25786009)(305945005)(7736002)(110136005)(26005)(478600001)(6506007)(6116002)(74316002)(9686003)(53546011)(186003)(54906003)(99286004)(486006)(66066001)(316002)(446003)(476003)(2501003)(11346002)(14454004)(966005)(76176011)(33656002)(7696005)(55236004)(102836004)(3846002)(6314003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2744; H:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: G+NwCNN55MyXD6hcBtfNieiTnDYu5Ri8W0f7MDF5h4cEPh0715QOzaN+5mLWTZMp6DhhI+Z1sjZWw9PwNsZk3X3NmQmG9eUPnOql7dticDriKO72ksnEN8ZGSepwsf9M/Nj3xSR2oyQVgvAv/WQrpvzbuasRHGSvXGBl97CoIMGmZaQElJqfChk3in6i0zx4pYQ4X5LaLHhAKJMl556F/bqqbIg0kcaCWGucJU56IyYkFH/6Z5CpMNijPLOjHilZUwaOrc78e3yKJS/BA06U80dZ0yqC+qSJMI75KIYzHyAOLFV7Go6d1VZ/VpKlHzRD3UEhiy38968GF4zNVu36tT/mTtu5huAS2GgwQrw76P3YIUlXlWBoHMUCfkTSJ7oIpxL6NPD7u6jPIlkAr0xzjSSWXHpvc5v5Htax+LzTFrM= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c3ba0a3f-33b5-4419-37bf-08d6cee6d112 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 10:13:26.3074 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2744 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-02_05:, , signatures=0 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: <20190502101326.JS9HmWctSmChVrQ4UAKtBcRY_j7E49vSVDy7hV-dO8M@z> > -----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 extensi= on >=20 > > 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 _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 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 sur= e. > > >> > > >> 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 o= nly when > crypto intrinsics are used. However, when 'sha3' (part of 8.2 crypto) fla= g is The default image is 8.1 spec and except octeontx2 every other SoC is 8.1 a= nd For octeotx2 crypto is supported. If so, Should we worry this case? > enabled, compiler can generate 3-way exclusive OR instructions beyond the > intrinsics. The very same problem will be applicable for Linux kernel too for distribut= ion binary case. If the above statement is true about 8.2 crypto and crypto generation witho= ut Intrinsics then we need to see how linux kernel handling that and align our= solution based on that. > 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 Not sure how it helps? If we know the compiler is generating a specific fun= ction With crypto instruction then we can generate _alternative_ function for the= same With hwcap?.How do we know which function compiler using compiler instructi= ons? > 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. >=20 > [1] https://willnewton.name/2013/07/02/using-gnu-indirect-functions/ >=20 > > > > Thanks > > Yongseok