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 10BFEA052A; Mon, 9 Nov 2020 10:47:50 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8404F592C; Mon, 9 Nov 2020 10:47:47 +0100 (CET) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id CEEAC5916 for ; Mon, 9 Nov 2020 10:47:45 +0100 (CET) IronPort-SDR: 7/5DUrFWOk4ENzFV4t/RB42GywotF169v16kWMND/i9ACpIsYCcKlz1YPtt2FFWiAetT2FAkPJ 3u/rMg0zFtzQ== X-IronPort-AV: E=McAfee;i="6000,8403,9799"; a="254482688" X-IronPort-AV: E=Sophos;i="5.77,463,1596524400"; d="scan'208";a="254482688" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Nov 2020 01:47:43 -0800 IronPort-SDR: IWgo8hgynRv5WofBlmQe73IK1PnDgmqAWFJdc8BJWqA7NOgW5bFh9wGLyWWprQ2vJfIgwHrm8m TZmE042nDtSQ== X-IronPort-AV: E=Sophos;i="5.77,463,1596524400"; d="scan'208";a="540776894" Received: from bricha3-mobl.ger.corp.intel.com ([10.214.194.11]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 09 Nov 2020 01:47:37 -0800 Date: Mon, 9 Nov 2020 09:47:32 +0000 From: Bruce Richardson To: Jerin Jacob Cc: Thomas Monjalon , 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 Message-ID: <20201109094732.GA831@bricha3-MOBL.ger.corp.intel.com> References: <20201107155306.463148-1-thomas@monjalon.net> <6088267.6fNGb03Fmp@thomas> <7853350.9sPKUjbg19@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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" On Mon, Nov 09, 2020 at 01:57:26PM +0530, Jerin Jacob wrote: > On Mon, Nov 9, 2020 at 1:34 PM Thomas Monjalon wrote: > > > > 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. > > Yes. Generally, it is not specific to Arm platform. Any platform that > has HW accelerated mempool. > Hi Jerin, Thomas, For platforms without hw mempool support too, the same holds that the pool pointer should never need to be touched on RX. However, as we discussed on the tech board, moving the pointer may help a little some cases, and especially less optimized drivers, and there seemed to be no downside to it. Jerin, can you please clarify why moving the pool pointer would cause a problem? Is it going to cause things to be slower on some systems for some reasons? Regards, /Bruce