[Olsr-dev] frequency of olsr_calculate_routing_table

[Saulo Jorge Queiroz]

Hi all,
Aside of the work for SPF incremental procedures, it seems for me that we
can avoid to trigger some useless calls of the routing table calculation
(olsr_calculate_routing_table). I know that a backoff mechanism has been
used to prevent too many calls but i think that we can improve this with a
"more natural" approach. In particular for changes regarding deletion or
weight increasing of  non-neighbor edge entries we do not need to trigger
routing table recalculation if they aren't in SPTree. Based on your
Henning's suggestion i used a pointer to node's parent in the struct
tc_entry.
I attached a patch that explain this idea better. Alternatively one can
check by:
git clone (spam-protected):saulojorge/sptree-aware-spf-update.git

In case of edge insertion/weight decrasing (say tc_edge) shortest paths can
also be improved for all nodes in the subtree rooted by
tc_edge->edge_inv->tc. So in the above-mentioned patch I have triggered the
recalculation of the whole routing table to see if we can improve this spf
subtree. However in this context I think we should check if the improvement
can be really achieved (this check is very fast) and so recalculate SPF only
for nodes in that subtree rather than the whole topology. The work I've done
in this sense having Hannes as mentor can be tracked by:

git clone (spam-protected):saulojorge/incremental-spf.git

regards.

-- 
Saulo Jorge bq
-
"In theory, there is no difference between practice and theory, in practice
there is"
-- Someone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100812/5c4f33f9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sptree-aware-spf-update.patch
Type: text/x-patch
Size: 13972 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100812/5c4f33f9/attachment.bin>