On 23.4.2010 19:24, Joakim Tjernlund wrote:
Ondrej Filip <feela@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