From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id B92342C07 for ; Tue, 6 Dec 2016 18:00:09 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP; 06 Dec 2016 09:00:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,310,1477983600"; d="scan'208";a="794928057" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by FMSMGA003.fm.intel.com with ESMTP; 06 Dec 2016 09:00:06 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.43]) by IRSMSX104.ger.corp.intel.com ([169.254.5.52]) with mapi id 14.03.0248.002; Tue, 6 Dec 2016 17:00:05 +0000 From: "Ananyev, Konstantin" To: =?iso-8859-1?Q?N=E9lio_Laranjeiro?= , =?iso-8859-1?Q?Morten_Br=F8rup?= CC: "Wiles, Keith" , "Richardson, Bruce" , "dev@dpdk.org" , Olivier Matz , "Lu, Wenzhuo" , "Adrien Mazarguil" Thread-Topic: [dpdk-dev] [PATCH] net: introduce big and little endian types Thread-Index: AQHSOpqjJZEmwRN0kU6+9TJvUFcv9KD4oKeAgADKCYCAAX/vkIAAD1IAgAALoxCAABAkgIAAD9eggAAHMYCAAApngIAADxeAgAAGCjA= Date: Tue, 6 Dec 2016 17:00:05 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583F0E4AC3@irsmsx105.ger.corp.intel.com> References: <2601191342CEEE43887BDE71AB9772583F0E3F68@irsmsx105.ger.corp.intel.com> <20161205120603.GL21794@autoinstall.dev.6wind.com> <2601191342CEEE43887BDE71AB9772583F0E4632@irsmsx105.ger.corp.intel.com> <20161206115502.GA12224@bricha3-MOBL3.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F0E46DC@irsmsx105.ger.corp.intel.com> <20161206133427.GB15416@bricha3-MOBL3.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F0E47E1@irsmsx105.ger.corp.intel.com> <7E1BBBA1-F384-4235-8A82-4B0D6DC0889C@intel.com> <98CBD80474FA8B44BF855DF32C47DC359EAA47@smartserver.smartshare.dk> <20161206162807.GS21794@autoinstall.dev.6wind.com> In-Reply-To: <20161206162807.GS21794@autoinstall.dev.6wind.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 17:00:11 -0000 > -----Original Message----- > From: N=E9lio Laranjeiro [mailto:nelio.laranjeiro@6wind.com] > Sent: Tuesday, December 6, 2016 4:28 PM > To: Morten Br=F8rup > Cc: Wiles, Keith ; Ananyev, Konstantin ; Richardson, Bruce > ; dev@dpdk.org; Olivier Matz ; Lu, Wenzhuo ; Adrien > Mazarguil > Subject: Re: [dpdk-dev] [PATCH] net: introduce big and little endian type= s >=20 > Hi all, >=20 > On Tue, Dec 06, 2016 at 04:34:07PM +0100, Morten Br=F8rup wrote: > > Hi all, > > > > Being a big fan of strong typing, I really like the concept of > > explicit endian types. Especially if type mismatches can be caught at > > compile time. >=20 > +1, >=20 > > However, I think it is too late! That train left the station when the > > rest of the world - including libraries and headers that might be > > linked with a DPDK application - decided to use implicit big endian > > types for network protocols, and has been doing so for decades. And, > > with all respect, I don't think the DPDK community has the momentum > > required to change this tradition outside the community. >=20 > I don't think, those types can be use from now on to help new API to > expose explicitly the type they are handling. For older ones, it can > come in a second step, even if there are not so numerous. Only few of > them touches the network types. >=20 > > Furthermore: If not enforced throughout DPDK (and beyond), it might > > confuse more than it helps. >=20 > The current situation is more confusing, nobody at any layer can rely > on a precise information, at each function entry we need to verify if > the callee has already handled the job. The only solution is to browse > the code to have this information. >=20 > Think about any function manipulating network headers (like flow director > or rte_flow) from the API down to the PMD, it may take a lot of time to > know at the end if the data is CPU or network ordered, with those types > it takes less than a second. Hmm, suppose I have such piece of code: struct ipv4_hdr iph; iph.total_length =3D val0; iph.packet_id =3D val1; ... iph.dst_addr =3D valn; hton_whole_ipv4_hdr_at_once(&iph); How I suppose to indicate via these new types that=20 hton_whole_ipv4_hdr_at_once() expects ipv4_hdr fields in host byte order? Other than just putting it into the doc? Konstantin