OSPF performance/SPF calculations

[Joakim Tjernlund]

Ondrej Zajicek <santiago at crfreenet.org> wrote on 2010/04/23 10:32:06:
>
> On Wed, Apr 21, 2010 at 10:04:06PM +0200, Joakim Tjernlund wrote:
> > 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.
>
> realloc() is used only for a persistent buffer to grow it sufficiently
> large. So it is called only small number of times during the run of
> the program and not in subsequent LSA originations. Therefore it is
> not an issue.

It would be better if you used the same (linear space) as you do
for received LSA's. I guess the received LSA's has a MAX size?
Then you could allocate space as big as the MAX received LSAs size,
add data to it and, if you want to, realloc the the whole
LSA to a smaller size.

  Jocke