RE: [lwip-users] Struct packing/alignment problems

[Mountifield, Tony]

> I have been thinking some more.. Four u8_t is actually not 
> very optimal, two u16_t might be a better solution.
> Two u16_t fields equals about the same performance as a
> unaligned u32_t even on systems that do support unaligned
> memory accesses, so replacing all 32 bit fields with two
> u16_t should work fine for all architectures.
> (A 32bit unaligned memory read usually results in two memory 
> read cycles)

This is quite a reasonable thought. The reason I went for bytes
was because ntohl and htonl need to deal with bytes anyway.
I hate all the shifting and masking, and prefer an approach
such as this:

#if LITTLE_ENDIAN
u32_t ntohl(u32_t addr)
{
  u32_t result;
  ((u8_t *)&result)[0] = ((u8_t *)&addr)[3];
  ((u8_t *)&result)[1] = ((u8_t *)&addr)[2];
  ((u8_t *)&result)[2] = ((u8_t *)&addr)[1];
  ((u8_t *)&result)[3] = ((u8_t *)&addr)[0];
  return result;
}
#endif

This then easily translates to the array equivalent for the input parameter. 
For the reverse direction I defined a function with two args:

void htonlb(u8_t *naddr, u32_t haddr);

However...

> I have also been considering a second approach where I add a 
> 16bit pad to the very beginning of the ethernet header.
> No data must be rearranged, the packet is simply written to
> offset 2 into the pbuf. This way all 32bit fields become
> aligned except for the dipaddr in the ARP header. This field
> can be substituted with two u16_t, and everything is solved.

It's interesting you should say that: I was wondering exactly the same thing as 
I was composing my earlier message this morning. I hadn't yet had time to 
investigate which headers became better aligned doing this and which became 
worse. I had wondered whether the alignment of the TCP header depended on the 
IP options too, but I've just verified that the IP header is always a multiple 
of 32 bits.

> This solution should actually increase performance slightly, even on 
> 32bit systems that do support unaligned memory accesses. The only bad 
> thing is that two bytes per packet are wasted.

I think it is actually a much more elegant and portable solution than all the 
hackery I've done, and I'm going to try it out later today. After all, I only 
discovered alignment problems when I changed from SLIP to Ethernet. It should 
be possible to encapsulate this pre-packet padding technique purely in the 
Ethernet driver.

> When the alignment problem is solved, we can get rid of all 
> thoose ugly PACK_STRUCT makros, because they are only needed
> for unaligned structs.
> 
> Timmy Brolin

Cheers,
Tony


***********************************************************************************
This email, its content and any attachments is PRIVATE AND
CONFIDENTIAL to TANDBERG Television. If received in error please
notify the sender and destroy the original message and attachments.

www.tandbergtv.com
***********************************************************************************