Hi Pavlin,<br><br>Thanks for your inputs. It makes few things easier and few places makes issues..But anyhow I thought another point that, by having pending deletion, we can prevent from cache miss due to PRUNE-PENDING state of upstream neighbour.
<br><br>Thanks,<br>Regards,<br>Suresh kannan.<br><br><div><span class="gmail_quote">On 10/29/06, <b class="gmail_sendername">Pavlin Radoslavov</b> <<a href="mailto:pavlin@icir.org">pavlin@icir.org</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> What is advantage of marking a pim mre for pending deletion rather than<br>> immediate delete?. Please let me know is there reason any behind it apart
<br>> from saying design..<br>><br>> ---code snip..---------------<br>> void<br>> PimMrt::add_task_delete_pim_mre(PimMre *pim_mre)<br>> {<br>> PimMreTask *pim_mre_task = NULL;<br>> PimMreTrackState::input_state_t input_state =
<br>> PimMreTrackState::INPUT_STATE_MAX;<br>><br>> if (pim_mre->is_task_delete_pending()) {<br>> // The entry is already pending deletion.<br>> // Shoudn't happen, but just in case...<br>> return;
<br>> }<br>> ...<br>> ...<br>> }<br>> ---code snip..---------------<br><br>The reason for this is design-related.<br><br>PIM-SM uses the so-called dependency tracking mechanism.<br>E.g., an event such as a MRIB update could trigger a number of
<br>operations (tasks) that need to be performed on a number of<br>multicast routing entries. Some of those operations might trigger<br>other events which translate in more operations (tasks), and so on.<br>Before you ask, no the dependency tracking does not result in loops :)
<br><br>The operations are scheduled as a list of tasks, where each task is<br>atomic and may contain a number of operations that need to be<br>performed on a routing entry.<br>To simplify the code and for optimization purpose, we lookup the
<br>appropriate multicast routing entry at the beginning of a task, and<br>perform all operations until the end of the task. Hence, if one of<br>the intermediate operations attempts to delete an entry, we mark the<br>entry as a candidate for deletion, and continue the processing, so
<br>the rest of the operations and tasks can proceed.<br>To be more accurate, we actually schedule a new task "delete the<br>entry" which goes to the end of the list with tasks.<br>This "delete the entry" task, when scheduled, will delete the
<br>routing entry or will be a no-op if an earlier task marked the entry<br>as being in-use.<br><br>Hope that helps,<br>Pavlin<br></blockquote></div><br>