From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <Honnappa.Nagarahalli@arm.com>
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 <dev@dpdk.org>; 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 <Honnappa.Nagarahalli@arm.com>
To: "yskoh@mellanox.com" <yskoh@mellanox.com>
CC: "jerinj@marvell.com" <jerinj@marvell.com>, "bruce.richardson@intel.com"
<bruce.richardson@intel.com>, Pavan Nikhilesh Bhagavatula
<pbhagavatula@marvell.com>, Shahaf Shuler <shahafs@mellanox.com>,
"dev@dpdk.org" <dev@dpdk.org>, "thomas@monjalon.net" <thomas@monjalon.net>,
"Gavin Hu (Arm Technology China)" <Gavin.Hu@arm.com>, nd <nd@arm.com>, nd
<nd@arm.com>
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: <VE1PR08MB5149CB8559183A94A4F357EB98350@VE1PR08MB5149.eurprd08.prod.outlook.com>
References: <20190412232451.30197-1-yskoh@mellanox.com>
<20190412232451.30197-6-yskoh@mellanox.com>
<BYAPR18MB2424A615C597E9F8549F770BC8290@BYAPR18MB2424.namprd18.prod.outlook.com>
<8328F59C-14DF-412E-A8F7-6AA1F5061065@mellanox.com>
<VE1PR08MB514978C5F96EC8FA0934C79F982B0@VE1PR08MB5149.eurprd08.prod.outlook.com>
<3ACFB177-32B1-4AF9-BC60-DE1EBB4EC9C7@mellanox.com>
<VE1PR08MB514979EA9CDF07C6810A7183983A0@VE1PR08MB5149.eurprd08.prod.outlook.com>
<BYAPR18MB2424A606C4E9218775D71A5CC8340@BYAPR18MB2424.namprd18.prod.outlook.com>
<926D3AC3-CA01-410A-8E23-4AB6581FA594@mellanox.com>
<VE1PR08MB51491D19A8F2671652BF477398350@VE1PR08MB5149.eurprd08.prod.outlook.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: <VE1PR08MB4639902827FEBA2EEEB4BA2D98350@VE1PR08MB4639.eurprd08.prod.outlook.com>
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="us-ascii"
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 03 May 2019 14:21:37 -0000
> On Fri, May 03, 2019 at 03:54:09AM +0000, Honnappa Nagarahalli wrote:
> > > >>> On Apr 15, 2019, at 1:13 PM, Honnappa Nagarahalli
> > > >>> <Honnappa.Nagarahalli@arm.com> 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
From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by dpdk.space (Postfix) with ESMTP id 0AB56A0AC5
for <public@inbox.dpdk.org>; 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 <dev@dpdk.org>; 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 <Honnappa.Nagarahalli@arm.com>
To: "yskoh@mellanox.com" <yskoh@mellanox.com>
CC: "jerinj@marvell.com" <jerinj@marvell.com>, "bruce.richardson@intel.com"
<bruce.richardson@intel.com>, Pavan Nikhilesh Bhagavatula
<pbhagavatula@marvell.com>, Shahaf Shuler <shahafs@mellanox.com>,
"dev@dpdk.org" <dev@dpdk.org>, "thomas@monjalon.net" <thomas@monjalon.net>,
"Gavin Hu (Arm Technology China)" <Gavin.Hu@arm.com>, nd <nd@arm.com>, nd
<nd@arm.com>
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:
<VE1PR08MB5149CB8559183A94A4F357EB98350@VE1PR08MB5149.eurprd08.prod.outlook.com>
References: <20190412232451.30197-1-yskoh@mellanox.com>
<20190412232451.30197-6-yskoh@mellanox.com>
<BYAPR18MB2424A615C597E9F8549F770BC8290@BYAPR18MB2424.namprd18.prod.outlook.com>
<8328F59C-14DF-412E-A8F7-6AA1F5061065@mellanox.com>
<VE1PR08MB514978C5F96EC8FA0934C79F982B0@VE1PR08MB5149.eurprd08.prod.outlook.com>
<3ACFB177-32B1-4AF9-BC60-DE1EBB4EC9C7@mellanox.com>
<VE1PR08MB514979EA9CDF07C6810A7183983A0@VE1PR08MB5149.eurprd08.prod.outlook.com>
<BYAPR18MB2424A606C4E9218775D71A5CC8340@BYAPR18MB2424.namprd18.prod.outlook.com>
<926D3AC3-CA01-410A-8E23-4AB6581FA594@mellanox.com>
<VE1PR08MB51491D19A8F2671652BF477398350@VE1PR08MB5149.eurprd08.prod.outlook.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: <VE1PR08MB4639902827FEBA2EEEB4BA2D98350@VE1PR08MB4639.eurprd08.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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
> > > >>> <Honnappa.Nagarahalli@arm.com> 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