From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 7F9F52BB1 for ; Wed, 1 Mar 2017 13:12:57 +0100 (CET) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Mar 2017 04:12:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,225,1484035200"; d="scan'208";a="70903570" Received: from bdejong-mobl.ger.corp.intel.com ([10.252.4.230]) by fmsmga005.fm.intel.com with SMTP; 01 Mar 2017 04:12:54 -0800 Received: by (sSMTP sendmail emulation); Wed, 01 Mar 2017 12:12:54 +0000 Date: Wed, 1 Mar 2017 12:12:53 +0000 From: Bruce Richardson To: Jerin Jacob Cc: Olivier Matz , dev@dpdk.org Message-ID: <20170301121253.GB31112@bricha3-MOBL3.ger.corp.intel.com> References: <20170228113511.GA28584@localhost.localdomain> <20170228115703.GA4656@bricha3-MOBL3.ger.corp.intel.com> <20170228120833.GA30817@localhost.localdomain> <20170228135226.GA9784@bricha3-MOBL3.ger.corp.intel.com> <20170228175423.GA23591@localhost.localdomain> <20170301094702.GA15176@bricha3-MOBL3.ger.corp.intel.com> <20170301111753.1223a01e@platinum> <20170301104257.GB25032@bricha3-MOBL3.ger.corp.intel.com> <20170301120633.6817036b@platinum> <20170301111942.GA403@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170301111942.GA403@localhost.localdomain> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.7.2 (2016-11-26) Subject: Re: [dpdk-dev] [PATCH v1 01/14] ring: remove split cacheline build setting 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: Wed, 01 Mar 2017 12:12:57 -0000 On Wed, Mar 01, 2017 at 04:49:56PM +0530, Jerin Jacob wrote: > On Wed, Mar 01, 2017 at 12:06:33PM +0100, Olivier Matz wrote: > > On Wed, 1 Mar 2017 10:42:58 +0000, Bruce Richardson wrote: > > > On Wed, Mar 01, 2017 at 11:17:53AM +0100, Olivier Matz wrote: > > > > On Wed, 1 Mar 2017 09:47:03 +0000, Bruce Richardson > > > > wrote: > > > > > So given that there is not much difference here, is the MIN_SIZE i.e. > > > > > forced 64B, your preference, rather than actual cacheline-size? > > > > > > [...] > > > > > > > I don't quite like this macro CACHE_LINE_MIN_SIZE. For me, it does not > > > > mean anything. The reasons for aligning on a cache line size are > > > > straightforward, but when should we need to align on the minimum > > > > cache line size supported by dpdk? For instance, in mbuf structure, > > > > aligning on 64 would make more sense to me. > > > > > > > > So, I would prefer using (RTE_CACHE_LINE_SIZE * 2) here. If we don't > > > > want it on some architectures, or if this optimization is only for Intel > > > > (or all archs that need this optim), I think we could have something > > > > like: > > > > > > > > /* bla bla */ > > > > #ifdef INTEL > > > > #define __rte_ring_aligned __rte_aligned(RTE_CACHE_LINE_SIZE * 2) > > > > #else > > > > #define __rte_ring_aligned __rte_aligned(RTE_CACHE_LINE_SIZE) > > > > #endif > > > > > > > I would agree that CACHE_LINE_MIN_SIZE probably doesn't make any sense > > > here, but I'm happy to put in any suitable scheme that others are happy > > > with. The options are: > > > > > > * Keep as-is: > > > adv: simplest option, disadv: wastes 128B * 2 on some platforms > > > * Change to MIN_SIZE: > > > adv: no ifdefs, disadv: doesn't make much sense logically here > > > * Use ifdefs: > > > adv: each platform gets what's best for it, disadv: untidy code, may > > > be harder to maintain > > > * Use hard-coded 128: > > > adv: short and simple, disadv: misses any logical reason why 128 is > > > used, i.e. magic number > > > > > > I'm ok with any option above. > > > > I'd vote for "Keep as-is" or "Use ifdefs". > > I'd vote for "Use ifdefs", default configuration can be "RTE_CACHE_LINE_SIZE > * 2" but a target can override if required. > > > Ok. Will update with some #ifdefs in v2. /Bruce