Project

General

Profile

Task #3565

Investigate management thread

Added by Junxiao Shi over 2 years ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Management
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
15.00 h

Description

Investigate the feasibility of separating NFD management to a separate thread.

Background:
NFD management is known to be a performance bottleneck, because it involves signing, etc.
On a device with low frequency CPU, packet processing could stop for seconds when management is generating a StatusDataset.
On the other hand, many devices are now equipped with multiple CPU cores, so moving NFD management into a separate thread would with this case.

The design should investigate how ControlCommand can be effected onto the tables in the forwarding thread, how StatusDataset can have a consistent view of the data structures, and how does the two threads communicate.


Related issues

Blocks NFD - Feature #4528: Management threadIn Progress

History

#1 Updated by Junxiao Shi over 2 years ago

20160329 conference call decides not to assign this task.

#2 Updated by Junxiao Shi over 2 years ago

I thought about this a little.

Assuming we have an asynchronous messaging mechanism between threads that supports arbitrary message types, effecting a ControlCommand is simple:

  1. mgmt thread parses, verifies, and authorizes the Interest
  2. mgmt thread sends the command name and parameters as a message to main thread
  3. main thread performs the table update / face creation / etc
  4. main thread sends the result code and other information (such as FaceId) as a message to mgmt thread
  5. mgmt thread replies a Data with the outcome to the Interest

For StatusDataset,

  • if main thread sends a message to mgmt thread (upon mgmt's request) with entire dataset contents: main thread has to lock the table to collect the dataset contents; comparing to generating the dataset Data packets in main thread, this only saves signing cost
  • if main thread does not lock the table, but sends entries to mgmt thread using multiple messages, the table may have changed during this process, causing consistency concerns

#3 Updated by Davide Pesavento over 2 years ago

Junxiao Shi wrote:

main thread has to lock the table to collect the dataset contents;

why? isn't the main thread the only thread that touches the tables?

#4 Updated by Junxiao Shi over 2 years ago

Answer to note-3:

A mutex is not needed.

When the main thread needs to generate a dataset of table entries, it must enumerable the entire table in one pass.
During the enumeration, no other packets can be processed, thus the dataset generation procedure "locks" the table for the duration of this enumeration.

The duration of dataset generation isn't too bad:

state NameTree entries FIB entries FIB dataset generation StrategyChoice dataset generation
initial 10 2 2548us 2536us
inserted 1000 FIB entries 1011 1002 13185us 2843us
inserted 10000 FIB entries 10010 10002 130353us 6998us

FIB entries were inserted with for I in $(seq 10000); do nfdc register /$I 255; done.

This is tested on Ubuntu 14.04 64-bit with DEBUG build; RELEASE will be faster.

Also, this is timed at FibManager::listEntries and StrategyChoiceManager::listChoices functions which includes more work than enumerating the table, such as signing Data packets.

"6998us" is the most useful number here: it enumerates the whole NameTree but signs only one Data, and the 7ms duration isn't too bad.

#6 Updated by Junxiao Shi 10 months ago

  • Status changed from New to Closed
  • Assignee set to Junxiao Shi
  • Target version set to v0.7

The investigation is completed in the form of my hackathon protocol quoted in note-5, so this issue is closed.
I’ll create another issue for the implementation.

#7 Updated by Junxiao Shi 10 months ago

Also available in: Atom PDF