From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id D89E5234 for ; Fri, 31 Mar 2017 13:51:18 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP; 31 Mar 2017 04:51:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,251,1486454400"; d="scan'208";a="72215413" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga004.jf.intel.com with ESMTP; 31 Mar 2017 04:51:15 -0700 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.12]) by IRSMSX101.ger.corp.intel.com ([163.33.3.153]) with mapi id 14.03.0319.002; Fri, 31 Mar 2017 12:51:14 +0100 From: "Ananyev, Konstantin" To: "Richardson, Bruce" , Olivier Matz CC: "dev@dpdk.org" , "mb@smartsharesystems.com" , "Chilikin, Andrey" , "jblunck@infradead.org" , "nelio.laranjeiro@6wind.com" , "arybchenko@solarflare.com" Thread-Topic: [PATCH 3/9] mbuf: set mbuf fields while in pool Thread-Index: AQHSl/BSFV38HmpAFEG4XpL/ah0+ZKGu4UgAgAAUu7A= Date: Fri, 31 Mar 2017 11:51:13 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583FAE328D@IRSMSX109.ger.corp.intel.com> References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com> <1488966121-22853-1-git-send-email-olivier.matz@6wind.com> <1488966121-22853-4-git-send-email-olivier.matz@6wind.com> <20170331112138.GA12052@bricha3-MOBL3.ger.corp.intel.com> In-Reply-To: <20170331112138.GA12052@bricha3-MOBL3.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 3/9] 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: Fri, 31 Mar 2017 11:51:19 -0000 > -----Original Message----- > From: Richardson, Bruce > Sent: Friday, March 31, 2017 12:22 PM > To: Olivier Matz > Cc: dev@dpdk.org; Ananyev, Konstantin ; mb@= smartsharesystems.com; Chilikin, Andrey > ; jblunck@infradead.org; nelio.laranjeiro@6win= d.com; arybchenko@solarflare.com > Subject: Re: [PATCH 3/9] mbuf: set mbuf fields while in pool >=20 > On Wed, Mar 08, 2017 at 10:41:55AM +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 function= s. > > > > 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 | 42 +++++++++++++++++++++++++++++---= -------- > > 4 files changed, 36 insertions(+), 14 deletions(-) > > > > > /** > > @@ -1244,9 +1262,13 @@ rte_pktmbuf_prefree_seg(struct rte_mbuf *m) > > __rte_mbuf_sanity_check(m, 0); > > > > if (likely(rte_mbuf_refcnt_update(m, -1) =3D=3D 0)) { > > - /* if this is an indirect mbuf, it is detached. */ > > if (RTE_MBUF_INDIRECT(m)) > > rte_pktmbuf_detach(m); > > + > > + m->next =3D NULL; > > + m->nb_segs =3D 1; > > + rte_mbuf_refcnt_set(m, 1); > > + > > return m; > > } > > return NULL; >=20 > Do we need to make this change to prefree_seg? If we update the detach > function to set the next point to null on detaching a segment, and if we > change the "free" function which frees a whole chain of mbufs, we should > be covered, should we not? If we are freeing a standalone segment, that > segment should already have it's nb_segs and next pointers correct. detach() is invoked only for indirect mbufs. We can have a chain of direct mbufs too. About free() - most PMD use either rte_pktmbuf_free_seg() or rte_pktmbuf_prefree_seg();rte_mempool_put_bulk(); directly. Konstantin