From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <konstantin.ananyev@intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id 172473237
 for <dev@dpdk.org>; Wed,  8 Apr 2015 15:45:05 +0200 (CEST)
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
 by orsmga101.jf.intel.com with ESMTP; 08 Apr 2015 06:45:04 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.11,544,1422950400"; d="scan'208";a="705478660"
Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153])
 by fmsmga002.fm.intel.com with ESMTP; 08 Apr 2015 06:45:03 -0700
Received: from irsmsx105.ger.corp.intel.com ([169.254.7.2]) by
 IRSMSX101.ger.corp.intel.com ([169.254.1.136]) with mapi id 14.03.0224.002;
 Wed, 8 Apr 2015 14:45:02 +0100
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Olivier MATZ <olivier.matz@6wind.com>, "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [PATCH v3 1/5] mbuf: fix clone support when application uses
 private mbuf data
Thread-Index: AQHQa+gyjaiCAXJ/uUmIkTCvT5y80Z058RBAgAaNe4CAAQPAcIAAKOKAgAAVpxCAARfGAIAAUocQ
Date: Wed, 8 Apr 2015 13:45:02 +0000
Message-ID: <2601191342CEEE43887BDE71AB97725821414805@irsmsx105.ger.corp.intel.com>
References: <1427385595-15011-1-git-send-email-olivier.matz@6wind.com>
 <1427829784-12323-1-git-send-email-zer0@droids-corp.org>
 <1427829784-12323-2-git-send-email-zer0@droids-corp.org>
 <2601191342CEEE43887BDE71AB97725821413A2D@irsmsx105.ger.corp.intel.com>
 <5522FF6B.1030503@6wind.com>
 <2601191342CEEE43887BDE71AB97725821414310@irsmsx105.ger.corp.intel.com>
 <5523FB9B.2060508@6wind.com>
 <2601191342CEEE43887BDE71AB9772582141451F@irsmsx105.ger.corp.intel.com>
 <5524F876.8090900@6wind.com>
In-Reply-To: <5524F876.8090900@6wind.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.181]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dpdk-dev] [PATCH v3 1/5] mbuf: fix clone support when
 application uses private mbuf data
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <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: Wed, 08 Apr 2015 13:45:06 -0000

Hi Olivier,

> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Wednesday, April 08, 2015 10:44 AM
> To: Ananyev, Konstantin; dev@dpdk.org
> Cc: zoltan.kiss@linaro.org; Richardson, Bruce
> Subject: Re: [PATCH v3 1/5] mbuf: fix clone support when application uses=
 private mbuf data
>=20
> Hi Konstantin,
>=20
> On 04/07/2015 07:17 PM, Ananyev, Konstantin wrote:
> >> Just to be sure we're on the same line:
> >>
> >> - before the patch series
> >>
> >>     - private area was working before that patch series if clones were=
 not
> >>       used. To use a private are, the user had to provide another
> >>       function derived from pktmbuf_init() to change m->buf_addr and
> >>       m->buf_len.
> >>     - using both private area + clones was broken
> >>
> >> - after the patch series
> >>
> >>     - private area is working with or without clone. But yo use it,
> >>       the user still has to provide another function to change
> >>       m->buf_addr, m->buf_len *and m->priv_size*.
> >>
> >> The series just fixes the fact that "clones + priv" was not working.
> >> It does not address the problem that providing a new pktmbuf_init()
> >> function is required to use privata area. To fix this, I think it
> >> could require a API evolution that should be part of another series.
> >
> > I don't think we need new pktmbuf_init().
> > We just need to update it, so both pktmbuf_init() and detach() setup
> > buf_addr, buf_len (and priv_size) to exactly the same values.
> > If they don't do that, it means that you can't use attach/detach with
> > mempools created with pktmbuf_init() any more.
> >
> > BTW, another thing that I just realised:
> > examples/ipv4_multicast and examples/ip_fragmentation/ -
> > both create a pool of mbufs with elem_size < 2K and don't populate memp=
ool's private area -
> > so mbp_priv->mbuf_data_room_size =3D=3D 0, for them.
> >
> > So that code in detach():
> >
> >   +	mbp_priv =3D rte_mempool_get_priv(mp);
> >   +	m->priv_size =3D mp->elt_size - RTE_PKTMBUF_HEADROOM -
> >   +		mbp_priv->mbuf_data_room_size -
> >   +		sizeof(struct rte_mbuf);
> >
> >
> > Would break both these samples.
> > I suppose we need to handle situation when mp->elt_size < RTE_PKTMBUF_H=
EADROOM + sizeof(struct rte_mbuf),
> > (and probably also when mbuf_data_room_size =3D=3D 0) correctly.
>=20
> Indeed. I think a mbuf pool (even with buf_len =3D=3D 0 like in
> ip_fragmentation example) should have a pool with a private area and
> should call rte_pktmbuf_pool_init() to populate it. So
> rte_pktmbuf_pool_init() has to be fixed first to use elt_size
> and support the buf_len < RTE_PKTMBUF_HEADROOM, then we can
> update frag/multicast examples.
>=20
> Unfortunately, we don't know the size of the mbuf private area
> in rte_pktmbuf_pool_init() if the opaque arg (data_room_size)
> is 0, which is the default. I think it should be replaced by a structure
> containing data_room_size and mbuf_priv_size, but it would break
> applications that are setting data_room_size.

Yes, same thoughts here.

> I don't see any good
> solution to do that while keeping a backward compatibility for
> rte_pktmbuf_pool_init(), but as the current API is not ideal,
> I think it's worth changing it and add something in the release
> note.

If no one else has a better alternative than that, then I suppose it is goo=
d enough.=20

>=20
> We may also want to introduce a new helper as discussed previously:
>=20
> struct rte_mempool *
> rte_pktmbuf_pool_create(const char *name, unsigned n, unsigned elt_size,
> 	unsigned cache_size, size_t mbuf_priv_size,
> 	rte_mempool_obj_ctor_t *obj_init, void *obj_init_arg,
> 	int socket_id, unsigned flags)
>=20
> Any comment?

Looks good to me.
Should we also introduce rte_pktmbuf_pool_xmem_create()?=20
Konstantin

>=20
>=20
> >
> > Konstantin