[ndnSIM] Content Store Caching/Replacement Policies

shijunxiao at email.arizona.edu shijunxiao at email.arizona.edu
Thu Dec 8 03:37:16 PST 2016


Hi John

Alex already answered. There’s one mistake, though.

Policy::doBeforeErase will not be invoked when policy decides to evict an entry. It’s only intended to be invoked from Cs::erase (it’s not implemented because there’s no valid use case).

When Policy decides to evict an entry, it inform CS via beforeEvict signal to erase the entry from CS’s lookup index (the Table), and then deletes the entry’s iterator from Policy’s cleanup queue first. Since the eviction is decided by Policy, Policy already knows which iterator should be deleted from its cleanup queue, so there’s no need to CS to tell Policy which iterator should be deleted.
On the other hand, in the case of Cs::erase (when it’s implemented), the deletion decision comes from “higher up” (an application or management utility), so the Policy needs to be told which iterator should be deleted from its cleanup queue.
 
Yours, Junxiao

From: Alex Afanasyev
Sent: Wednesday, December 7, 2016 22:42
To: John Baugh
Cc: ndnsim
Subject: Re: [ndnSIM] Content Store Caching/Replacement Policies

1.)  In cs-policy-lru.cpp, the doBeforeErase function is as follows:

void
 LruPolicy::doBeforeErase(iterator i)
 {
   m_queue.get<1>().erase(i);
 }

Note that it is removing an item from the queue, apparently.  However, I was told this is just another copy of the table of iterators that the Cs itself stores?

If this is so, how is this actually having any effect of the contents in the Cs itself?

doBeforeErase doesn't affect the CS itself. It is being called just before removal of an entry from CS, which has been decided in some other way.


2.)  I noticed that there is an emitSignal when entries as evicted, and it has beforeEvict as the first argument (in both LRU and Priority Fifo) - what exactly is this signal emission doing?  Does this tell the Cs itself to remove entries?

Exactly. For LRU policy, this decision process happen on doAfterInsert: if the size of CS becomes larger than the limit, the policy selects an entry (using the policy-managed queue) and emit signal to indicate CS to remove the specified entry.   After that CS will do the job of preparing to remove, call doBeforeErase on the policy, and then actually remove the entry.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20161208/026247c8/attachment-0001.html>


More information about the ndnSIM mailing list