From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 008CDA0562; Tue, 31 Mar 2020 03:46:52 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 799CE1C065; Tue, 31 Mar 2020 03:46:51 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 21CFF1C033; Tue, 31 Mar 2020 03:46:49 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5EC0B5C004E; Mon, 30 Mar 2020 21:46:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 30 Mar 2020 21:46:48 -0400 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=oRjyW6kYDsBk6By4rNu9fOIVWqKpa81s7ANGUVLh9dI=; b=R8vPskJwluLa pMXe58fQLJ+ml4jhFha11E88xyAw3EfONrdp9j5MVRMEfybDbCzpD3s65QLTYMD1 Qkix4J0lRLKwGnBIkfCZnUl/ISkT6gFJMU+nJzttgmDgxp20hEE/gu0ilqsAl9ea 7D1Jq30QyAo7Fvi+wS4wxx+Cm9/qMlg= 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=fm2; bh=oRjyW6kYDsBk6By4rNu9fOIVWqKpa81s7ANGUVLh9 dI=; b=CkOeSFSt+VcY9U0Aa/vXHosiO7YLA6TeeF1if1y9GpAyU9dgrmaaGNzxf Ns2LC6jIfKsUwFTbYGfD3QKDpHtvpzybRvxPaeMa8fWH+gQ9jGSvG32Bk2x6EMMH K+7khawLlYdq0pPTNFO+xMBQMnCE73lFhhtt77QoL2ppnTqwRLlvCeZX5O1KThSB 3tfTv6ZYwteVqHjH3JjHdiEJ29sVCV9y3j3yZyejsOHgYcu02ohVVc9UslPYxNS0 asglHwHLy6KskVtYny15RdjSBDLf8Fb1v7GVr+Gm5FLfY2IBNMKFaLYu/z6PYuf1 E/pFjojMHUlh95tx46cBmM/sz+kXg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeiiedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght 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 A85F1328005D; Mon, 30 Mar 2020 21:46:46 -0400 (EDT) From: Thomas Monjalon To: Alexander Kozyrev Cc: stable@dpdk.org, dev@dpdk.org, viacheslavo@mellanox.com, matan@mellanox.com, stable@dpdk.org, Olivier Matz Date: Tue, 31 Mar 2020 03:46:45 +0200 Message-ID: <3368517.MVdQ21Qd56@xps> In-Reply-To: <20200327081314.GD6327@platinum> References: <1584383500-27482-1-git-send-email-akozyrev@mellanox.com> <1584719715-17818-1-git-send-email-akozyrev@mellanox.com> <20200327081314.GD6327@platinum> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v2] mbuf: optimize memory loads during mbuf freeing 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 27/03/2020 09:13, Olivier Matz: > On Fri, Mar 20, 2020 at 03:55:15PM +0000, Alexander Kozyrev wrote: > > Introduction of pinned external buffers doubled memory loads in the > > rte_pktmbuf_prefree_seg() function. Analysis of the generated assembly > > code shows unnecessary load of the pool field of the rte_mbuf structure. > > Here is the snippet of the assembly for "if (!RTE_MBUF_DIRECT(m))": > > Before the change the code was: > > movq 0x18(%rbx), %rax // load the ol_flags field > > test %r13, %rax // check if ol_flags equals to 0x60...0 > > jz 0x9a8718 // jump out to "if (m->next != NULL)" > > After the change the code became: > > movq 0x18(%rbx), %rax // load ol_flags > > test %r14, %rax // check if ol_flags equals to 0x60...0 > > jnz 0x9bea38 // jump in to "if (!RTE_MBUF_HAS_EXTBUF(m)" > > movq 0x48(%rbx), %rax // load the pool field > > jmp 0x9bea78 // jump out to "if (m->next != NULL)" > > Look like this absolutely unneeded memory load of the pool field is an > > optimization for the external buffer case in GCC (4.8.5), since Clang > > generates the same assembly for both before and after the change versions. > > Plus, GCC favors the external buffer case over the simple case. > > This assembly code layout causes the performance degradation because the > > rte_pktmbuf_prefree_seg() function is a part of a very hot path. > > Workaround this compilation issue by moving the check for pinned buffer > > apart from the check for external buffer and restore the initial code > > flow that favors the direct mbuf case over the external one. > > > > Fixes: 6ef1107ad4c6 ("mbuf: detach mbuf with pinned external buffer") > > Cc: stable@dpdk.org > > > > Signed-off-by: Alexander Kozyrev > > Acked-by: Viacheslav Ovsiienko > > Acked-by: Olivier Matz > > Thanks! Applied, thanks