Re: [dpdk-dev] [dpdk-stable] [PATCH] bugfix: rte_raw_checksum

["Morten Brørup" <mb@smartsharesystems.com>]

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Wednesday, June 24, 2020 5:04 PM
> 
> 24/06/2020 15:00, Morten Brørup:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > Sent: Wednesday, June 24, 2020 2:22 PM
> > >
> > > 27/05/2020 15:40, guohongzhi:
> > > > From: Hongzhi Guo <guohongzhi1@huawei.com>
> > > >
> > > > __rte_raw_cksum should consider Big Endian.
> > >
> > > We need to explain the logic in the commit log.
> >
> > Having grown up with big endian CPUs, reading the final byte like
> this is obvious to me. I struggle understanding the little endian way
> of reading the last byte. (Not really anymore, but back when little
> endian was unfamiliar to me I would have struggled.)
> >
> > An RFC (I can't remember which) describes why the same checksum
> calculation code works on both big and little endian CPUs. Is it this
> explanation you are asking for?
> 
> This explanation may be interesting.
> 

RFC 1071, especially chapter 3.

Please note that big endian is considered "Normal" order in the RFC. :-)

> 
> > > > Signed-off-by: Hongzhi Guo <guohongzhi1@huawei.com>
> > > > ---
> > > > +#if (RTE_BYTE_ORDER == RTE_BIG_ENDIAN)
> > > > +		sum += *((const uint8_t *)u16_buf) << 8;
> > > > +#else
> > > >  		sum += *((const uint8_t *)u16_buf);
> > > > +#endif
> > >
> > > *((const uint8_t *)u16_buf) should be an uint8_t.
> > > What is the expected behaviour of shifting 8 bits of a byte?
> >
> > Yes, the value will be an uint8_t type. But the shift operation will
> cause the compiler to promote the type to int before shifting it.
> 
> This is the explanation I was looking for :-)
> 
>