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 ED82DA0AC5 for ; Fri, 3 May 2019 12:28:29 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7A9684D27; Fri, 3 May 2019 12:28:11 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 19F4F325F for ; Fri, 3 May 2019 12:28:09 +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 x43AFL8P014246; Fri, 3 May 2019 03:28:05 -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=jNyZ/MO0/JLXYt+3/MvNyKidjqS9/a3Gls/0kF65vKI=; b=BM86Zk+Ngxf2/HYIPZClRhLPBQIJd0e7czOqdYTnmOVGCCdJMjhEoMNEiY2hoxb/KZWO z/dWKxgWoZKYzUay5jGQ8DAywPfqATwGyYkXVoLuc6VioyHDfMIS+MPnAKT3vkKW0Yll CYSbPWgT3nUD2bb7o2IpSpNGyxq2SbursG8u5z1aKpqPK3SUEZC2FVNLsd8UOpcK5jx6 QxdwlFizfNqZCny4O68jM+xnaWNPrW/D0vG6ty563BVQ919l6wWn/mlfAcaxWrV8sUXF VGQEZaqeZG3ogVz8cn/ES7Z/7Cpab2T+M+0JENWo2QSGtL2Xe3ObqdF96GmhDZsnMXqB wA== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0b-0016f401.pphosted.com with ESMTP id 2s89rk9scq-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 03 May 2019 03:28:05 -0700 Received: from SC-EXCH02.marvell.com (10.93.176.82) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 3 May 2019 03:28:03 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (104.47.40.55) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Fri, 3 May 2019 03:28:03 -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=jNyZ/MO0/JLXYt+3/MvNyKidjqS9/a3Gls/0kF65vKI=; b=B7yrfS39isIklNrxItoN2TYfvTIkCXlUES4I6zzeNCnhRd5XdOLrVhcyBh9ftd/I+fxfYF4v8YhaDeHi6PHeKb+A+j9OLvy3uPFKz2JF5OIqlih3Xbsfd5u6q0BLE8mZTPvTRm9QW6qHJBQ57dyUS6Z/n2OBBhpW4J2xxb6yeRw= Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by BYAPR18MB2695.namprd18.prod.outlook.com (20.178.207.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.12; Fri, 3 May 2019 10:28:02 +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; Fri, 3 May 2019 10:28:02 +0000 From: Jerin Jacob Kollanukkaran To: Yongseok Koh 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: AQHVAT91az0EDTnq3ESYrU9sv1ccqqZZMvcA Date: Fri, 3 May 2019 10:28:02 +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> <76A4CB8C-4429-492D-8885-54B30C64165F@mellanox.com> In-Reply-To: <76A4CB8C-4429-492D-8885-54B30C64165F@mellanox.com> 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: 219e5cd3-77bb-4883-a9c4-08d6cfb2058c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR18MB2695; x-ms-traffictypediagnostic: BYAPR18MB2695: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0026334A56 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(136003)(366004)(396003)(376002)(199004)(189003)(13464003)(6506007)(53546011)(53936002)(55236004)(71200400001)(71190400001)(102836004)(86362001)(81156014)(81166006)(25786009)(54906003)(9686003)(26005)(4326008)(6916009)(256004)(2906002)(14444005)(7696005)(74316002)(186003)(6246003)(3846002)(6116002)(5660300002)(305945005)(7736002)(76176011)(76116006)(66476007)(66556008)(64756008)(66446008)(52536014)(99286004)(229853002)(66946007)(73956011)(55016002)(6436002)(478600001)(33656002)(8936002)(68736007)(476003)(486006)(14454004)(66066001)(316002)(446003)(11346002)(6314003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2695; H:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: 2GVyuTL9vj/MM58jM5U85tKb21KOBE7H1QplBcwDdV1tXUjg2Kxf/Eq4YwXjuBJtt832J/Md01zbZml3GRnaRH10YFw9y9ZH2XEVilNNonCBkACQvhKoS+J7J0cMQTkr3m3CY8WfbDKvGCU+zQdFFOHrARneX3LQtCxxWqi/fWKhXTwaqiIh3o/WxR0cUqvHkXYXhE+F93uH1Z4KsxfnocpJEfYSIa46NiOqEOSRgFu4i4k0y63GZU6QUVrLYNY00aB9cQg3p/kQ9ydTe3NEDnZblm7hZ08QyJtmwh0jAk+LkIw5ziuoQfhtvb0sCKiXClGHavxz6lpYKjKI2hnPMKaOmoP/FKyRyKJy6ggFC+YFhpTkjBZ+/XcKMEkVaghT8UUfKkbUZ6bvr9cwcHqwNlIlkhwvh12a79Km9PPQyno= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 219e5cd3-77bb-4883-a9c4-08d6cfb2058c X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2019 10:28:02.2055 (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: BYAPR18MB2695 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-03_04:, , 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: <20190503102802.5a8G74PjJuJBViwnoGb84S9jWWOal418NRdiqaKO_pw@z> > -----Original Message----- > From: Yongseok Koh > Sent: Friday, May 3, 2019 5:03 AM > 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 > Subject: Re: [dpdk-dev] [EXT] [PATCH 5/6] build: add option for armv8 cry= pto > extension >=20 >=20 > > On May 2, 2019, at 4:08 PM, Yongseok Koh wrote: > > > >> > >> On May 2, 2019, at 3:13 AM, Jerin Jacob Kollanukkaran > wrote: > >> > >>> -----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 > >>> extension > >>> > >>>> 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 _option= al_. > >>>>>>> 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 fl= ag. > >>>>>>> > >>>>>>> Do you see any issues with that approach? > >>>>>> > >>>>>> I also thought about that approach and that was my number 1 priori= ty. > >>>>>> 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 s= ure. > >>>>>> > >>>>>> 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 > >> 8.1 and For octeotx2 crypto is supported. If so, Should we worry this = case? > > > > 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 release note [1], currently '+crypto' implies '+aes' and '+sha2' > > while '+sha3' and '+sm4' 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 disable it from armv8=20 build configs? +1 Yes. Simply disable crypto would be enough for DPDK.