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 C1875A0613 for ; Thu, 26 Sep 2019 10:30:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E59571BF25; Thu, 26 Sep 2019 10:30:33 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 4855D1BEDE for ; Thu, 26 Sep 2019 10:30:32 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2019 01:30:31 -0700 X-IronPort-AV: E=Sophos;i="5.64,551,1559545200"; d="scan'208";a="201546371" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.31.171]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2019 01:30:28 -0700 Date: Thu, 26 Sep 2019 09:30:25 +0100 From: Bruce Richardson To: Mattias =?iso-8859-1?Q?R=F6nnblom?= Cc: Morten =?iso-8859-1?Q?Br=F8rup?= , olivier.matz@6wind.com, stephen@networkplumber.org, harry.van.haaren@intel.com, konstantin.ananyev@intel.com, dev@dpdk.org Message-ID: <20190926083024.GA1821@bricha3-MOBL.ger.corp.intel.com> References: <20190925120355.44821-1-mb@smartsharesystems.com> <20190925120355.44821-3-mb@smartsharesystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH v2 2/2] mbuf: add bulk free function 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 Wed, Sep 25, 2019 at 09:02:28PM +0200, Mattias Rönnblom wrote: > On 2019-09-25 14:03, Morten Brørup wrote: > > Add function for freeing a bulk of mbufs. > > > > Signed-off-by: Morten Brørup > > --- > > lib/librte_mbuf/rte_mbuf.c | 35 +++++++++++++++++++++++++++++++++++ > > lib/librte_mbuf/rte_mbuf.h | 16 +++++----------- > > 2 files changed, 40 insertions(+), 11 deletions(-) > > > > diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c > > index 37718d49c..b63a0eced 100644 > > --- a/lib/librte_mbuf/rte_mbuf.c > > +++ b/lib/librte_mbuf/rte_mbuf.c > > @@ -245,6 +245,41 @@ int rte_mbuf_check(const struct rte_mbuf *m, int is_header, > > return 0; > > } > > +/** > > + * Maximum bulk of mbufs rte_pktmbuf_free_bulk() returns to mempool. > > + */ > > +#define RTE_PKTMBUF_FREE_BULK_SZ 64 > > + > > +/* Free a bulk of mbufs back into their original mempools. */ > > +void rte_pktmbuf_free_bulk(struct rte_mbuf **mbufs, unsigned int count) > > +{ > > + struct rte_mbuf *m, *free[RTE_PKTMBUF_FREE_BULK_SZ]; > > + unsigned int idx, nb_free = 0; > > + > > + for (idx = 0; idx < count; idx++) { > > + m = mbufs[idx]; > > + if (unlikely(m == NULL)) > > + continue; > > + > > + __rte_mbuf_sanity_check(m, 1); > > + m = rte_pktmbuf_prefree_seg(m); > > + if (unlikely(m == NULL)) > > + continue; > > + > > + if (nb_free >= RTE_PKTMBUF_FREE_BULK_SZ || > > + (nb_free > 0 && m->pool != free[0]->pool)) { > > Maybe an unlikely() would be in order here? > I'd caution against it, since it can penalize the cold branch a lot. If a branch really is predictable the HW branch predictors generally are good enough to handle it at runtime. So long as a path is a valid path for a runtime app, i.e. not something like a fatal error only ever hit once in an entire run, I'd tend to omit likely()/unlikely() calls unless profiling shows a real performance difference. /Bruce