From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id D7BF3293C for ; Tue, 24 Jan 2017 16:50:53 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP; 24 Jan 2017 07:50:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,278,1477983600"; d="scan'208";a="51958823" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.61]) by orsmga004.jf.intel.com with SMTP; 24 Jan 2017 07:50:50 -0800 Received: by (sSMTP sendmail emulation); Tue, 24 Jan 2017 15:50:49 +0000 Date: Tue, 24 Jan 2017 15:50:49 +0000 From: Bruce Richardson To: Olivier Matz Cc: dev@dpdk.org Message-ID: <20170124155049.GA172024@bricha3-MOBL3.ger.corp.intel.com> References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com> <1485271173-13408-4-git-send-email-olivier.matz@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1485271173-13408-4-git-send-email-olivier.matz@6wind.com> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.7.1 (2016-10-04) Subject: Re: [dpdk-dev] [RFC 3/8] mbuf: set mbuf fields while in pool 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: , X-List-Received-Date: Tue, 24 Jan 2017 15:50:54 -0000 On Tue, Jan 24, 2017 at 04:19:28PM +0100, Olivier Matz wrote: > Set the value of m->refcnt to 1, m->nb_segs to 1 and m->next > to NULL when the mbuf is stored inside the mempool (unused). > This is done in rte_pktmbuf_prefree_seg(), before freeing or > recycling a mbuf. > > Before this patch, the value of m->refcnt was expected to be 0 > while in pool. > > The objectives are: > > - to avoid drivers to set m->next to NULL in the early Rx path, since > this field is in the second 64B of the mbuf and its access could > trigger a cache miss > > - rationalize the behavior of raw_alloc/raw_free: one is now the > symmetric of the other, and refcnt is never changed in these functions. > > Signed-off-by: Olivier Matz > --- > drivers/net/mlx5/mlx5_rxtx.c | 5 ++--- > drivers/net/mpipe/mpipe_tilegx.c | 1 + > lib/librte_mbuf/rte_mbuf.c | 2 ++ > lib/librte_mbuf/rte_mbuf.h | 45 +++++++++++++++++++++++++++++----------- > 4 files changed, 38 insertions(+), 15 deletions(-) > > /* compat with older versions */ > __rte_deprecated > -static inline void __attribute__((always_inline)) > +static inline void > __rte_mbuf_raw_free(struct rte_mbuf *m) > { > rte_mbuf_raw_free(m); > @@ -1218,8 +1232,12 @@ static inline void rte_pktmbuf_detach(struct rte_mbuf *m) > m->data_len = 0; > m->ol_flags = 0; > > - if (rte_mbuf_refcnt_update(md, -1) == 0) > + if (rte_mbuf_refcnt_update(md, -1) == 0) { Minor nit, but in the case that we only have a single reference to the mbufs, we are always setting that to zero just to re-increment it to 1 again. > + md->next = NULL; > + md->nb_segs = 1; > + rte_mbuf_refcnt_set(md, 1); > rte_mbuf_raw_free(md); > + } > } > > /**