OSPF performance/SPF calculations

[Joakim Tjernlund]

Joakim Tjernlund/Transmode wrote on 2010/04/21 22:04:06:
>
> Ondrej Zajicek <santiago at crfreenet.org> wrote on 2010/04/21 20:15:07:
> > On Wed, Apr 21, 2010 at 09:41:47AM +0200, Joakim Tjernlund wrote:
> > > I am using Quagga ATM but I had a quick look at BIRD and I got a few
> > > observations.
> >
> > Hello. Thank you for your tips and notes.
> >
> > > The LSA/checksum code seem very inefficient.
> > > LSAs are built allocating/reallocing bits
> > > of memory. This is slow and will case memory fragmentation.
> >
> > You mean lsab_alloc() in originate_rt_lsa_body()?
> > This allocation is just a sequential allocation in a persistent memory buffer,
> > therefore it is very efficient (in most cases just increase of lsab_used counter)
> > and there si no memory fragmentation (all is done inside a persistent memory buffer).
>
> Yes, you do realloc on small amounts of memory. Also, receives LSAs
> seems to be impl. differently so you need handle these somewhat
> differently.
> >
> > > The fletcher checksum is very slow as it has extra tests in the hot path and also
> > > flips endian in the LSA back and forth.
> >
> > Do you have some suggestions for a better algorithm, or just a better
> > implementation? Yes, the problem with flipping endianity is known.
> > I do not studied this part of the code yet (the checksum algorithm).
>
> Yes, but not at the moment. The endian problem should be addressed when you
> build the lsa.

Does this help at all? In any case, the (int) cast should be there.