From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <konstantin.ananyev@intel.com>
Received: from mga06.intel.com (mga06.intel.com [134.134.136.31])
by dpdk.org (Postfix) with ESMTP id D89E5234
for <dev@dpdk.org>; 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" <konstantin.ananyev@intel.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>, Olivier Matz
<olivier.matz@6wind.com>
CC: "dev@dpdk.org" <dev@dpdk.org>, "mb@smartsharesystems.com"
<mb@smartsharesystems.com>, "Chilikin, Andrey" <andrey.chilikin@intel.com>,
"jblunck@infradead.org" <jblunck@infradead.org>, "nelio.laranjeiro@6wind.com"
<nelio.laranjeiro@6wind.com>, "arybchenko@solarflare.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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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 <olivier.matz@6wind.com>
> Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>; mb@=
smartsharesystems.com; Chilikin, Andrey
> <andrey.chilikin@intel.com>; 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 <olivier.matz@6wind.com>
> > ---
> > 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(-)
> >
> <snip>
> > /**
> > @@ -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