From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 9C8426CD8; Mon, 14 Jan 2019 12:55:46 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0AECB2AA87; Mon, 14 Jan 2019 06:55:46 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 14 Jan 2019 06:55:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=vj1SZmOFwT+PmI+VoshYaW0WCfsC2GrqErs+xYe8xgc=; b=p1RmVPenHXxy tjWX1ZfLrYsHOKI9Vb6MT+b2sY1hhpH8n5HSvkebMyU4zmGtj2eKjQ/twVaazT4G DcxMO3kW1S5oOc4QuOF/uV0lTULZko/D5a+Ivy+ljeYcd6+nmRHAQ+FD8jQO9eTj tumaB5bpIyKHM9TVW8/b0SymocOUw9M= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=vj1SZmOFwT+PmI+VoshYaW0WCfsC2GrqErs+xYe8x gc=; b=abZZ+OCuf6QgTaOzm0q5wLLwwLsGDtFXC6RE+BxkIdlQGUP3niwUlITbs mStqMVTJtDoqPH5thtiSnGiNL9qTqBOFd/MJEwJghtkWoedWV4vGHBB13/uP2R0y 3EBhpbkWTOIgxtiG9Csv3tW2J0sk3R92fRRgTxzB6CtikpGYaU+Pksl2qVg/gPz5 QmIbAXHL9xg+MlvVHnN9s8a0WL4iIYvEdMtQHMPzFPirHRKoR5oSmavFaKMzdtqk sf/hK6GDu14Q9TXf3ZJ0wGJjOHxuHftrl33f2+SEB3oentNAEagzTACFtVUfJqKt sjb5B3Kb/PaSXTl24sKEg2N7KhpHQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgedugdefgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffkfgjfh gggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceo thhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuffhomhgrihhnpeguphgukhdroh hrghdpthhoohhltghhrghinhdqtghomhhprghtrdhmkhdpghhnuhdrohhrghenucfkphep jeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomh grshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 3224E1026D; Mon, 14 Jan 2019 06:55:43 -0500 (EST) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, John McNamara , Marko Kovacevic , stable@dpdk.org, Tom Barbette , Yongseok Koh , Konstantin Ananyev , Bruce Richardson , Vipin Varghese Date: Mon, 14 Jan 2019 12:55:42 +0100 Message-ID: <1573462.QHEBVEx1sm@xps> In-Reply-To: <20190107164942.88785-1-ferruh.yigit@intel.com> References: <20190103162313.85623-1-ferruh.yigit@intel.com> <20190107164942.88785-1-ferruh.yigit@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v4] mk: fix scope of disabling AVX512F support 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: , X-List-Received-Date: Mon, 14 Jan 2019 11:55:46 -0000 Hi, Few details reviewed below, 07/01/2019 17:49, Ferruh Yigit: > --- a/doc/guides/rel_notes/known_issues.rst > +++ b/doc/guides/rel_notes/known_issues.rst > +AVX-512 support disabled > +------------------------ > + > +**Description**: > + ``AVX-512`` support has been disabled on some conditions. > + This shouldn't be confused with ``CONFIG_RTE_ENABLE_AVX512`` config option which is already > + disabled by default. This config option defines if ``AVX-512`` specific implementations of > + some file to be used or not. What has been disabled is compiler feature to produce ``AVX-512`` > + instructions from any source code. > + > + On DPDK v18.11 ``AVX-512`` disabled for all ``GCC`` builds which reported to cause a performance > + drop. *is* disabled > + > + On DPDK v19.02 ``AVX-512`` disable scope reduced to ``GCC`` and ``binutils version 2.30`` based *is* reduced > + on information accured from the GCC community defect. > + > +**Reason**: > + Generated ``AVX-512`` code cause crash: > + https://bugs.dpdk.org/show_bug.cgi?id=97 > + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88096 > + > +**Resolution/Workaround**: > + Update ``binutils`` to newer version than ``2.30``. > + Use different compiler, like ``clang`` for this case. These are 2 possible workarounds. Should we say "Or" ? > + > +**Affected Environment/Platform**: > + ``GCC`` and ``binutils version 2.30``. > --- a/doc/guides/rel_notes/release_19_02.rst > +++ b/doc/guides/rel_notes/release_19_02.rst > @@ -276,6 +276,19 @@ Known Issues > Also, make sure to start the actual text at the margin. > ========================================================= > > +* ``AVX-512`` support has been disabled for ``GCC`` builds when ``binutils 2.30`` > + is detected [1] because of a crash [2]. This can affect ``native`` machine type > + build targets on the platforms that support ``AVX512F`` like ``Intel Skylake`` > + processors, and can cause a possible performance drop. The immediate workaround > + is to use ``clang`` compiler on these platforms. > + Initial workaround in DPDK v18.11 was to disable ``AVX-512`` support for ``GCC`` > + completely, but based on information on defect submitted to GCC community [3], > + issue has been identified as ``binutils 2.30`` issue. Since currently only GCC > + generates ``AVX-512`` instructions, scope limited to ``GCC`` and ``binutils 2.30`` *the* scope *is* limited > + > + - [1]: Commit ("mk: fix scope of disabling AVX512F support") > + - [2]: https://bugs.dpdk.org/show_bug.cgi?id=97 > + - [3]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88096 > Space missing here > Tested Platforms > ---------------- > --- a/mk/toolchain/gcc/rte.toolchain-compat.mk > +++ b/mk/toolchain/gcc/rte.toolchain-compat.mk > +LD_VERSION = $(shell $(LD) -v) > +# disable AVX512F support for GCC & binutils 2.30 as a workaround for Bug 97 > +ifneq ($(filter 2.30%,$(LD_VERSION)),) > +FORCE_DISABLE_AVX512 := y > +# print warning only once for librte_eal > +ifneq ($(filter %librte_eal,$(lastword $(CURDIR))),) Do we need lastword for CURDIR?