From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0054.outbound.protection.outlook.com [157.56.112.54]) by dpdk.org (Postfix) with ESMTP id 45834C5BA for ; Mon, 4 May 2015 19:26:58 +0200 (CEST) Authentication-Results: 6wind.com; dkim=none (message not signed) header.d=none; Received: from cchemparathy-ubuntu (12.218.212.162) by VI1PR02MB0800.eurprd02.prod.outlook.com (25.162.14.15) with Microsoft SMTP Server (TLS) id 15.1.154.19; Mon, 4 May 2015 17:26:56 +0000 Date: Mon, 4 May 2015 10:26:39 -0700 From: Cyril Chemparathy To: Olivier MATZ Message-ID: <20150504102639.43e92ef4@cchemparathy-ubuntu> In-Reply-To: <554740D1.4050104@6wind.com> References: <1430324134-25654-1-git-send-email-cchemparathy@ezchip.com> <554740D1.4050104@6wind.com> Organization: EZchip X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [12.218.212.162] X-ClientProxiedBy: CO2PR06CA018.namprd06.prod.outlook.com (10.141.242.18) To VI1PR02MB0800.eurprd02.prod.outlook.com (25.162.14.15) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR02MB0800; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:VI1PR02MB0800; BCL:0; PCL:0; RULEID:; SRVR:VI1PR02MB0800; X-Forefront-PRVS: 05669A7924 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(24454002)(51444003)(479174004)(51704005)(46406003)(86362001)(40100003)(50466002)(33646002)(87976001)(110136002)(42186005)(92566002)(19580395003)(33716001)(46102003)(2950100001)(23726002)(50986999)(66066001)(122386002)(76176999)(19580405001)(5001960100002)(62966003)(50226001)(77156002)(47776003)(107986001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR02MB0800; H:cchemparathy-ubuntu; FPR:; SPF:None; MLV:sfv; LANG:en; X-OriginatorOrg: ezchip.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2015 17:26:56.7847 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR02MB0800 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 00/10] Improve cast alignment for strict aligned machines X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 17:26:58 -0000 On Mon, 4 May 2015 11:50:09 +0200 Olivier MATZ wrote: > Hi Cyril, > > On 04/29/2015 06:15 PM, Cyril Chemparathy wrote: > > This series contains a few improvements that allow the DPDK code > > base to build properly on machines that enforce strict pointer cast > > alignment constraints. > > > > When dealing with packet data which could be arbitrarily aligned, > > we get the compiler to do the right thing by (a) making sure that > > header types are packed, and (b) introducing and using > > unaligned_uint(16|32|64)_t types when upcasting from byte pointers. > > > > In a few other instances, we know apriori that the pointer cast > > cannot possibly break alignment. This applies to the changes in > > mempool, hash, mbuf, and the ethdev stats code. Here, we simply > > silence the compiler by casting through (void *) using the > > RTE_PTR_(ADD|SUB) macros. > > > > Finally, we introduce a new rte_pktmbuf_mtod_offset() helper to > > return a type casted pointer to an offset within the packet data. > > This replaces the following commonly used pattern: > > (struct foo *)(rte_pktmbuf_mtod(m, char *) + offset) > > with: > > rte_pktmbuf_mtod_offset(m, struct foo *, offset) > > To ensure consistency, the above transform was applied throughout > > the code base using the coccinelle semantic patching tool. > > > > Before diving into the patches, I'm wondering if adding aligned(1) or > (packed) attribute at some places would have a performance impact on > supported architectures (Intel or IBM Power). Did you manage to test > it? > I don't expect to see a performance impact on x86. I don't really have a way of trying this out on PPC, and I could use some help here. Overall, I think that the few places where we've injected aligned(1) or packed really warrant the insertion for correctness. These are places where packet data of unknown alignment is being typecast and dereferenced. In such cases, _not_ representing the unaligned nature of these accesses breaks machines with strict alignment. Thanks -- Cyril.