From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 09D9A201 for ; Tue, 13 Nov 2018 01:30:30 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 838BA2226C; Mon, 12 Nov 2018 19:30:29 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 12 Nov 2018 19:30:29 -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=SjXyGf6LZyrj6zvx697gbx6I63APJqnQK5Vo2iqg0G4=; b=EvqZ1wtlQnuC ghaATJsUIRSzAcSuU2AK45QdKjZis7pTYZJOw8tUYTRbqlOWIJDP268MNGSceXk+ aBNxJrL+oQseRbiWOhaD+0kEe1bjlX3ld5Yqv/tV2DVMnJ+tmJ95KB9o6quwvbBB xwaf8u1K3YIN5vGl2FOq8Nho01oyYHc= 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=SjXyGf6LZyrj6zvx697gbx6I63APJqnQK5Vo2iqg0 G4=; b=VfELex58+l/w5fzVax3I9EHymUtY7nvAxwFDV+AY7t5A6fDde54CtK4Qa 0Em+12yutm+BCjUM5frr9T731XWJUZOe9vyKDXv8wu+f4dZEzzABgGPjS9OrzyqJ BY33ActrWgbqNvv9+COsbz9Eq9tXE/sYZfiLebtlreiey+vdNLL6tdxnVya43XNs x6NDVOAsbsBTwxx9EIqb2q/QNgVA8KZc8uTrsIbHtWv4fTQvGAHt1CI7cBU5AaK6 fnuMZ/97pfMKRXEvk54ez0zOwdMtWMdwM8+VZkjMbGRjMvlTXIsbo/0be/fACmQN G9ZzLkX5kYhyDfqVMfa35AefiEzgQ== X-ME-Sender: 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 AFDC5E4678; Mon, 12 Nov 2018 19:30:27 -0500 (EST) From: Thomas Monjalon To: Stephen Hemminger Cc: dev@dpdk.org, yskoh@mellanox.com, shahafs@mellanox.com, ferruh.yigit@intel.com, bruce.richardson@intel.com, konstantin.ananyev@intel.com, christian.ehrhardt@canonical.com, justin.parus@microsoft.com Date: Tue, 13 Nov 2018 01:30:26 +0100 Message-ID: <3466805.ZzxQIDAxy8@xps> In-Reply-To: References: <20181113000122.12594-1-thomas@monjalon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] net/mlx5: restrict workaround of gcc AVX512F bug 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: Tue, 13 Nov 2018 00:30:30 -0000 13/11/2018 01:14, Stephen Hemminger: > On Mon, Nov 12, 2018, 4:01 PM Thomas Monjalon > > A bug was found when the inline function mlx5_tx_complete() > > is optimized with AVX512F instructions. It corrupts an offset > > in the instructions vmovdqu8 of the AVX2 version of rte_mov128(), > > used in rte_memcpy(), which is called in rte_mempool_put_bulk(). > > > > All the above functions are inline. So the workaround is > > to disable AVX512F optimization for the functions calling the > > top-level function of this call stack, i.e. mlx5_tx_complete(). > > All GCC versions supporting AVX512 are supposed to be affected. > > > > The root cause is not identified yet. It may be thought that > > more related bugs may happen in other functions. > > That's why the initial workaround was to disable AVX512F globally. > > This patch takes the risk of applying the workaround only for the > > functions known to be affected, in order to preserve the optimization > > everywhere else. > > > > Bugzilla ID: 97 > > Fixes: 8d07c82b239f ("mk: disable gcc AVX512F support") > > > > Signed-off-by: Thomas Monjalon > > The additional annotations clutter the code. > How big a performance hit is it to disable for whole driver? Or just use > memcpy instead of rte_memcpy? rte_memcpy() is used via rte_mempool_put_bulk(). I am not going to change it to memcpy... About disabling AVX512F for the whole driver, the goal of this patch is to reduce the scope of the workaround. If a per-function scope is not chosen, then we can stay with a global safe scope. If you are interested to know more, the bugzilla has tons of infos: https://bugs.dpdk.org/show_bug.cgi?id=97 Given that we don't get much help on this major GCC bug, we are probably going to stay on the safe side. Anyway I must stop working (alone) on this bug, and instead, focus on making 18.11 out.