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 1FE55A04B1; Thu, 5 Nov 2020 11:30:21 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 69299BE3D; Thu, 5 Nov 2020 11:30:18 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 4B83DBC5E; Thu, 5 Nov 2020 11:30:15 +0100 (CET) IronPort-SDR: 8Xnjs36J3dOKflPuFRPO77x4b5CpwNXtssxigF7TV1qvREgJiJDiWH2FELJOSZ0bQ0Zd+IRrdL Uhj+yr/eMFKw== X-IronPort-AV: E=McAfee;i="6000,8403,9795"; a="165851532" X-IronPort-AV: E=Sophos;i="5.77,453,1596524400"; d="scan'208";a="165851532" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Nov 2020 02:30:12 -0800 IronPort-SDR: hCZX6708ynQyD2CLRSI2G2i1XYh3QFBDrtdgthUMuijO89TMSUGmOg0YClfCV/Mn6ZWHo/vF/8 H2hEEtuQKdeA== X-IronPort-AV: E=Sophos;i="5.77,453,1596524400"; d="scan'208";a="363770552" Received: from bricha3-mobl.ger.corp.intel.com ([10.251.177.138]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 05 Nov 2020 02:30:02 -0800 Date: Thu, 5 Nov 2020 10:29:56 +0000 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: "Ananyev, Konstantin" , Olivier Matz , Slava Ovsiienko , NBU-Contact-Thomas Monjalon , dev@dpdk.org, techboard@dpdk.org, Ajit Khaparde , Andrew Rybchenko , "Yigit, Ferruh" , david.marchand@redhat.com, jerinj@marvell.com, honnappa.nagarahalli@arm.com, maxime.coquelin@redhat.com, stephen@networkplumber.org, hemant.agrawal@nxp.com, Matan Azrad , Shahaf Shuler Message-ID: <20201105102956.GA773@bricha3-MOBL.ger.corp.intel.com> References: <20201029092751.3837177-1-thomas@monjalon.net> <3086227.yllCKDRCEA@thomas> <98CBD80474FA8B44BF855DF32C47DC35C613CD@smartserver.smartshare.dk> <13044489.RHGIMAnax8@thomas> <98CBD80474FA8B44BF855DF32C47DC35C613DB@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35C613DF@smartserver.smartshare.dk> <20201104150053.GI1898@platinum> <98CBD80474FA8B44BF855DF32C47DC35C613EE@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: <98CBD80474FA8B44BF855DF32C47DC35C613EE@smartserver.smartshare.dk> Subject: Re: [dpdk-dev] [PATCH 15/15] mbuf: move pool pointer in hotterfirst 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 Thu, Nov 05, 2020 at 10:35:45AM +0100, Morten Brørup wrote: > There is a simple alternative for applications with a single mbuf pool to avoid accessing m->pool. > > We could add a global variable pointing to the single mbuf pool. > > It would be NULL by default. > > It would be set by rte_pktmbuf_pool_create() on first invocation, and reset back to NULL on following invocations. (There would need to be a counter too, to prevent setting it again on the third invocation.) > > All functions accessing m->pool would use the global mbuf pool pointer if set, and otherwise use the m->pool pointer, like this: > > - rte_mempool_put(m->pool, m); > + rte_mempool_put(global_mbuf_pool ? global_mbuf_pool : m->pool, m); > > This optimization can be implemented without ABI breakage: > > Since m->pool is initialized as always, functions that are not modified to use the global_mbuf_pool will simply continue using m->pool, not knowing that a global mbuf pool exists. > Very interesting idea. Definitely worth considering. A TX function would only have to check the global variable once at the start of cleanup too, and if set, it can use bulk frees without any additional work. /Bruce