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 DD7247CFB for ; Sat, 3 Jun 2017 12:00:09 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP; 03 Jun 2017 03:00:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,289,1493708400"; d="scan'208";a="94261070" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by orsmga004.jf.intel.com with ESMTP; 03 Jun 2017 03:00:07 -0700 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.250]) by IRSMSX152.ger.corp.intel.com ([169.254.6.83]) with mapi id 14.03.0319.002; Sat, 3 Jun 2017 11:00:07 +0100 From: "Ananyev, Konstantin" To: "Verkamp, Daniel" , "dev@dpdk.org" CC: "Richardson, Bruce" Thread-Topic: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation Thread-Index: AQHS29yUGhSpppN6a069aA11FRzec6ISDAhwgAAJcACAANJnAA== Date: Sat, 3 Jun 2017 10:00:06 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583FB05216@IRSMSX109.ger.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: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 10:00:10 -0000 >=20 > The PROD/CONS_ALIGN values on x86-64 are set to 2 cache lines, so members= of struct rte_ring are 128 byte aligned,=20 >and therefore the whole struct needs 128-byte alignment according to the A= BI so that the 128-byte alignment of the fields can be guaranteed. Ah ok, missed the fact that rte_ring is 128B aligned these days. BTW, I probably missed the initial discussion, but what was the reason for = that? Konstantin >=20 > If the allocation is only 64-byte aligned, the beginning of the prod and = cons fields may not actually be 128-byte aligned (but we've told the > compiler that they are using the __rte_aligned macro). Accessing these f= ields 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 und= efined behavior according to the C standard, and UBSan (- > fsanitize=3Dundefined) checks for this. >=20 > Thanks, > -- Daniel Verkamp >=20 > > -----Original Message----- > > From: Ananyev, Konstantin > > Sent: Friday, June 2, 2017 1:52 PM > > To: Verkamp, Daniel ; dev@dpdk.org > > Cc: Verkamp, Daniel > > Subject: RE: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation > > > > > > > > > -----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 > > > 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 a= re > > > 128 bytes, but cache line size is 64 bytes. > > > > 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 > > > > > > > > Fixes runtime warnings with UBSan enabled. > > > > > > Fixes: d9f0d3a1ffd4 ("ring: remove split cacheline build setting") > > > > > > Signed-off-by: Daniel Verkamp > > > --- > > > > > > 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,= int > > 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 fun= ction */ > > > - 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