https://redmine.named-data.net/https://redmine.named-data.net/favicon.ico?14759811232018-03-02T14:45:23ZNDN project issue tracking systemNFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=225732018-03-02T14:45:23ZJunxiao Shi
<ul><li><strong>Blocks</strong> <i><a class="issue tracker-2 status-1 priority-2 priority-default" href="/issues/4529">Feature #4529</a>: Merge NFD-RIB into management thread</i> added</li></ul> NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=225752018-03-02T14:47:35ZJunxiao Shi
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-2 priority-2 priority-default" href="/issues/4530">Feature #4530</a>: More efficient communication between threads</i> added</li></ul> NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=225792018-03-02T14:53:07ZJunxiao Shi
<ul><li><strong>Blocked by</strong> <i><a class="issue tracker-3 status-5 priority-2 priority-default closed" href="/issues/3565">Task #3565</a>: Investigate management thread</i> added</li></ul> NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=226932018-03-17T18:26:34ZDavide Pesavento
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul><p>Junxiao Shi wrote:</p>
<blockquote>
<p>Connect management thread to forwarding through a Unix stream face.</p>
</blockquote>
<p>I will not do this. It's faster to simply implement <a class="issue tracker-2 status-2 priority-2 priority-default" title="Feature: More efficient communication between threads (In Progress)" href="https://redmine.named-data.net/issues/4530">#4530</a> directly.</p>
NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=226962018-03-18T02:58:19ZJunxiao Shi
<ul></ul><blockquote>
<blockquote>
<p>Connect management thread to forwarding through a Unix stream face.</p>
</blockquote>
<p>I will not do this. It's faster to simply implement <a class="issue tracker-2 status-2 priority-2 priority-default" title="Feature: More efficient communication between threads (In Progress)" href="https://redmine.named-data.net/issues/4530">#4530</a> directly.</p>
</blockquote>
<p>That’s fine. I wrote “Unix stream face” to reduce blocking relations at the cost of increasing total work amount.</p>
NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=227002018-03-18T16:27:18ZDavide Pesavento
<ul></ul><p>With this change (and even more with <a class="issue tracker-2 status-1 priority-2 priority-default" title="Feature: Merge NFD-RIB into management thread (New)" href="https://redmine.named-data.net/issues/4529">#4529</a>) the current source-level split into the three <code>core</code>, <code>daemon</code>, and <code>rib</code> subdirs doesn't make sense anymore.</p>
<p><code>daemon/mgmt</code> and <code>rib</code> should be together, and they should be separate from the rest of the modules that run on the main (forwarding) thread. Feel free to bikeshed how exactly this should look like.</p>
<p>Management unit tests should also be split from <code>unit-tests-daemon</code>. In fact, I propose to go one step further and split <code>unit-tests-daemon</code> into <code>unit-tests-face</code>, <code>unit-tests-fw</code>, <code>unit-tests-table</code>, and <code>unit-tests-mgmt</code>. After <a class="issue tracker-2 status-1 priority-2 priority-default" title="Feature: Merge NFD-RIB into management thread (New)" href="https://redmine.named-data.net/issues/4529">#4529</a>, <code>unit-tests-rib</code> can either be merged into <code>unit-tests-mgmt</code> or be kept separate.</p>
NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=248622019-02-20T11:48:04ZJunxiao Shi
<ul></ul><p>Regarding codebase structure, I would say:</p>
<ul>
<li><code>dp/face</code>: data plane, face system</li>
<li><code>dp/table</code>: data plane, tables</li>
<li><code>dp/fw</code>: data plane, forwarding</li>
<li><code>cp/mgmt</code>: control plane, management protocol</li>
<li><code>cp/rib</code>: control plane, RIB service</li>
</ul>
NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=248632019-02-20T12:02:04ZDavide Pesavento
<ul></ul><p>There is an implicit desire to minimize the total number of changes, especially unnecessary ones. The current <code>daemon/{face,fw,table}</code> subdir structure is perfectly fine, there is no reason to change it, so I will not touch it. I'm only going to change <code>rib/</code>, <code>daemon/mgmt</code> (if necessary), and probably some files in <code>core/</code>. So your proposal does not work for me.</p>
<p>Also, what should happen to <code>RibManager</code>? It's currently in <code>rib/</code> but it's technically part of the management protocol.</p>
NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=248652019-02-20T13:20:58ZJunxiao Shi
<ul></ul><blockquote>
<p>There is an implicit desire to minimize the total number of changes, especially unnecessary ones.</p>
</blockquote>
<p>Minimizing diff size is explicitly a non-goal. See <a href="https://gerrit.named-data.net/#/c/NFD/+/332/1/daemon/fw/strategy.cpp@39">https://gerrit.named-data.net/#/c/NFD/+/332/1/daemon/fw/strategy.cpp@39</a></p>
<blockquote>
<p>The current <code>daemon/{face,fw,table}</code> subdir structure is perfectly fine, there is no reason to change it, so I will not touch it.</p>
</blockquote>
<p>Either way is fine. <code>daemon</code> means "data plane". Just put that in <code>daemon/README</code>.<br>
Similarly, you may rename <code>cp</code> to something better, but I'd suggest avoiding <code>rib</code> or <code>mgmt</code>, because control plane does not equal RIB or management.</p>
<blockquote>
<p>Also, what should happen to <code>RibManager</code>? It's currently in <code>rib/</code> but it's technically part of the management protocol.</p>
</blockquote>
<p>It eventually should be <code>cp/mgmt/rib-manager.hpp</code>.<br>
This would require some object ownership changes in <a class="issue tracker-3 status-4 priority-1 priority-lowest" title="Task: RIB: deduplicate RibManager::FaceIdSet and Rib::FaceLookupTable (Feedback)" href="https://redmine.named-data.net/issues/4731">#4731</a>.</p>
NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=248712019-02-21T20:40:41ZJunxiao Shi
<ul></ul><blockquote>
<p>I don't understand what the problem is. You said "daemon/" is fine. Be more specific in your comments.</p>
</blockquote>
<p><code>daemon</code> is fine as an alternative to <code>dp</code>.<br>
mgmt and rib belong to control plane and they need a separate folder other than <code>daemon</code>.</p>
NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=248722019-02-21T20:48:49ZDavide Pesavento
<ul></ul><p>Not gonna do that. "daemon" means daemon, not dataplane. All code of <code>nfd</code> binary goes in <code>daemon/</code> subdir. As I already said, I will not change that.</p>
NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=248742019-02-22T03:36:10ZJunxiao Shi
<ul></ul><p>Due to this dispute, this issue needs to be discussed in next NFD call.</p>
NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=248912019-02-23T13:00:23ZAlex Afanasyev
<ul></ul><p>I completely agree with Davide. Whatever control not control plane is the business of the daemon and not source code organization. The structure is already non-trivial to understand, I see absolutely no reason to make more changes than minimally necessary.</p>
NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=250362019-03-17T17:50:12ZJunxiao Shi
<ul></ul><p>In <a href="https://gerrit.named-data.net/5328">https://gerrit.named-data.net/5328</a> several components in the RIB thread start to use <code>getScheduler()</code> global function instead of the <code>m_scheduler</code> member variable. I remember that 6th-ndn-hackathon report indicates that globals should be avoid in favor of passing <code>io_service</code> and schedulers around. What has changed since then, that leads to a different design?</p>
NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=250402019-03-17T22:44:19ZDavide Pesavento
<ul></ul><p>I may have found a way to do it without passing <code>io_service</code> and <code>Scheduler</code> around. Of course getting rid of all "globals" is still possible, but I'd rather not do it unless strictly necessary, I tried with <code>Scheduler</code> and you need to change really <em>a lot</em> of code just to pass the reference around to the classes that need it.</p>
NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=250952019-03-25T10:36:36ZDavide Pesavento
<ul></ul><p>And more importantly, self-learning required adding the <code>getMainIoService</code> and <code>getRibIoService</code> helpers, which are another way to do this. We did investigate this approach during that hackathon, but ultimately abandoned it because we thought it was not particularly elegant and expected it to be rejected by reviewers.</p>
NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=257342019-08-27T20:43:08ZDavide Pesavento
<ul><li><strong>Target version</strong> deleted (<del><i>v0.7</i></del>)</li></ul> NFD - Feature #4528: Management threadhttps://redmine.named-data.net/issues/4528?journal_id=269822020-09-12T14:25:05ZJunxiao Shi
<ul></ul><blockquote>
<p>how much performance improvement would you expect from separating mgmt out -- 20%? 50%?</p>
</blockquote>
<p>Benefits depend on frequency of management commands.<br>
It will most likely be less than 20%.</p>