From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0077.outbound.protection.outlook.com [157.56.112.77]) by dpdk.org (Postfix) with ESMTP id 77C57C910 for ; Fri, 19 Jun 2015 19:18:33 +0200 (CEST) Received: from DB5PR02MB0791.eurprd02.prod.outlook.com (10.161.243.15) by DB5PR02MB0806.eurprd02.prod.outlook.com (10.161.243.152) with Microsoft SMTP Server (TLS) id 15.1.190.14; Fri, 19 Jun 2015 17:18:33 +0000 Authentication-Results: 6wind.com; dkim=none (message not signed) header.d=none; Received: from cchemparathy-ubuntu (12.218.212.162) by DB5PR02MB0791.eurprd02.prod.outlook.com (10.161.243.15) with Microsoft SMTP Server (TLS) id 15.1.190.14; Fri, 19 Jun 2015 17:18:31 +0000 Date: Fri, 19 Jun 2015 10:18:17 -0700 From: Cyril Chemparathy To: Olivier MATZ Message-ID: <20150619101817.4884a947@cchemparathy-ubuntu> In-Reply-To: <55843C41.7010702@6wind.com> References: <1430324134-25654-1-git-send-email-cchemparathy@ezchip.com> <1430324134-25654-2-git-send-email-cchemparathy@ezchip.com> <55843C41.7010702@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: DM2PR07CA0036.namprd07.prod.outlook.com (10.141.52.164) To DB5PR02MB0791.eurprd02.prod.outlook.com (25.161.243.15) X-Microsoft-Exchange-Diagnostics: 1; DB5PR02MB0791; 2:OGaNiYqz8PGBj848Y3CbwFimv6jIAwNWBerrWbpzmL17CAe4LYLciH7CjLjR3Wwz; 2:/+K7LBHIuvDgzCUBNPRHmxaQ+PAEDDJo27JD4udK59yb4jBtHQnkNoLtHRLat9EOJqRuRrASqCHw8346rBt4wyZkQ+KQqV6ik9D/SS6HrohTZuAoBCvGLKJNH/cHOiwTBTqqzY0xePtD1Ty3hVTcGA==; 6:wyabU3QU1rpeaLdUwR7X3JtCCCJ0oQ6QL0tPhZDIQeDuI4mVVN1IwHSx2lJdjyf+/9ZqlfoxOOAJ5R0WRTMR391rG6UZfWUI5qv7D1Y7Gy4WaSytiVpVZRUvh73bfHfvZOC9uAiv+kzFbqNUBfTlVA==; 3:9AfzhN1k5V25nImGlstrGk04Lg6BgHxQHUA+3A5a8+dd4eMo2iHGXQ1X58zIOZbO/zcYvei0ELLVyaPw8OuUDITJoG5zDqNtNPdCQukPRA/vdDHhBijHGUBgtBjVGkTC4TZ5LgejXT8eeMKU2gTd3uXX9uCOpPOLn5lDKOIBZwxKUPEcmi0PdYydPln24Apbp9I/j+jvJ3dncNB2rBJaBMmutt/uI8JNm7UF8TBeQQuq1FpTqe0fsmPn4KanyyEvyr16NHE82mw5nsmPy6dEuWty7uYTLZkqumEhFaOGCxQ= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB5PR02MB0791; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB5PR02MB0806; 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:DB5PR02MB0791; BCL:0; PCL:0; RULEID:; SRVR:DB5PR02MB0791; X-Forefront-PRVS: 0612E553B4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(24454002)(479174004)(76104003)(377454003)(92566002)(19580405001)(23726002)(66066001)(33716001)(47776003)(42186005)(46406003)(33646002)(50986999)(76176999)(46102003)(19580395003)(5001920100001)(86362001)(575784001)(5001960100002)(50226001)(122386002)(40100003)(2950100001)(62966003)(189998001)(77096005)(50466002)(77156002)(110136002)(107986001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR02MB0791; H:cchemparathy-ubuntu; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB5PR02MB0791; 9:YKU7G5Kt61X7bV7GNbManR3FUgUH5rmVF5O0iR/0mBkW/NOXxTClXPKisMSTIPm1MNOOn2DgqrSwQN6u6hWdrgaBWZQOintStcvXGJeHwakTiwJzFatZMty8YrsyLj8yNG0UTgkdHexvtO16sYqp7qx1VvBAH6AEzpWxTIP5g9et3vXqoMUOd68C5rhsVOfkZ4Huqm5Tf0Oa78v3F+wV1jTGFYameeTac0K+j9NZ8Uo+olo6rFTtPfDnSHKhiNF6Z62kQbuNbgON7DjcJSq9RIV/6pNIUcL52t65oEIW7Q3ZhJ7iHDubPhxBgfJGWRLBp0o6w9iFKIb0RfmzI/OBlNGqCRuSb75ZKQFXzJSWM3IhyKgTmUZ2giQvwm20brxuI9yOjce3rOO9AOl+fn5ma0qL0uszbV0rQiT7GaBbgctftmxkkLeey5+XJd8h6P9Wj3HkzxbDn1vSFpP6jx0r14OXEtTKjWO3oywwgbC9FJ8kwjelvSGt4Xr9eGctEraAZLRagS9GJPNIG9+I6TIwSJSUHw/L1HRusILuHP9xkTSRGeNsXqrCK2Whfj/VbFeBbVDk/UPcDx25umo7jL75zM8LhWpUFtaVl/JIeWUSJbnjLcGT3d6/6xU+a/IWF6pWcWkYbWbPQcnqHyRtDc3cgr7s+1BKRGGTNA0KOSoqWZXtRu5w9zkM2z52vUiQRY1hNIBaiGN/p9GJjLVLNBNCDUKGYQd2nsiDeJ5DVp61L1wWrwpgOshVue0UGUS/I0+04nMqictbt9WuLmOjFZPTfNRotz4qX8d417gyvi7pGbYskgVzenxy6L404cac6f/Oc9yshvfGzjfs2GMFlhpGL7j4jfNy32HKtj8GX8v9cO/7g89vWsoGESFzEZEUfuMIG0BBQNzBYUZaD4JsGpWVZlBUt6yGOhu7UvEDwR+2Hp8= X-Microsoft-Exchange-Diagnostics: 1; DB5PR02MB0791; 3:8i1ixVNGVrqHnq9KMzdkYHqY8ET/JLgQ3OUNmvQ8byJd9T7ItueLP2v3VDHMukIE9C3/G/ec+orFC4hqhQ3FDKYilgCWXiiZ5o3wTRP4F5xj14YOJESLxoEEIHhJKh21E9GZEfwqkrrmj31AQO9FDQ==; 10:nT89+VKRJXn9zzs5Aeq0i4SyvoegmxD/R28o4un0RTNVnOmikJ7bKSMcsTJ94LF9wAo/sHH+ZpPDC9uJUT0s0yzNdRfPavqXypKQthQQqR8=; 6:i9bzkd/P5iSDS4Fow4XnE/F9FE9Eb7IPTnAf3czDSsEgseIN+CIiR1dI57Ztp12O X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2015 17:18:31.6718 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR02MB0791 X-Microsoft-Exchange-Diagnostics: 1; DB5PR02MB0806; 2:/QyTiEWNQOLCwZVLv7fhGa3ErCdtel4s9FnDykwwIuX044A/4eK10D7gQKIszhnm; 2:XH0i27piVyCCMTfJgAdt1Kt4cWtWm3A3PVIM0e+AmmSZ4ADDjgN65JlYh+tAH87eXPYW3TKiPdpWiQmfiNkgH4hl8/WEx1iZ/1AeQu84gedVvqNurLUytXXdRTopmF079AW8E8+/8IglVAItm5PPBg==; 9:TZcXDU2f6V9cBuQtbT8Cc0Rb0RusBRYQkWXsvWGXp1g7B4nVKXxLiD9UiWIf+Q5rN7Uz0ReAP1h2SPPy9s/wHpVU7BGQTiftPH6TMfJX1ASIa/D8UOGIaVqbTx+CxCMeomjR6L+WA4C9MNmU7iLFAA== X-OriginatorOrg: ezchip.com Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 01/10] eal: add and use unaligned integer types 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: Fri, 19 Jun 2015 17:18:33 -0000 On Fri, 19 Jun 2015 17:58:57 +0200 Olivier MATZ wrote: > Hello Cyril, > > First, sorry commenting that late. My first intent was to benchmark > with your modifications, but I did not find the time for it. > > So, please find some comments on your series below so it can be pushed > for 2.1. > > On 04/29/2015 06:15 PM, Cyril Chemparathy wrote: > > 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. > > > > This is currently unimplemented on ICC and clang, and equivalents > > will need to be plugged in. > > > > Signed-off-by: Cyril Chemparathy > > --- > > app/test-pmd/flowgen.c | 4 ++-- > > app/test-pmd/txonly.c | 2 +- > > app/test/packet_burst_generator.c | 4 ++-- > > app/test/test_mbuf.c | 16 ++++++++-------- > > lib/librte_eal/common/include/rte_common.h | 10 ++++++++++ > > lib/librte_ether/rte_ether.h | 2 +- > > lib/librte_ip_frag/rte_ipv4_reassembly.c | 4 ++-- > > 7 files changed, 26 insertions(+), 16 deletions(-) > > > > [...] > > diff --git a/lib/librte_eal/common/include/rte_common.h > > b/lib/librte_eal/common/include/rte_common.h index c0ab8b4..3bb97d1 > > 100644 --- a/lib/librte_eal/common/include/rte_common.h > > +++ b/lib/librte_eal/common/include/rte_common.h > > @@ -61,6 +61,16 @@ extern "C" { > > > > /*********** Macros to eliminate unused variable warnings ********/ > > > > +#if defined(__GNUC__) > > +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 > > + > > Shouldn't we only define these unaligned types for architectures that > have strict alignment constraints ? I am a bit puzzled by only > defining it when compiling with gcc: is it because only gcc triggers > a warning? If yes, I'm not sure it's a good reason. > > Maybe we could have a compile-time option to enable these types, and > this option would be set for architectures that require it only. The > advantage would be to ensure there's no modification on x86. > > What do you think? > Fair enough. I like that better than keying off of GCC or anything like that. I will change this patch accordingly for the next revision. > cosmetic: the definitions should go above the comment line that refers > to the macro below. > > For the rest of the series (except a small comment on patch 8/10, > see the other mail): > Acked-by: Olivier Matz > >