OSPF performance/SPF calculations

[Joakim Tjernlund]

Ondrej Zajicek <santiago at 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