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 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: <xms:B6GCXrKgpZBou-Ip4JrD-Y72ALA7khSM7XyUG4lZf6Gc3XKPcdszDg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeiiedggeelucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr
shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf
hppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgr
rhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght
X-ME-Proxy: <xmx:B6GCXgWrICLQYS6QmrUQIRESIeKBwnDkDYnfJAmbUJ2N6RVUPwmdSA>
<xmx:B6GCXkI55sRMUUEJnTzons0dPMoQiftgVAydqk6B0ocuL9pg7fTIBA>
<xmx:B6GCXtwwmy4iP4Ge0C6tpWiF5g4Y3E2E6NK2RTgqdpGvwKek-wPrnQ>
<xmx:CKGCXvsA7aE_1S5W_A_YZv1i_GSp3mue3oUEyvDdalanoc5TfXAfxA>
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 <thomas@monjalon.net>
To: Alexander Kozyrev <akozyrev@mellanox.com>
Cc: stable@dpdk.org, dev@dpdk.org, viacheslavo@mellanox.com, matan@mellanox.com,
stable@dpdk.org, Olivier Matz <olivier.matz@6wind.com>
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 <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>
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 <Block 2> // 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 <Block 2> // jump in to "if (!RTE_MBUF_HAS_EXTBUF(m)"
> > movq 0x48(%rbx), %rax // load the pool field
> > jmp 0x9bea78 <Block 7> // 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 <akozyrev@mellanox.com>
> > Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
>
> Acked-by: Olivier Matz <olivier.matz@6wind.com>
>
> Thanks!
Applied, thanks