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 793B4A0527; Mon, 9 Nov 2020 11:08:56 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A09125928; Mon, 9 Nov 2020 11:08:54 +0100 (CET) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 66E285916; Mon, 9 Nov 2020 11:08:51 +0100 (CET) IronPort-SDR: XBonIEybedC1TDBHRDR9fKOyMwPFIvvHw2INnjFR5uX7VoWweopxS3Sxkkpn1TiQStAzwwL4BI xF28ormMm5zg== X-IronPort-AV: E=McAfee;i="6000,8403,9799"; a="149056240" X-IronPort-AV: E=Sophos;i="5.77,463,1596524400"; d="scan'208";a="149056240" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Nov 2020 02:08:49 -0800 IronPort-SDR: 7ZZXiuLitSckSxN4HqGZ+HcH8g2/BOFZezatavW6Kyu4fDgU/JbiGCHh6TxsIGFZWL22HcfSBf rfszO+Rr81TA== X-IronPort-AV: E=Sophos;i="5.77,463,1596524400"; d="scan'208";a="540784837" 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 02:08:43 -0800 Date: Mon, 9 Nov 2020 10:08:38 +0000 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: Thomas Monjalon , dev@dpdk.org, david.marchand@redhat.com, ferruh.yigit@intel.com, olivier.matz@6wind.com, konstantin.ananyev@intel.com, andrew.rybchenko@oktetlabs.ru, viacheslavo@nvidia.com, ajit.khaparde@broadcom.com, jerinj@marvell.com, hemant.agrawal@nxp.com, Ray Kinsella , Neil Horman , Nithin Dabilpuram , Kiran Kumar K , techboard@dpdk.org Message-ID: <20201109100838.GC831@bricha3-MOBL.ger.corp.intel.com> References: <20201107155306.463148-1-thomas@monjalon.net> <98CBD80474FA8B44BF855DF32C47DC35C61404@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C61404@smartserver.smartshare.dk> 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 Sat, Nov 07, 2020 at 07:57:05PM +0100, Morten Brørup wrote: > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > Sent: Saturday, November 7, 2020 4:53 PM > > > > 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. > > Perhaps with the #define DEV_TX_OFFLOAD_MBUF_FAST_FREE mentioned by Konstantin, it might be better moving m->next instead, at least for applications with the opportunity to set this flag (e.g. applications with only one mbuf pool). > > Unfortunately, the information about the DEV_TX_OFFLOAD_MBUF_FAST_FREE flag came to light after the techboard meeting, and I don't have any benchmarks to support this suggestion, so I guess it's hard to change the techboard's decision to move the pool pointer. > The thing with FAST_FREE is that it doesn't just indicate that there is only one mbuf pool, but rather that none of the packets are chained mbufs either. Therefore, the flag applies equally to both next and pool pointers for optimization. [And the flag should perhaps be two flags!] /Bruce