From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <yskoh@mellanox.com>
Received: from EUR01-VE1-obe.outbound.protection.outlook.com
(mail-ve1eur01on0051.outbound.protection.outlook.com [104.47.1.51])
by dpdk.org (Postfix) with ESMTP id 377C21B136;
Sat, 3 Nov 2018 00:31:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com;
s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=sKjkbYsOkxIrYlAY1p9z6+VzCarmp0Rndmzt73E1Un4=;
b=Tlhqfr7eqZlNc5N+PGZ1nilIRNUYLQV/wuyFuXAUtP97lbNkZrORWnH3ry75GLqf2maDLXqDWPRrd/zalju85m8wHk8UpaIrvcnwnitfTSVCjFgs3eoXXetTl5TGHHxCqJk84qRnGiYF3lJV9ifAo/Rwb3+NGNlUkl1MY9nvpZk=
Received: from AM0PR0502MB3971.eurprd05.prod.outlook.com (52.133.40.151) by
AM0PR0502MB3779.eurprd05.prod.outlook.com (52.133.47.25) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.1273.26; Fri, 2 Nov 2018 23:31:37 +0000
Received: from AM0PR0502MB3971.eurprd05.prod.outlook.com
([fe80::cdde:1e48:5899:c509]) by AM0PR0502MB3971.eurprd05.prod.outlook.com
([fe80::cdde:1e48:5899:c509%5]) with mapi id 15.20.1273.030; Fri, 2 Nov 2018
23:31:37 +0000
From: Yongseok Koh <yskoh@mellanox.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
CC: Thomas Monjalon <thomas@monjalon.net>, "bruce.richardson@intel.com"
<bruce.richardson@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, Shahaf Shuler
<shahafs@mellanox.com>, "stable@dpdk.org" <stable@dpdk.org>, Konstantin
Ananyev <konstantin.ananyev@intel.com>, Anatoly Burakov
<anatoly.burakov@intel.com>
Thread-Topic: [dpdk-stable] [PATCH] build: disable compiler AVX512F support
Thread-Index: AQHUaxajIqJF1GRaIEuSbF5cO+4UK6U8fNqAgAASW4CAAAMlAIAAgmaAgAAdZgA=
Date: Fri, 2 Nov 2018 23:31:37 +0000
Message-ID: <20181102233115.GD15737@mtidpdk.mti.labs.mlnx>
References: <20181023212318.43082-1-yskoh@mellanox.com>
<df9a31b9-435a-faf0-5693-93589441ccfa@intel.com>
<3a34ea82-fbdf-2ebd-c6d9-9713bfadefb8@intel.com>
<20181102205926.GA15737@mtidpdk.mti.labs.mlnx>
<f3a8112e-d3e8-2cce-9894-bb2fdce96ede@intel.com>
In-Reply-To: <f3a8112e-d3e8-2cce-9894-bb2fdce96ede@intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: BYAPR08CA0022.namprd08.prod.outlook.com
(2603:10b6:a03:100::35) To AM0PR0502MB3971.eurprd05.prod.outlook.com
(2603:10a6:208:11::23)
authentication-results: spf=none (sender IP is )
smtp.mailfrom=yskoh@mellanox.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [209.116.155.178]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR0502MB3779;
6:gzaTpxCmO00z0bGgtHoLMSSJvlV2rb0oMKGu5JRnfuz2QM6WbN+obSCwrZjWrU79nkX2kNdSprwfzKf38xIWXUeQZTYwBbqW1XPt5T1I1k2dV8Vf8FyN/ncNbEpuDg35+kxORJzZnCQuhHlxojHM23jzIrLPdGyeU1vs6RNd1z7BjbI0J0kg18vdditMXKoGaevUEDuq76pD5tbpv55AfdS8DRlFulGf8qQ4wnWhAlveV/GAWUUhigSsDNcPVIDOpwsg0c5FeiQaZbM+JoY6hgVJzacSue0P5md17jVDp/fv11tuM17uXfZpHoNobLKjGmrED8O22jHDkZi3ZVgHt3zUwoPI83xT51ndwSMCvQl7BOqA0+1NhoJ3B3nwBxrHLG8q6+DRzfVCEyC7fCiYj7bq5C9E44AUS0+ly6j/glJtgQVLsoZnP73h2tnSYZBPp6Iyr/fIVRXPV2haU3DLFA==;
5:3JKWiAREpScAwpuKuh82jSBcHI4i6OO8g8FwtAllRQ5izE/0j7pSbx5hXgXJKENS5YqMyQYgYt+FFsphoEeicjypl1VyPjFwBZSggGygx2HcCpkiYhbbnud4QqgQ/QjB9m7I+WXbmV7WrFPuRpTLwqzaJ4KxCwmFihE7D7/1cwM=;
7:Ty5mBbVUbbnx0W4nB0D4HYKs6Tu1mWuwldd9pWZgjHIIP6drXJs77YfTN22QSEoBpH9cILJhEJfn/F1YVqbmP3wteiFD9zVh0mTiNOwhr3wTT78jHEcJ7w2tZc6zh7iSXKBhrh1+x1QI1n7tu00oyg==
x-ms-office365-filtering-correlation-id: 17f3c4f0-aa27-4e32-919b-08d6411b5560
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0;
RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020);
SRVR:AM0PR0502MB3779;
x-ms-traffictypediagnostic: AM0PR0502MB3779:
x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr
x-microsoft-antispam-prvs: <AM0PR0502MB37797476917FA0E0CF9AC570C3CF0@AM0PR0502MB3779.eurprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095);
SRVR:AM0PR0502MB3779; BCL:0; PCL:0; RULEID:; SRVR:AM0PR0502MB3779;
x-forefront-prvs: 08444C7C87
x-forefront-antispam-report: SFV:NSPM;
SFS:(10009020)(136003)(366004)(396003)(39860400002)(346002)(376002)(199004)(189003)(305945005)(33656002)(52116002)(2906002)(68736007)(66066001)(6436002)(99286004)(7736002)(229853002)(6486002)(14444005)(14454004)(106356001)(256004)(81166006)(97736004)(53936002)(81156014)(8676002)(6512007)(9686003)(25786009)(8936002)(105586002)(26005)(5660300001)(11346002)(6916009)(386003)(1076002)(316002)(54906003)(53546011)(575784001)(4326008)(86362001)(6246003)(446003)(6116002)(3846002)(2900100001)(71190400001)(33896004)(76176011)(71200400001)(478600001)(6506007)(102836004)(186003)(486006)(93886005)(476003)(21314003);
DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR0502MB3779;
H:AM0PR0502MB3971.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en;
PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: mellanox.com does not designate
permitted sender hosts)
x-microsoft-antispam-message-info: 2YAUXx9MYMoobqitikvh5FyxHphAexLDwwQSbPiufDCH0TLdtOraQQzXX14N5fD+CswEJuMVkNLkNuvIFpeUIcCG7pApuYrZkk5J5qxqMOpG2joI/WplUuaAHyVh3hMigCYgnQQWy+P/xaEQLNZ13M1OU7F78hdiFMBXM4p4boT73z1B1ABUujr54DaMpjKQuaxcePXU3MncsLcpFRBVvUN1bmkBNwbyMvFXvyn9hBejbHDWj7s3B4cPpJfNuWQ29nbI5EV2n+5D+CCKKsHcgZXhUk0WkfWRdMZvykUWGPKvJjk2jlfDMUW98XghqTBIhZWSiQm2bosLuQC9chq/iFXxPyj08qB8GbDbrCpPZqI=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E429DC5D70C99F438CF91C595214F18D@eurprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: Mellanox.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 17f3c4f0-aa27-4e32-919b-08d6411b5560
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2018 23:31:37.7662 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0502MB3779
Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] build: disable compiler
AVX512F support
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, 02 Nov 2018 23:31:39 -0000
On Fri, Nov 02, 2018 at 09:46:09PM +0000, Ferruh Yigit wrote:
> On 11/2/2018 8:59 PM, Yongseok Koh wrote:
> > On Fri, Nov 02, 2018 at 01:48:11PM +0000, Ferruh Yigit wrote:
> >> On 11/2/2018 12:42 PM, Ferruh Yigit wrote:
> >>> On 10/23/2018 10:23 PM, Yongseok Koh wrote:
> >>>> This is a workaround to prevent a crash, which might be caused by
> >>>> optimization of newer gcc (7.3.0) on Intel Skylake.
> >>>>
> >>>> Bugzilla ID: 97
> >>>
> >>> After checking the defect description again, this is the issue observ=
ed in
> >>> rte_memcpy() implementation for AVX2, compiler uses AVX512F instructi=
ons while
> >>> compiling it which causes the failure, so this may be a compiler defe=
ct but we
> >>> don't know the root cause yet.
> >>
> >> Is the issue only with gcc, and only with specific version of gcc?
> >> If so can we reduce the disabling avx512 only to that gcc version?
> >>
> >>>
> >>> I think best solution is to find the root cause and fix either avx2
> >>> implementation or compiler, but this seems won't be soon, at least fo=
r rc2.
> >>>
> >>> What this patch does is to prevent compiler to use avx512f instructio=
n when
> >>> "CONFIG_RTE_ENABLE_AVX512=3Dn".
> >>>
> >>> Concern is this will affect all DPDK generated code for x86, but sinc=
e
> >>> rte_memcpy() in header file there is no way to disable using avx512f
> >>> instructions locally for rte_memcpy().
> >>> I can't think of any other solution for now, so OK to go with this pa=
tch for
> >>> now. Please find below comment.
> >>>
> >>>>
> >>>> Cc: stable@dpdk.org
> >>>>
> >>>> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> >>>> ---
> >>>> config/x86/meson.build | 5 +++++
> >>>> mk/rte.cpuflags.mk | 5 +++++
> >>>> 2 files changed, 10 insertions(+)
> >>>>
> >>>> diff --git a/config/x86/meson.build b/config/x86/meson.build
> >>>> index 33efb5e547..e10ba872ac 100644
> >>>> --- a/config/x86/meson.build
> >>>> +++ b/config/x86/meson.build
> >>>> @@ -47,6 +47,11 @@ endif
> >>>> if cc.get_define('__AVX512F__', args: march_opt) !=3D ''
> >>>> dpdk_conf.set('RTE_MACHINE_CPUFLAG_AVX512F', 1)
> >>>> compile_time_cpuflags +=3D ['RTE_CPUFLAG_AVX512F']
> >>>> +else
> >>>> +# disable compiler's AVX512F support as a workaround for Bug 97
> >>>> + if cc.has_argument('-mavx512f')
> >>>> + machine_args +=3D '-mno-avx512f'
> >>>> + endif
> >>>> endif
> >>>> =20
> >>>> dpdk_conf.set('RTE_CACHE_LINE_SIZE', 64)
> >>>> diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk
> >>>> index 43ed84155b..8fdb0cc2c3 100644
> >>>> --- a/mk/rte.cpuflags.mk
> >>>> +++ b/mk/rte.cpuflags.mk
> >>>> @@ -68,6 +68,11 @@ endif
> >>>> ifneq ($(filter $(AUTO_CPUFLAGS),__AVX512F__),)
> >>>> ifeq ($(CONFIG_RTE_ENABLE_AVX512),y)
> >>>> CPUFLAGS +=3D AVX512F
> >>>> +else
> >>>> +# disable compiler's AVX512F support as a workaround for Bug 97
> >>>> +ifeq ($(shell $(CC) --target-help | grep -q mavx512f && echo 1), 1)
> >>>
> >>> This will not work for ICC, and do we need this? AUTO_CPUFLAGS alread=
y should
> >>> have what you are looking for, so I think this check can be removed.
> >=20
> > This is different from AUTO_CPUFLAGS as it tries to check compiler flag=
support.
>=20
> What AUTO_CPUFLAGS does?
>=20
> It is output of `cc -march=3Dxxx -dM -E - < /dev/null`, which list define=
d macros
> for that specific march provided.
>=20
> Like if you use `-march=3Dcorei7` you won't see __AVX2__ set.
>=20
> And for `native`, if compiler doesn't support AVX2, I assume it won't abl=
e to
> output __AVX2__
>=20
> Is there a case AUTO_CPUFLAGS has __AVX512F__ but "$(CC) --target-help" d=
oesn't
> have `mavx512f`?
Right. For some reason, I have wrong impression that the flag grabs cpuflag=
s of
the compile host. Will submit a new version.
> > And per your question, I have only tested it with gcc, so I agree on ap=
plying it
> > only for gcc. Will submit v2. But, I don't think we need to check gcc v=
ersion as
> > there's no fix reported yet in a newer gcc version and this patch would=
have
> > very limited impact. avx512f support is quite new and kinda experimenta=
l so
> > far. Dropping a bit of performance would be better than crash. :-)
> >=20
> > Thanks for your review,
> > Yongseok
> >=20
> >>>> +MACHINE_CFLAGS +=3D -mno-avx512f
> >>>> +endif
> >>>> endif
> >>>> endif
> >>>> =20
> >>>>
> >>>
> >>
>=20