> -----Original Message----- > From: Nélio Laranjeiro [mailto:nelio.laranje...@6wind.com] > Sent: Tuesday, December 6, 2016 4:28 PM > To: Morten Brørup <m...@smartsharesystems.com> > Cc: Wiles, Keith <keith.wi...@intel.com>; Ananyev, Konstantin > <konstantin.anan...@intel.com>; Richardson, Bruce > <bruce.richard...@intel.com>; dev@dpdk.org; Olivier Matz > <olivier.m...@6wind.com>; Lu, Wenzhuo <wenzhuo...@intel.com>; Adrien > Mazarguil <adrien.mazarg...@6wind.com> > Subject: Re: [dpdk-dev] [PATCH] net: introduce big and little endian types > > Hi all, > > On Tue, Dec 06, 2016 at 04:34:07PM +0100, Morten Brørup 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. > > +1, > > > 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. > > 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. > > > Furthermore: If not enforced throughout DPDK (and beyond), it might > > confuse more than it helps. > > 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. > > 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 = val0; iph.packet_id = val1; ... iph.dst_addr = valn; hton_whole_ipv4_hdr_at_once(&iph); How I suppose to indicate via these new types that hton_whole_ipv4_hdr_at_once() expects ipv4_hdr fields in host byte order? Other than just putting it into the doc? Konstantin
