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