From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 7C9907CB6 for ; Mon, 5 Jun 2017 18:22:04 +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; 05 Jun 2017 09:22:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,302,1493708400"; d="scan'208";a="95776017" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga002.jf.intel.com with ESMTP; 05 Jun 2017 09:21:59 -0700 Received: from fmsmsx117.amr.corp.intel.com (10.18.116.17) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 5 Jun 2017 09:21:59 -0700 Received: from fmsmsx103.amr.corp.intel.com ([169.254.2.37]) by fmsmsx117.amr.corp.intel.com ([169.254.3.49]) with mapi id 14.03.0319.002; Mon, 5 Jun 2017 09:21:59 -0700 From: "Verkamp, Daniel" To: "Ananyev, Konstantin" , "dev@dpdk.org" CC: "Richardson, Bruce" Thread-Topic: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation Thread-Index: AQHS29yMvgJOgijkWE2oOe5FhRvBaKISgceA//+jIWCAATkRAIADGW8g Date: Mon, 5 Jun 2017 16:21:58 +0000 Message-ID: References: <20170602200337.50743-1-daniel.verkamp@intel.com> <20170602201213.51143-1-daniel.verkamp@intel.com> <2601191342CEEE43887BDE71AB9772583FB05190@IRSMSX109.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583FB05216@IRSMSX109.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772583FB05216@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjgzOWM3MDUtOTVjOC00Y2JiLWI0OTYtOWY2ZDJmMTAxZTRkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlVBT2ozSnAxcjlpekFvSEx6ZGd1VTRvVFhKaklyRTlqZFpJOVlhNEJuZmM9In0= dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.1.200.107] 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: Mon, 05 Jun 2017 16:22:05 -0000 > -----Original Message----- > From: Ananyev, Konstantin > Sent: Saturday, June 3, 2017 3:00 AM > To: Verkamp, Daniel ; dev@dpdk.org > Cc: Richardson, Bruce > Subject: RE: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation >=20 >=20 >=20 > > > > The PROD/CONS_ALIGN values on x86-64 are set to 2 cache lines, so membe= rs > of struct rte_ring are 128 byte aligned, > >and therefore the whole struct needs 128-byte alignment according to the= ABI > so that the 128-byte alignment of the fields can be guaranteed. >=20 > 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 fo= r that? > Konstantin I don't know why PROD_ALIGN/CONS_ALIGN use 128 byte alignment; it seems unn= ecessary if the cache line is only 64 bytes. An alternate fix would be to = just use cache line alignment for these fields (since memzones are already = cache line aligned). Maybe there is some deeper reason for the >=3D 128-by= te alignment logic in rte_ring.h? Thanks, -- Daniel