Ondrej Zajicek <santiago@crfreenet.org> wrote on 2010/04/23 18:46:19:
On Fri, Apr 23, 2010 at 05:29:09PM +0200, Joakim Tjernlund wrote:
But you also need LSAs in host endianity when doing SPF calculation. Although it would be probably possible to change SPF calculation to use directly BE values it would be huge work and it is questionable whether it wouldn't just move endianity swaps deeper in the code.
But how do you know when swap endian or not? It seems to me that swapping endian back and forth for some LSAs and not for others is more work.
In BIRD, we do net->host 4B endianity swap when receiving every LSA and do host->net 4B endianity swap when transmitting every LSA.
Ah, I haven't noticed that yet. I do think it is the wrong way though. You will must convert each LSA multiple times and will generate a lot memory traffic to and from main RAM. I don't think it would cost that much to keep the PDUs in BE, == and != ops don't care about endian so it is only when need to do arith. and > or < that you need host endian.
If LSA contains for example 2x u16 fields, we have such field swapped in structure declaration on little endian systems (see ospf.h for example struct ospf_lsa_rt).
When we do some LSA processing (for example in SPF), we can assume that everything is in host endianity.
Meanwhile, perhaps you could add something like this so only LE CPU suffer:
I would make some ifdefs to lsalib.c / lsalib.h to make htonlsah() (and others) an empty operation on big endians.
Yes, it would be great if on BE CPUs all the endian stuff were NOPs