From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id 4033B2BB1 for ; Wed, 1 Mar 2017 12:06:36 +0100 (CET) Received: by mail-wm0-f53.google.com with SMTP id u199so33331739wmd.1 for ; Wed, 01 Mar 2017 03:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=PfSE7dIVXsRHkosGsBsthwmNrx0Fil3vgrFaizOoohw=; b=Z4A9ax1OpshLfqAyqqH+3SjXaLBbZi6jLX8tBJLVNT/61JYYq6HlXbkmiHkFMPgHmK qcq9zoWKUTsUiusW2ICob8IsAVnVEHuqxfJfc7J5JmmCFiZoA4Aouw99Ol/XzOlPRHyn avugnyl73Tt61P4u3jTBUeN9eSFkfsesGS+j3qXcZacaLfudoRup4qUm+jXo/hCGU/iY B5phjh4kwGd7XKVoU6muH1kYy4cFy83r146M0cwbU2kBeuBQcvwIVDTcUk+qG2xEdI3o jnx0hDiT7BydVi0c1OziAJfcc56Kbapx7GZPBlbhpn9fvyc/GMwn216l3IVrYMwQ4OcM RFgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=PfSE7dIVXsRHkosGsBsthwmNrx0Fil3vgrFaizOoohw=; b=cbR1CXbvvlQbsYjEn1IASwWkjI7IEHwx9fHrRToiFk+W9MqQDLCFX/x/qymmLMyuMM IS7UfZo+fcwOrSoKmn8QcF4BR3rTEWpSW8QeUrk4dixnl8efcLyXOg3LKpXIrN+t6jUp e/O38ipEL+Dao1jqgnCvU9M/ODQKBqrK4rpd/rx3Rr1p9VVMUUPW0w1A3GIOlKHj0h1V oPU0JkWwEOoD+wieWd6/AawfG2aiExvRJVc9GN3MPiLy5+LzKRnK6RsSW6dwkJ9iLR0u d8Rix5VbHvJfEP9+ossqmg12z25TlKNgFW5GnWQWHsqykyFnUeaYM7DWUqYyokOSG6Ti w0OA== X-Gm-Message-State: AMke39l83cmFec/0tgllOvb0AdH8/T7Z/MnrS95FcicAYQYDQzKwxlRzUVCnhHAIZFz9Geip X-Received: by 10.28.37.195 with SMTP id l186mr2754054wml.73.1488366395770; Wed, 01 Mar 2017 03:06:35 -0800 (PST) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id t30sm6112969wra.52.2017.03.01.03.06.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 01 Mar 2017 03:06:35 -0800 (PST) Date: Wed, 1 Mar 2017 12:06:33 +0100 From: Olivier Matz To: Bruce Richardson Cc: Jerin Jacob , dev@dpdk.org Message-ID: <20170301120633.6817036b@platinum> In-Reply-To: <20170301104257.GB25032@bricha3-MOBL3.ger.corp.intel.com> References: <20170223172407.27664-1-bruce.richardson@intel.com> <20170223172407.27664-2-bruce.richardson@intel.com> <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> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 11:06:36 -0000 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". Olivier