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 0AB56A0AC5 for ; Fri, 3 May 2019 16:21:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 88CBF5B36; Fri, 3 May 2019 16:21:37 +0200 (CEST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30067.outbound.protection.outlook.com [40.107.3.67]) by dpdk.org (Postfix) with ESMTP id CD5565B2C for ; Fri, 3 May 2019 16:21:36 +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=Z5nmLlUfJjBma9UQiaiL9fd3Hg+2v8UW95SJ6C1TZos=; b=S2593iQEp9uG2mpEywSbspZkRYfO1ckhlDWSQT34XS8QemKbqmUHj4VvyLzyFQCTD9cKM3zGKiqzZNZmgB2BQWhumc72G1kMuLTO8HpehHtCbPKk52TQMz7ZbBj6m8XaLKQoibP1cMqDoBUQGXy0hOoSbhPfLWVNxTI7XNiIJzY= Received: from VE1PR08MB5149.eurprd08.prod.outlook.com (20.179.30.152) by VE1PR08MB4639.eurprd08.prod.outlook.com (10.255.27.74) 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 14:21:34 +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 14:21:34 +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)" , nd , nd Thread-Topic: [EXT] [PATCH 5/6] build: add option for armv8 crypto extension Thread-Index: AQHU87skDqGgIb5/akCGo940k1lIHaY9pwyQgALmmoCAEyNQcIAEBvAAgADYnICAADrIEIAAeESAgABLkcA= Date: Fri, 3 May 2019 14:21:33 +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> <20190503094923.GB2510@mtidpdk.mti.labs.mlnx> In-Reply-To: <20190503094923.GB2510@mtidpdk.mti.labs.mlnx> 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: 21d525c6-2a8e-49e7-3368-08d6cfd2a522 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:VE1PR08MB4639; x-ms-traffictypediagnostic: VE1PR08MB4639: 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:9508; x-forefront-prvs: 0026334A56 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(396003)(346002)(376002)(39860400002)(189003)(199004)(5660300002)(6916009)(2501003)(229853002)(99286004)(66556008)(66476007)(81166006)(64756008)(66446008)(81156014)(1730700003)(54906003)(6246003)(8676002)(8936002)(73956011)(66946007)(7696005)(508600001)(45080400002)(52536014)(68736007)(9686003)(72206003)(5640700003)(966005)(76116006)(6306002)(6436002)(6506007)(76176011)(26005)(256004)(14444005)(14454004)(55016002)(446003)(11346002)(86362001)(4326008)(71200400001)(71190400001)(2906002)(66066001)(33656002)(486006)(186003)(53546011)(53936002)(305945005)(476003)(102836004)(316002)(2351001)(25786009)(7736002)(74316002)(6116002)(3846002)(6314003); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR08MB4639; 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: eePS1GK2IPgEiVWoMI5Vl9bHoi7W2CpzbK1rGWjF3PfbovKV2NeyoHOm9YVc5S5z4AH0h+QsytTzLs43rDB/mtxpvxxVO2AQKmU7MviZDF/5MKd9wIjp35MiM2QzspAgvqTTNLwnDSoDfOwY/gJWba6swmJjXsbgdzXwHd3z2Ecs1ghuT0E0CFj0fYA2HUgcAyBHO8UsH30ZzeYANW4zXODVJaChUFPHmYOkoEJpYG9hdgfiZr3720NrCXET5jifeIOzX87MKvJSK0LCL/ICgzNNxqDNioHvsCg0MBQIj35VCphvII6z4gT7n0fUvLJQTznO7HSKGnL236V9jNCSVTheCe1wgNa2H4NDHG0TvVPjWaAlfmvKobO6uaJPISYAOru+frdulJBGCqsCZhJjKksJAv/T50MW8qrJdTeaNeE= 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: 21d525c6-2a8e-49e7-3368-08d6cfd2a522 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2019 14:21:33.8726 (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: VE1PR08MB4639 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: <20190503142133.3pvhByWfI1zimoyZDxcCARtAmfhMNTtTWlNtQdDu8dI@z> > On Fri, May 03, 2019 at 03:54:09AM +0000, Honnappa Nagarahalli wrote: > > > >>> 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 fo= r > sure. > > > >>>>> > > > >>>>> Copied dpdk-on-arm ML. > > > >>>>> > > > >>>> I do not know the answer, will have to check with the compiler t= eam. > > > >>>> 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 th= is > case? > > 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 > corresponding support. > > > > > > > > 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 bu= ild > configs? > > I think it should be fine. But, this alone is not enough. The run time > > detection of the crypto feature and hooking up the correct pointers > > needs to be added. >=20 > Like Jerin pointed out above, armv8 cryptodev already has runtime check o= f > cpuflags. If there's no support, it returns error. Unless we need a fallb= ack > function with non-crypto instructions instead of returning error, I don't= think > such hookup of func pointers are needed. >=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]] > > > > > > 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 > > > > > > -MACHINE_CFLAGS +=3D -march=3Darmv8-a+crc+crypto > > > +MACHINE_CFLAGS +=3D -march=3Darmv8-a+crc > > > > > > > > > [1] > > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fg= c > > > c.gnu.org%2Fgcc- > 8%2Fchanges.html&data=3D02%7C01%7Cyskoh%40mellanox > > > .com%7C5cd398e4cf1e45c1755a08d6cf7b0091%7Ca652971c7d2e4d9ba > 6a4d14925 > > > > 6f461b%7C0%7C0%7C636924524543262594&sdata=3D4m4S2VQUVBML > YqpxmeLoAP > > > qAcKGm9u1Wo5R7oE2CK94%3D&reserved=3D0 > > > > > > Thanks, > > > Yongseok > > > > > > >> 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 > myself. > > > > > > > > > >> 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 > > function pointer to use at run time. If this feature is used, the > > function pointer to use is decided during dynamic linking stage. >=20 > I think what Jerin meant was about the case where compiler can generate > crypto instructions beyond intrinsics/asm like sha3 for 3-way exclusive O= R > instructions. In this case, such function pointer can't help as we can't = know > how compiler generates such instructions. >=20 > > Either ways, we need to have 2 sets of crypto PMD drivers. One that > > implements the actual functionality using crypto intrinsics/assembly. > > Only, this code 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. >=20 > Like I mentioned above, it may not be necessary. armv8 cryptodev links > external library, which is compiled separately (out of dpdk) with crypto > support and we don't have/need a fallback but returns error if no crypto > support in runtime. Ok, got it (did not realize crypto library is external to DPDK). >=20 > > > >> 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%= 2 > > > >> Fwil > > > >> lnewton.name%2F2013%2F07%2F02%2Fusing-gnu-indirect- > > > functions%2F&d > > > >> > > > > ata=3D02%7C01%7Cyskoh%40mellanox.com%7Cda8fb7ed03e7406ded8908d6c > > > ee6d759 > > > >> %7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C63692388 > 818 > > > 9316743& > > > >> > > > > sdata=3Dx5XNd5WZ3EtiprPMiFzaskvigX8K0AoXA2w%2BKiN156c%3D&res > > > erved=3D0