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 A3F03A0527; Mon, 9 Nov 2020 09:04:19 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E5EEB5913; Mon, 9 Nov 2020 09:04:17 +0100 (CET) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id 0E89C58C4 for ; Mon, 9 Nov 2020 09:04:15 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 4A7625805B8; Mon, 9 Nov 2020 03:04:13 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 09 Nov 2020 03:04:13 -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= xImcI7c+S1GaC+8RGeEtYTOTG/uwT+7fYwoJsb6YjxY=; b=Rnxw0AqFWdXqqUg6 UUwly05kBw9UBP1X3DqSgsh96UXnq95n8GpbF55T5jk4H9bECUcH6dxFE3q8argZ FEJKf7QoFU0ocBRfxsHFGDjutuJSBzZRbqcpgUmORVxBM0RBzQBUhnClsVzZIiGe n23Ij4E7govIsMEjRuYN33vNCOS9lzfVW8kNgtDYNH2y7350afTm/cWwngxKx/3o aQzEDqoyfQzcqDLDs0gKKi4G7HRBXhJYdSicOYNL8HzP0+9vn1PZlYiTEPdAsabK qBeFIuNSxKvi6hd1HRSZ1sGpDqlHyE4K3LzixQyj/nE43w/23rlAqTcqIpWQ9+34 qf4BNw== 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=xImcI7c+S1GaC+8RGeEtYTOTG/uwT+7fYwoJsb6Yj xY=; b=K2Ee/WhOAbDSYqjI0nxUwE0+gfbJ7P0GO9dsMeVcjFKCHz2zQrSca9hCl H3N38u2irMJ/s2M8pX2Cykbc9n83y7hLSAu6zkaDjJH96GlFxvLuludipDT7/6vP jFLLgCtiul4dazsz/pVPf+aENRcoZQ0Z2n+gvz4JNa/jtjrrbNc3Fq94LtRu3MB3 G4s/pHwHWRtCrIMNcSBXIN2vZ/MhlyO5HF1D3ErS1BRs07n5xVxaOcnwD2yqXr0R 6dcsgV9UWgqJPaYRstPA3ieHJL19Nz6JT9pv947i0nIrozTvdi9ZJi34aV+01NoY 2Tjdp5yKleSoKlNIsXAi7NCcB8nlQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddugedguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgr lhhonhdrnhgvth 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 1803A3280068; Mon, 9 Nov 2020 03:04:10 -0500 (EST) From: Thomas Monjalon To: Jerin Jacob Cc: dpdk-dev , David Marchand , Ferruh Yigit , Olivier Matz , Morten =?ISO-8859-1?Q?Br=F8rup?= , "Ananyev, Konstantin" , Andrew Rybchenko , Viacheslav Ovsiienko , Ajit Khaparde , Jerin Jacob , Hemant Agrawal , Ray Kinsella , Neil Horman , Nithin Dabilpuram , Kiran Kumar K Date: Mon, 09 Nov 2020 09:04:08 +0100 Message-ID: <7853350.9sPKUjbg19@thomas> In-Reply-To: References: <20201107155306.463148-1-thomas@monjalon.net> <6088267.6fNGb03Fmp@thomas> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 09/11/2020 06:18, Jerin Jacob: > On Sun, Nov 8, 2020 at 2:03 AM Thomas Monjalon wrote: > > 07/11/2020 20:05, Jerin Jacob: > > > On Sun, Nov 8, 2020 at 12:09 AM Thomas Monjalon wrote: > > > > 07/11/2020 18:12, Jerin Jacob: > > > > > On Sat, Nov 7, 2020 at 10:04 PM Thomas Monjalon 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. > > Yes. Initially, I thought it is OK as we have 128B CL, After looking > into Thomas's change, I realized > it is not good for ARM64 64B catchlines based NPU as > - 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. Small note: It is not true for all Arm platforms. > - Also it will be effecting exiting vector routines > > I request to reconsider the tech board decision.