OSPF performance/SPF calculations

[Joakim Tjernlund]

Ondrej Filip <feela at network.cz> wrote on 2010/04/23 19:05:57:
>
> On 23.4.2010 14:22, Ondrej Zajicek wrote:
> > On Fri, Apr 23, 2010 at 01:06:20PM +0200, Joakim Tjernlund wrote:
> >>> I must be missing something then(not surprising as I just started looking
> >>> at BIRD). Why do you need the separate allocation for the body of the LSA then?
> >>> Why not just adding entries to the allocated LSA header?
> >>
> >> Ahh, I am starting to get a clue I think. It is the struct top_hash_entry
> >> that has this separation of LSA header and body.
> >> Would it be feasible to move struct ospf_lsa_header lsa into
> >> void *lsa_body, that is, merge them into one so
> >> there is just one struct ospf_lsa_header *lsa instead?
> >
> > Yes, LSA header and LSA body are separated and i am not sure what is a
> > purpose of that separation, but it does not cause much problems, so it
> > is probably pointless to change this. It probably makes slightly faster
> > access to the header fields.
>
> Hmm, I wrote this part about 8 years ago. But I believe I had many
> reasons for that. Size of LSA body differs, but size of LSA header is
> fixed. Also LSA body is kept in network endianity while LSA header is
> in CPU endianity.

hmm, don't think the body is in network order. Look at the
lsasum_calculate, it swaps the whole LSA, twice.
Then you must also swap the LSA once more before transmitting it.

>
> I know the function lsasum_calculate is unefficient - I noted this in
> the related comment. But I have never felt this has been a serious
> issues. I believe we have some other more important things to do.
>
> I believe Martin's idea with to check BIRD with OProfile is the key
> one. Otherwise we would work on fixing some minor issues.

Ok, but could at least make this endian stuff a NOP on BE CPUs?