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 3D86EA0524; Sat, 7 Nov 2020 21:34:05 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 014722E8B; Sat, 7 Nov 2020 21:34:03 +0100 (CET) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id B0A3E2C2E for <dev@dpdk.org>; Sat, 7 Nov 2020 21:34:01 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 311B7580290; Sat, 7 Nov 2020 15:33:58 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 07 Nov 2020 15:33:58 -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=fm2; bh= m1wJyTVnB+xWqIKPMGVXejpur/CDH7nHF73bVIEfn/w=; b=AaS+wZ95wqDEB7Gw N6kntK6XqgfRaugJOGa/LEGkKyHvR2H6QHKFmvy/LUOh0kTdCbEmhlcRmp6Dfp53 mIa9QzTUsCvO8yJBJwoXTpkIHkwuvxGjDc/Advll0Zf7nPZ02Tg+ZI/xM08rRHQH D/6d5bDMOBiFileB8dTDmPdBo2A6Eohei3PRVBRy4pH6Qybx9whEP9miM9+VFAk/ mSGo4cOmPfV8K24ekRqei558v9s2rYsWMzhxQnN/4WdpZHUpyDg9cvjlZDM1Kt2E ZyFlHby8yPzqvX4WQKoBVw+KzHs0c+Mqk1saDy0wtLN/ZeDFCEUKQtc6ayh56eDG xAJMRA== 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=m1wJyTVnB+xWqIKPMGVXejpur/CDH7nHF73bVIEfn /w=; b=X0+SbN4Qhx3Xgl/s4QcKqhsZam6/hIpdTH/kcZQ6vkBbRaRWregwxUjaj 4SKv2DXAJWh3INPQEef5r99j9/7Tw+Ex9X6Dz6ffC6cfGp6P0jP2Iy256w1N1Iub fl4GN4bnHw7yjEnUP+DJRcAcDoS5Vp+l/A1tHXMhuX/NnjMh5oKXMS4d2P16pZm7 EqS0NJEgksITpNIhzmDvvrCTg9+BmMogWTHloDBKgZ0N0YHBcBuGxPnoXZ4B4k2F Rjgw2XKL+k0uJbclsx7cIxNdPe7L31DONHbW6n1S2MMw4iHhMOEV/eYEZjqgBuWv HscI+YQbkWzXPtI/9nu3pR718XoXQ== X-ME-Sender: <xms:tASnX0kMq52R-OSmtRQnSsuu53wnlQq-C_drWWjgRSH4qssSA4EB3g> <xme:tASnXz3tH7hknrHRqbP62hk-ScvPPmE7atCFDBINMmQDzVfvSQQW9mU16WabTigPr i8X8dBK9WyVj-5fvw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudduuddgudegtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgr lhhonhdrnhgvth X-ME-Proxy: <xmx:tASnXyopWaa5BLioUX4G5B-asaB1AMWM2i45ngQ8QdNoFWLugoGXWg> <xmx:tASnXwmvjZIzItI4nUKaU0MEZ8lGI-Jd50Opipg89ZVpVaxd20ALaQ> <xmx:tASnXy1hJRhZoDGrWR-ly3DdYmrd7DnjUvZQtQ1q7Z8iH2fpEMT96A> <xmx:tgSnX10OUWhOQ45IovnOMvZBcySzHXVblZFopYO7tuFqqlGYrm2RMA> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2CCA9328041D; Sat, 7 Nov 2020 15:33:52 -0500 (EST) From: Thomas Monjalon <thomas@monjalon.net> To: Jerin Jacob <jerinjacobk@gmail.com> Cc: dpdk-dev <dev@dpdk.org>, David Marchand <david.marchand@redhat.com>, Ferruh Yigit <ferruh.yigit@intel.com>, Olivier Matz <olivier.matz@6wind.com>, Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, Viacheslav Ovsiienko <viacheslavo@nvidia.com>, Ajit Khaparde <ajit.khaparde@broadcom.com>, Jerin Jacob <jerinj@marvell.com>, Hemant Agrawal <hemant.agrawal@nxp.com>, Ray Kinsella <mdr@ashroe.eu>, Neil Horman <nhorman@tuxdriver.com>, Nithin Dabilpuram <ndabilpuram@marvell.com>, Kiran Kumar K <kirankumark@marvell.com> Date: Sat, 07 Nov 2020 21:33:50 +0100 Message-ID: <6088267.6fNGb03Fmp@thomas> In-Reply-To: <CALBAE1PMq=8KD-C4Au4RTK+aLPp532vBsMJjqad1Pq4YFSWsOQ@mail.gmail.com> References: <20201107155306.463148-1-thomas@monjalon.net> <4509916.LqRtgDRpI1@thomas> <CALBAE1PMq=8KD-C4Au4RTK+aLPp532vBsMJjqad1Pq4YFSWsOQ@mail.gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 1/1] mbuf: move pool pointer in first half 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> 07/11/2020 20:05, Jerin Jacob: > On Sun, Nov 8, 2020 at 12:09 AM Thomas Monjalon <thomas@monjalon.net> wrote: > > 07/11/2020 18:12, Jerin Jacob: > > > On Sat, Nov 7, 2020 at 10:04 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > > > > > > > The mempool pointer in the mbuf struct is moved > > > > from the second to the first half. > > > > It should increase performance on most systems having 64-byte cache line, > > > > > > > i.e. mbuf is split in two cache lines. > > > > > > But In any event, Tx needs to touch the pool to freeing back to the > > > pool upon Tx completion. Right? > > > Not able to understand the motivation for moving it to the first 64B cache line? > > > The gain varies from driver to driver. For example, a Typical > > > ARM-based NPU does not need to > > > touch the pool in Rx and its been filled by HW. Whereas it needs to > > > touch in Tx if the reference count is implemented. > > See below. > > > > > > > > Due to this change, tx_offload is moved, so some vector data paths > > > > may need to be adjusted. Note: OCTEON TX2 check is removed temporarily! > > > > > > It will be breaking the Tx path, Please just don't remove the static > > > assert without adjusting the code. > > > > Of course not. > > I looked at the vector Tx path of OCTEON TX2, > > it's close to be impossible to understand :) > > Please help! > > Off course. Could you check the above section any share the rationale > for this change > and where it helps and how much it helps? It has been concluded in the techboard meeting you were part of. I don't understand why we restart this discussion again. I won't have the energy to restart this process myself. If you don't want to apply the techboard decision, then please do the necessary to request another quick decision.