Re: [lwip-users] byte alignment

[Tyrel Newton]

> As to the aligned pbuf payload: I think the code currently relies on mem_malloc 
> returning aligned data (and that should be OK with your current settings), so 
> you might want to check the return values of your libc malloc.
>    

As the pbuf code is written (I think I'm running the latest stable, 
1.3.2), there is no way to guarantee a 32-bit aligned payload pointer at 
the start of the Ethernet frame with MEM_ALIGNMENT=4. This is because in 
pbuf_alloc, the payload pointer for PBUF_RAM types is initialized at an 
offset that is itself memory aligned (this offset is equal to the size 
of pbuf structure plus the various header lengths). When the 14 byte 
Ethernet header is eventually uncovered, it will always be 16-bit 
aligned since the the original payload pointer was 32-bit aligned. This 
of course assumes a PBUF_LINK_HLEN=14.

The moral for me is that I actually see higher throughput by setting 
MEM_ALIGNMENT=2, which guarantees that when the Ethernet header is 
uncovered, it will be 32-bit aligned. Even though the TCP/IP headers are 
unaligned, the final copy to the mac's transmit buffer is much faster if 
the source pointer is 32-bit aligned, i.e. at the start of the actual 
Ethernet frame.

Btw, this is also assuming the outgoing data is copied into the stack 
such that all the outgoing pbufs are PBUF_RAM-type.

Interesting results, but pretty esoteric since this is not an oft-used 
platform (MicroBlaze w/ xps_ethernetlite IP core).

Tyrel