On Wed, 1 Mar 2017 10:42:58 +0000, Bruce Richardson <bruce.richard...@intel.com> 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 > > <bruce.richard...@intel.com> 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
