From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 96D1C1B303; Fri, 19 Jan 2018 00:24:16 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 34A2A20B90; Thu, 18 Jan 2018 18:24:16 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 18 Jan 2018 18:24:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=/fyjzb0RdFww+bX/pq5tEfKcAa IyKM97z7xJ3aeYkhI=; b=S4GDpXG3/7M7lalLeRoClXp2sAskRAESjtGq3brsfY bPbmKdZ/CQQ2S2R0A0Hh5bCM1YtS9ViVbLQC4GN7BNfjpn0qohRuI6q0C8SG+MKx xc71cYCNObKMueBSq+2QGAuVz4VYct/PVlG3sKSypa4m8JyyQyHmOGGvjmZ1Wboi k= 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-sender:x-me-sender:x-sasl-enc; s=fm1; bh=/fyjzb 0RdFww+bX/pq5tEfKcAaIyKM97z7xJ3aeYkhI=; b=i185DBSAWZYiBhyI1AdFg7 DhBp0myUWsqW9vX1AV25zNgm7UqR1xtmqoGe2dEtsLwtG+RuixCQUhkW2RWqhcZA 86JWcmrdofc7jasuL/wNIcFsYUzsiQLizef0SFa+r+LXnSnZSymIwo5yDhfaUWTa ldsIF+qcalkmjT/8iynok3BGUSeBs2jn3wE017z8rydsAGspr1G0UDpU3F66jg/Z xv9BYoHCB/DlR65/HzzqZBvXKjAL8eVyqfa9LPMKDzGyaN9H3X5MoHhARh0ig1D6 ruHy89VfFQ0sk7s/4KJe3DGx4MBMBzrFEt6ZU6zbOw77FCm2PgtBfQZqMroXSBPg == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id D859C7E3DF; Thu, 18 Jan 2018 18:24:15 -0500 (EST) From: Thomas Monjalon To: Olivier Matz Cc: dev@dpdk.org, hhaim@cisco.com, matvejchikov@gmail.com, konstantin.ananyev@intel.com, stable@dpdk.org Date: Fri, 19 Jan 2018 00:23:40 +0100 Message-ID: <2358946.9nMsedO5u3@xps> In-Reply-To: <20171208154651.16546-1-olivier.matz@6wind.com> References: <20171115091413.27119-1-hhaim@cisco.com> <20171208154651.16546-1-olivier.matz@6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v4] mbuf: fix mbuf free performance with non atomic refcnt 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: Thu, 18 Jan 2018 23:24:16 -0000 08/12/2017 16:46, Olivier Matz: > When RTE_MBUF_REFCNT_ATOMIC=n, the decrement of the mbuf reference > counter uses an atomic operation. This is not necessary and impacts > the performance (seen with TRex traffic generator). > > We cannot replace rte_atomic16_add_return() by rte_mbuf_refcnt_update() > because it would add an additional check. > > Solves this by introducing __rte_mbuf_refcnt_update(), which > updates the reference counter without doing anything else. > > Fixes: 8f094a9ac5d7 ("mbuf: set mbuf fields while in pool") > Suggested-by: Hanoch Haim > Signed-off-by: Olivier Matz Applied, thanks