> 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. > > Regards, > > -- > Nélio Laranjeiro > 6WIND Regards, Keith