From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <daniel.verkamp@intel.com>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
by dpdk.org (Postfix) with ESMTP id 541C47D0D
for <dev@dpdk.org>; Sat, 3 Jun 2017 00:24:24 +0200 (CEST)
Received: from orsmga002.jf.intel.com ([10.7.209.21])
by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
02 Jun 2017 15:24:22 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.39,286,1493708400"; d="scan'208";a="94974003"
Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205])
by orsmga002.jf.intel.com with ESMTP; 02 Jun 2017 15:24:22 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by
fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS)
id 14.3.319.2; Fri, 2 Jun 2017 15:24:22 -0700
Received: from fmsmsx103.amr.corp.intel.com ([169.254.2.37]) by
FMSMSX110.amr.corp.intel.com ([169.254.14.165]) with mapi id 14.03.0319.002;
Fri, 2 Jun 2017 15:24:21 -0700
From: "Verkamp, Daniel" <daniel.verkamp@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, "dev@dpdk.org"
<dev@dpdk.org>
Thread-Topic: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation
Thread-Index: AQHS29yMvgJOgijkWE2oOe5FhRvBaKISgceA//+jIWA=
Date: Fri, 2 Jun 2017 22:24:20 +0000
Message-ID: <A5F28D4A728A7E41839CDC5C3B5A01E87EA1B586@FMSMSX103.amr.corp.intel.com>
References: <20170602200337.50743-1-daniel.verkamp@intel.com>
<20170602201213.51143-1-daniel.verkamp@intel.com>
<2601191342CEEE43887BDE71AB9772583FB05190@IRSMSX109.ger.corp.intel.com>
In-Reply-To: <2601191342CEEE43887BDE71AB9772583FB05190@IRSMSX109.ger.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ctpclassification: CTP_IC
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzQ1ZDBlMTAtYmRmMC00Y2RlLWIyMTQtNmJhZDg0OWIzNzNmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlJCNHBwaDBqZmc0UmRMQ0doOHZTb3hoYTBcL1NyUEl6Z0EzTUZIaGFUdU1VPSJ9
dlp-product: dlpe-windows
dlp-version: 10.0.102.7
dlp-reaction: no-action
x-originating-ip: [10.1.200.108]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation
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, 02 Jun 2017 22:24:24 -0000
The PROD/CONS_ALIGN values on x86-64 are set to 2 cache lines, so members o=
f struct rte_ring are 128 byte aligned, and therefore the whole struct need=
s 128-byte alignment according to the ABI so that the 128-byte alignment of=
the fields can be guaranteed.
If the allocation is only 64-byte aligned, the beginning of the prod and co=
ns fields may not actually be 128-byte aligned (but we've told the compiler=
that they are using the __rte_aligned macro). Accessing these fields when=
they are misaligned will work in practice on x86 (as long as the compiler =
doesn't use e.g. aligned SSE instructions), but it is undefined behavior ac=
cording to the C standard, and UBSan (-fsanitize=3Dundefined) checks for th=
is.
Thanks,
-- Daniel Verkamp
> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Friday, June 2, 2017 1:52 PM
> To: Verkamp, Daniel <daniel.verkamp@intel.com>; dev@dpdk.org
> Cc: Verkamp, Daniel <daniel.verkamp@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation
>=20
>=20
>=20
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Daniel Verkamp
> > Sent: Friday, June 2, 2017 9:12 PM
> > To: dev@dpdk.org
> > Cc: Verkamp, Daniel <daniel.verkamp@intel.com>
> > Subject: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation
> >
> > rte_memzone_reserve() provides cache line alignment, but
> > struct rte_ring may require more than cache line alignment: on x86-64,
> > it needs 128-byte alignment due to PROD_ALIGN and CONS_ALIGN, which are
> > 128 bytes, but cache line size is 64 bytes.
>=20
> Hmm but what for?
> I understand we need our rte_ring cche-line aligned,
> but why do you want it 2 cache-line aligned?
> Konstantin
>=20
> >
> > Fixes runtime warnings with UBSan enabled.
> >
> > Fixes: d9f0d3a1ffd4 ("ring: remove split cacheline build setting")
> >
> > Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
> > ---
> >
> > v2: fixed checkpatch warnings
> >
> > lib/librte_ring/rte_ring.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_ring/rte_ring.c b/lib/librte_ring/rte_ring.c
> > index 5f98c33..6f58faf 100644
> > --- a/lib/librte_ring/rte_ring.c
> > +++ b/lib/librte_ring/rte_ring.c
> > @@ -189,7 +189,8 @@ rte_ring_create(const char *name, unsigned count, i=
nt
> socket_id,
> > /* reserve a memory zone for this ring. If we can't get rte_config or
> > * we are secondary process, the memzone_reserve function will set
> > * rte_errno for us appropriately - hence no check in this this funct=
ion */
> > - mz =3D rte_memzone_reserve(mz_name, ring_size, socket_id, mz_flags);
> > + mz =3D rte_memzone_reserve_aligned(mz_name, ring_size, socket_id,
> > + mz_flags, __alignof__(*r));
> > if (mz !=3D NULL) {
> > r =3D mz->addr;
> > /* no need to check return value here, we already checked the
> > --
> > 2.9.4