On Tue, Feb 13, 2024 at 08:27:52PM +0100, Morten Brørup wrote: > > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com] > > Sent: Tuesday, 13 February 2024 19.48 > > > > On Tue, Feb 13, 2024 at 05:58:21PM +0100, Morten Brørup wrote: > > > > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com] > > > > Sent: Tuesday, 13 February 2024 07.46 > > > > > > > > Replace the use of RTE_MARKER<x> with C11 anonymous unions to > > improve > > > > code portability between toolchains. > > > > > > How about combining the cacheline 0 marker and padding, like this: > > > > this seems like a good suggestion i will evaluate it. at least it gets > > rid of all the extra nesting if there are no unforseen problems. > > > > > > > > struct rte_mbuf { > > > - RTE_MARKER cacheline0; > > > + union { > > > + char cacheline0[RTE_CACHE_LINE_MIN_SIZE]; > > > > > > + struct { > > > - void *buf_addr; /**< Virtual address of segment buffer. > > */ > > > + void *buf_addr; /**< Virtual address of segment > > buffer. */ > > > #if RTE_IOVA_IN_MBUF > > > > > > > > > You could do the same with the cacheline1 marker: > > > > yeah, i wondered if i should. i'll do it since it does seem more > > consistent to just pad out both cachelines explicitly instead of just > > doing all but the last. > > > > we probably don't need to align struct rte_mbuf type if we do since it > > will cause it to be naturally aligned to RTE_CACHE_LINE_MIN_SIZE. > > We still need to align struct rte_mbuf to cache line size. > RTE_CACHE_LINE_MIN_SIZE is 64, like the cache line size on Intel arch, > but cache line size is 128 byte on POWER architecture and Apple M2.
RTE_CACHE_LINE_SIZE vs RTE_CACHE_LINE_MIN_SIZE forgot about that.
