From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH 0/3] Add RTE_ prefix to CACHE_LINE related macros Date: Thu, 27 Nov 2014 14:58:05 +0100 Message-ID: <3199535.XIuFQf7Fcl@xps13> References: <1416399968-348-1-git-send-email-sergio.gonzalez.monroy@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Sergio Gonzalez Monroy Return-path: In-Reply-To: <1416399968-348-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" > Currently DPDK sets CACHE_LINE_SIZE value to 64 by default if the macro is > not already defined. > > FreeBSD defines a CACHE_LINE_SIZE macro in the header file: > /usr/include/machine/param.h > > These macros set different values, 64 in DPDK vs 128 in FreeBSD, causing > broken application behaviour if the system header file is included before > rte_memory.h (where DPDK sets CACHE_LINE_SIZE). > > This is the case for some examples like ip_fragmentation. > In such application, DPDK library code would assume 64 bytes cache line size > and the application code would assume 128 cache line size. > Given that mbufs now take two cache lines and that the structure is being > aligned based on this value, the result is broken application functionality. > > The approach to fix this issue is to add RTE_ prefix to all CACHE_LINE_xxxx > related macros to avoid conflicts. > > Sergio Gonzalez Monroy (3): > Add RTE_ prefix to CACHE_LINE_SIZE macro > Add RTE_ prefix to CACHE_LINE_MASK macro > Add RTE_ prefix to CACHE_LINE_ROUNDUP macro Updated and applied in 1 commit. Thanks -- Thomas