> -----Original Message----- > From: Wiles, Keith > Sent: Tuesday, December 6, 2016 4:32 PM > To: Nélio Laranjeiro <nelio.laranje...@6wind.com> > Cc: Morten Brørup <m...@smartsharesystems.com>; Ananyev, Konstantin > <konstantin.anan...@intel.com>; Richardson, Bruce > <bruce.richard...@intel.com>; DPDK <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 > > > > On Dec 6, 2016, at 10:28 AM, Nélio Laranjeiro > <nelio.laranje...@6wind.com> wrote: > > > > 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. > > Still Documentation should handle this problem without code and ABI > changes. >
While my additional suggestion of compiler-enforced endian correctness may break the ABI (though even that is not certain since parameters would be the same size, just from a compiler syntax analysis side the result would be different, I think), if I'm reading it correctly, Neilo's original suggestion of just using typedefs for big or little endian won't affect the ABI as the underlying types are exactly the same as before. Only the type name has changed to document for the user the endianness the expected data is to be. In effect, the original suggestion is a documentation patch - just the code is the documentation. Regards, /Bruce
