Ondrej Zajicek <santi...@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