Task #3565
closed
Investigate management thread
0%
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.
Updated by Junxiao Shi over 8 years ago
20160329 conference call decides not to assign this task.
Updated by Junxiao Shi over 8 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:
- mgmt thread parses, verifies, and authorizes the Interest
- mgmt thread sends the command name and parameters as a message to main thread
- main thread performs the table update / face creation / etc
- main thread sends the result code and other information (such as FaceId) as a message to mgmt thread
- 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
Updated by Davide Pesavento over 8 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?
Updated by Junxiao Shi over 8 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.
Updated by Junxiao Shi over 6 years 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 proposal quoted in note-5, so this issue is closed.
I’ll create another issue for the implementation.
Updated by Junxiao Shi over 6 years ago
- Blocks Feature #4528: Management thread added