From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 6C6C72BAF for ; Tue, 6 Dec 2016 12:55:13 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 06 Dec 2016 03:55:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,310,1477983600"; d="scan'208";a="1068567708" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.64]) by orsmga001.jf.intel.com with SMTP; 06 Dec 2016 03:55:03 -0800 Received: by (sSMTP sendmail emulation); Tue, 06 Dec 2016 11:55:02 +0000 Date: Tue, 6 Dec 2016 11:55:02 +0000 From: Bruce Richardson To: "Ananyev, Konstantin" Cc: =?iso-8859-1?Q?N=E9lio?= Laranjeiro , "dev@dpdk.org" , Olivier Matz , "Lu, Wenzhuo" , Adrien Mazarguil Message-ID: <20161206115502.GA12224@bricha3-MOBL3.ger.corp.intel.com> References: <2601191342CEEE43887BDE71AB9772583F0E3F68@irsmsx105.ger.corp.intel.com> <20161205120603.GL21794@autoinstall.dev.6wind.com> <2601191342CEEE43887BDE71AB9772583F0E4632@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0E4632@irsmsx105.ger.corp.intel.com> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.7.1 (2016-10-04) Subject: Re: [dpdk-dev] [PATCH] net: introduce big and little endian types X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 11:55:13 -0000 On Tue, Dec 06, 2016 at 11:23:42AM +0000, Ananyev, Konstantin wrote: > Hi Neilo, > > > Hi Neilo, > > > > > > > > This commit introduces new rte_{le,be}{16,32,64}_t types and updates > > > > rte_{le,be,cpu}_to_{le,be,cpu}_*() and network header structures > > > > accordingly. > > > > > > > > Specific big/little endian types avoid uncertainty and conversion mistakes. > > > > > > > > No ABI change since these are simply typedefs to the original types. > > > > > > It seems like quite a lot of changes... > > > Could you probably explain what will be the benefit in return? > > > Konstantin > > > > Hi Konstantin, > > > > The benefit is to provide documented byte ordering for data types > > software is manipulating to determine when network to CPU (or CPU to > > network) conversion must be performed. > > Ok, but is it really worth it? > User can still make a mistake and forget to call ntoh()/hton() at some particular place. > From other side most people do know that network protocols headers are usually in BE format. > I would understand the effort, if we'll have some sort of tool that would do some sort of static code analysis > based on these special types or so. > Again, does it mean that we should go and change uint32_t to rte_le_32 inside all Intel PMDs > (and might be in some others too) to be consistent? > Konstantin > I actually quite like this patch as I think it will help make things clear when the user is possibly doing something wrong. I don't think we need to globally change all PMDs to use the types, though. One thing I'm wondering though, is if we might want to take this further. For little endian environments, we could define the big endian types as structs using typedefs, and similarly the le types on be platforms, so that assigning from the non-native type to the native one without a transformation function would cause a compiler error. /Bruce