Investigate management thread
Investigate the feasibility of separating NFD management to a separate thread.
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.
#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:
- 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
- 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
#4 Updated by Junxiao Shi over 2 years ago
Answer to note-3:
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|
|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
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.