Currently, for each link-delete, the walker does one graph-walk. In the case,
where the server-table code got enough time to process a bunch of, say n,
link-deletes before the walker got a chance to run, the walker will still
perform 'n' graph-walks. The last (n - 1) graph-walks are unnecessary since the
first walk would already work with a graph with all the 'n' links removed.
We fix that by absorbing the last (n - 1) triggers into the first trigger i.e.
run the graph-walk only once instead of 'n' times. Replace the work-queue with
a bitmap of client-ids.
Reviewed: https:/ /review. opencontrail. org/8939 github. org/Juniper/ contrail- controller/ commit/ 8518e3e4b8f8abf da3c06daafd3078 788d828b6c
Committed: http://
Submitter: Zuul
Branch: master
commit 8518e3e4b8f8abf da3c06daafd3078 788d828b6c
Author: Tapan Karwa <email address hidden>
Date: Mon Apr 6 16:11:47 2015 -0700
Graphwalker optimization
Currently, for each link-delete, the walker does one graph-walk. In the case,
where the server-table code got enough time to process a bunch of, say n,
link-deletes before the walker got a chance to run, the walker will still
perform 'n' graph-walks. The last (n - 1) graph-walks are unnecessary since the
first walk would already work with a graph with all the 'n' links removed.
We fix that by absorbing the last (n - 1) triggers into the first trigger i.e.
run the graph-walk only once instead of 'n' times. Replace the work-queue with
a bitmap of client-ids.
Partial-Bug: 1432735
Change-Id: Iab79a58285aa8a 8ebce54e453a1c2 215dbe60099