[Xorp-hackers] PIM MRE deletion pending

Suresh Kannan.D sureshkannan at gmail.com
Tue Oct 31 05:46:01 PST 2006


Hi Pavlin,

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.

Thanks,
Regards,
Suresh kannan.

On 10/29/06, Pavlin Radoslavov <pavlin at icir.org> wrote:
>
> > What is advantage of marking a pim mre for pending deletion rather than
> > immediate delete?. Please let me know is there reason any behind it
> apart
> > from saying design..
> >
> > ---code snip..---------------
> > void
> > PimMrt::add_task_delete_pim_mre(PimMre *pim_mre)
> > {
> >     PimMreTask *pim_mre_task = NULL;
> >     PimMreTrackState::input_state_t input_state =
> > PimMreTrackState::INPUT_STATE_MAX;
> >
> >     if (pim_mre->is_task_delete_pending()) {
> >     // The entry is already pending deletion.
> >     // Shoudn't happen, but just in case...
> >     return;
> >     }
> >    ...
> >    ...
> > }
> > ---code snip..---------------
>
> The reason for this is design-related.
>
> PIM-SM uses the so-called dependency tracking mechanism.
> E.g., an event such as a MRIB update could trigger a number of
> operations (tasks) that need to be performed on a number of
> multicast routing entries. Some of those operations might trigger
> other events which translate in more operations (tasks), and so on.
> Before you ask, no the dependency tracking does not result in loops :)
>
> The operations are scheduled as a list of tasks, where each task is
> atomic and may contain a number of operations that need to be
> performed on a routing entry.
> To simplify the code and for optimization purpose, we lookup the
> appropriate multicast routing entry at the beginning of a task, and
> perform all operations until the end of the task. Hence, if one of
> the intermediate operations attempts to delete an entry, we mark the
> entry as a candidate for deletion, and continue the processing, so
> the rest of the operations and tasks can proceed.
> To be more accurate, we actually schedule a new task "delete the
> entry" which goes to the end of the list with tasks.
> This "delete the entry" task, when scheduled, will delete the
> routing entry or will be a no-op if an earlier task marked the entry
> as being in-use.
>
> Hope that helps,
> Pavlin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20061031/d5993edf/attachment.html 


More information about the Xorp-hackers mailing list