From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v2 05/10] eal: add and use unaligned integer types Date: Mon, 22 Jun 2015 18:56:14 +0200 Message-ID: <4657204.d81FlWYDKy@xps13> References: <1434735293-15469-1-git-send-email-cchemparathy@ezchip.com> <4101438.HZvvEl93na@xps13> <20150622094726.2a751267@cchemparathy-ubuntu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: Cyril Chemparathy Return-path: Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by dpdk.org (Postfix) with ESMTP id 9BF5EC406 for ; Mon, 22 Jun 2015 18:57:16 +0200 (CEST) Received: by wibdq8 with SMTP id dq8so81436271wib.1 for ; Mon, 22 Jun 2015 09:57:16 -0700 (PDT) In-Reply-To: <20150622094726.2a751267@cchemparathy-ubuntu> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2015-06-22 09:47, Cyril Chemparathy: > On Mon, 22 Jun 2015 11:36:20 +0200 > Thomas Monjalon wrote: > > > 2015-06-19 10:34, Cyril Chemparathy: > > > On machines that are strict on pointer alignment, current code > > > breaks on GCC's -Wcast-align checks on casts from narrower to wider > > > types. This patch introduces new unaligned_uint(16|32|64)_t types, > > > which correctly retain alignment in such cases. > > [...] > > > +#ifdef RTE_ARCH_STRICT_ALIGN > > > +typedef uint64_t unaligned_uint64_t __attribute__ ((aligned(1))); > > > +typedef uint32_t unaligned_uint32_t __attribute__ ((aligned(1))); > > > +typedef uint16_t unaligned_uint16_t __attribute__ ((aligned(1))); > > > +#else > > > +typedef uint64_t unaligned_uint64_t; > > > +typedef uint32_t unaligned_uint32_t; > > > +typedef uint16_t unaligned_uint16_t; > > > +#endif > > > > CONFIG_RTE_ARCH_STRICT_ALIGN should be declared (and disabled) in > > config templates. > > Sure. Will include in v3. I'm assuming this goes into > common_linuxapp and common_bsdapp, allowing specific architectures to > override if necessary. Correct? Yes, thanks