RE: [lwip-users] lwip + sam7x = udef exception

[Kieran Mansley]

On Thu, 2007-02-15 at 13:21 +0100, Goldschmidt Simon wrote:
> Are you suggesting on a 32-bit-platform, ethernet packets should always
> be received in a buffer which is 2 byte aligned, not 4 byte aligned??

Not always, no.  That's why I said "normally".  As you rightly point out
there are reasons why you might not want or be able to do this.  It is
the most efficient way however to achieve the required alignment, and so
should be done if possible. 

> Also, the ethernetif.c shipped with lwIP 1.2.0 does this alignment only
> if ETH_PAD_SIZE is defined as 2.

ethernetif.c is just a skeleton example.  ETH_PAD_SIZE defined to 2 is
the mechanism for how this is achieved.

> Since (except data alignment, but the
> "application" has to deal with that) this seems to apply only to IP
> addresses (only in IP header, not in ARP header) and TCP sequence
> numbers, I think there should be an option for this alignment!

I'm not sure what you mean by only applies to the IP addresses and TCP
sequence numbers.  Is it that as they are the only 4-byte values in the
headers, they're the only ones for which alignment matters?

Checksumming will also be more efficient if the data payload is properly
aligned, and while it may be up to the application to deal with it,
providing aligned data is definitely a good thing if we can.

> This could be done by changing IP addresses in the IP header to struct
> ip_addr2 and a get-/set-seqno macro for TCP which handles the
> (mis-)alignment of the 32-bit values in the TCP header.
> 
> I know this is a speed issue, also. But copying the received data from a
> 4 byte aligned buffer to a 2 byte aligned buffer is much more expensive.

In the case where you can't provide the 2 byte aligned buffer you're
going to suffer a performance penalty whatever you do.  I think it would
be wrong to have a performance penalty across the board to make it
easier/more efficient to port to some platforms.

That said, if anyone else has views on this, let's hear them.  If others
want to change how this is done, then please let us know, particularly
if you've got the time to make and test the changes.

Kieran