Re: [PATCH net-next v4 1/4] ieee802154: add generic header handling routines

["Phoebe Buckheister" <phoebe.buckheister@itwm.fraunhofer.de>]

> Why have an intermediate copy when that's not necessary at all?  It
> seems like pure overhead to be.
>
> Furthermore, cpu's have byte-shifting load and store instructions
> which will be used if you make use of the 'p' versions of the endian
> swap functions, such as cpu_to_le16p().
>
> So it's going to cost basically nothing.

I didn't mean the runtime cost of any conversion that might happen, I was
thinking about how much these conversions would affect the code that uses
these header structs. While for the u16/u32 fields this might be not much,
it will be more for the hardware address fields since these are stored as
the little endian encoding of u64 field you get when reading the u8[8] as
a __be64. If I understand you correctly, these fields would also have to
be in network byte order in the header struct, introducing copy-and-swaps
in every upper layer that uses those addresses and making address matching
harder since memcmp won't work anymore.

What would be better here? Explicit endianness on all fields for
consistency and thus __le64 for EUI64 members with copy-swap functions to
convert those addresses into u8[8] where required, explicit endianness on
everything except addresses, or keeping it as is? I'm honestly not sure.

I want to note here that struct ieee802154_addr, which holds the address
information and is also used by BSD socket calls, has always used host
byte order for its own fields. This might itself be a huge mistake, but it
is relevant to this discussion.