From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <prvs=2025ea45be=jerinj@marvell.com>
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com
[67.231.156.173]) by dpdk.org (Postfix) with ESMTP id EBC1E29CB
for <dev@dpdk.org>; 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 <jerinj@marvell.com>
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>, "yskoh@mellanox.com"
<yskoh@mellanox.com>
CC: "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: AQHU8YcCJBMTHcCzhkWYreJI0p1ieaY5q2zggAPnzwCAABj/AIAC5dWAgBOV8gCAA5D2wA==
Date: Thu, 2 May 2019 10:13:26 +0000
Message-ID: <BYAPR18MB2424A606C4E9218775D71A5CC8340@BYAPR18MB2424.namprd18.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>
In-Reply-To: <VE1PR08MB514979EA9CDF07C6810A7183983A0@VE1PR08MB5149.eurprd08.prod.outlook.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: 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: <BYAPR18MB27449007DBB749388129B33CC8340@BYAPR18MB2744.namprd18.prod.outlook.com>
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="us-ascii"
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 <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: Thu, 02 May 2019 10:13:34 -0000
> -----Original Message-----
> From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Sent: Tuesday, April 30, 2019 9:04 AM
> To: yskoh@mellanox.com
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> bruce.richardson@intel.com; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Shahaf Shuler <shahafs@mellanox.com>;
> dev@dpdk.org; thomas@monjalon.net; Gavin Hu (Arm Technology China)
> <Gavin.Hu@arm.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>; nd <nd@arm.com>
> 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
> > <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 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
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 B490FA0AC5
for <public@inbox.dpdk.org>; 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 <dev@dpdk.org>; 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 <jerinj@marvell.com>
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>, "yskoh@mellanox.com"
<yskoh@mellanox.com>
CC: "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: AQHU8YcCJBMTHcCzhkWYreJI0p1ieaY5q2zggAPnzwCAABj/AIAC5dWAgBOV8gCAA5D2wA==
Date: Thu, 2 May 2019 10:13:26 +0000
Message-ID:
<BYAPR18MB2424A606C4E9218775D71A5CC8340@BYAPR18MB2424.namprd18.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>
In-Reply-To: <VE1PR08MB514979EA9CDF07C6810A7183983A0@VE1PR08MB5149.eurprd08.prod.outlook.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: 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: <BYAPR18MB27449007DBB749388129B33CC8340@BYAPR18MB2744.namprd18.prod.outlook.com>
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 <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: <20190502101326.JS9HmWctSmChVrQ4UAKtBcRY_j7E49vSVDy7hV-dO8M@z>
> -----Original Message-----
> From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Sent: Tuesday, April 30, 2019 9:04 AM
> To: yskoh@mellanox.com
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> bruce.richardson@intel.com; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Shahaf Shuler <shahafs@mellanox.com>;
> dev@dpdk.org; thomas@monjalon.net; Gavin Hu (Arm Technology China)
> <Gavin.Hu@arm.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>; nd <nd@arm.com>
> 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
> > <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 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