OSPF performance/SPF calculations

[Ondrej Filip]

On 23.4.2010 19:24, Joakim Tjernlund wrote:
> 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.

True, I checked it now. So maybe that was just an original idea. And
this is still in some functions like lsa_flood etc. Anyway.

>> 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?

I am open to anything that helps.

			Ondrej

>