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 8E10CA0527; Mon, 9 Nov 2020 11:37:15 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 742B15937; Mon, 9 Nov 2020 11:37:13 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 2A503592C; Mon, 9 Nov 2020 11:37:10 +0100 (CET) IronPort-SDR: OUbCvCpQ3iiU4c6ucB9glO5pt04tlbknP8K7NsFBDG++sLU0g/1D4RHTT1+d+/irJNGEAVdaSb sTJDYQrssHzg== X-IronPort-AV: E=McAfee;i="6000,8403,9799"; a="156789068" X-IronPort-AV: E=Sophos;i="5.77,463,1596524400"; d="scan'208";a="156789068" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Nov 2020 02:37:07 -0800 IronPort-SDR: kPOT3rLyO0CeePEYdszAsdqoAnt8gt4RGg6Qiu5X8JamPeHdLPGkWZioxa+u2A6s3NB3WqU0GA b/UcpMaIDnug== X-IronPort-AV: E=Sophos;i="5.77,463,1596524400"; d="scan'208";a="530681255" Received: from bricha3-mobl.ger.corp.intel.com ([10.214.194.11]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 09 Nov 2020 02:36:57 -0800 Date: Mon, 9 Nov 2020 10:36:51 +0000 From: Bruce Richardson To: "Ananyev, Konstantin" Cc: Morten =?iso-8859-1?Q?Br=F8rup?= , Thomas Monjalon , "dev@dpdk.org" , "david.marchand@redhat.com" , "Yigit, Ferruh" , "olivier.matz@6wind.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: <20201109103650.GD831@bricha3-MOBL.ger.corp.intel.com> References: <20201107155306.463148-1-thomas@monjalon.net> <98CBD80474FA8B44BF855DF32C47DC35C61404@smartserver.smartshare.dk> <20201109100838.GC831@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 10:33:41AM +0000, Ananyev, Konstantin wrote: > > > > 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. > > Hmm, wonder where such assumption comes from? > There is nothing about forbidding chained mbufs in rte_ethdev.h right now: > #define DEV_TX_OFFLOAD_MBUF_FAST_FREE 0x00010000 > /**< Device supports optimization for fast release of mbufs. > * When set application must guarantee that per-queue all mbufs comes from > * the same mempool and has refcnt = 1. > */ > I should have checked before mailing. I was mixing up the refcnt = 1 bit with chained mbuf support. /Bruce