[Nfd-dev] [EXT] Multi-Worker NFD (MW-NFD) 0.7.1 Release

[Sung Hyuk Byun]

Hi Junxiao,

 

Thank you for your quick and good comments.

 

We have to admit that we have not fully check the unit-test cases yet..

Our tests was mainly compatibility test with applications and forwarding. 

When we look over the unit-test error cases, there are some conflicts on face implementations between what test codes assume and what MW-NFD modifies to separate input thread with forwarding thread. 

We’ll check each error cases, and will fix if it is a real error, or update the unit-test codes to accommodate new MW-NFD arch.

 

For ndfc commands processing changing forwarding worker’s tables, we use udp socket between management thread and forwarding woker threads. 

The message queue was one of our considerations, but we chose udp socket, because it is more simple than message queue method.   If message queue is used, management thread should wait the responses from all worker threads asynchronously, through another message queues or global variables. 

There should be some unique command ID and ID-related response structure to check whether all workers return OK, and 

it requires  another polling operation to check the responses. 

If we use udp socket, management thread can just wait the response from each worker synchronously. 

Of course, asynchronous operation of message queue methods can enhance commands processing time a little,  with more complex operation. So we decided to use udp because it is sufficient to handle nfdc commands. 

 

For command parameter passing, we use shared pointer of <ndn::nfd::ControlParameters>, because it makes fixed udp message size for all commands, and it works. 

If shared pointer passing between threads are a little risky coding style, we can use pointer of global variable, or we can just send parameter itself in the udp message.  

Would you let us know more detail about your concerns on shared pointer passing between threads? 

 

We appreciate more comments from NFD developers like you, because we might miss some points should be checked first for proper operation as a NFD-compatible forwarder.

 

Thanks again, 

 

Sung Hyuk Byun

 

 

From: Junxiao Shi <shijunxiao at email.arizona.edu> 
Sent: Saturday, February 20, 2021 8:19 AM
To: Sung Hyuk Byun <shbyun at etri.re.kr>
Cc: <nfd-dev at lists.cs.ucla.edu> <nfd-dev at lists.cs.ucla.edu>
Subject: Re: [EXT][Nfd-dev] Multi-Worker NFD (MW-NFD) 0.7.1 Release

 

Hi Sung

 

I had a quick look at your codebase, and I found a few strange things.

I'll only mention one below.

 

In mw-nfd/daemon/mw-nfd/mw-nfd-global.cpp file emitMwNfdcCommand function contains the following code:

https://github.com/etri/mw-nfd/blob/44fd00a55b1a80595c5e677f74762334a25d9a39/daemon/mw-nfd/mw-nfd-global.cpp#L127

char buf[MW_NFD_CMD_BUF_SIZE]={0,};
mw_nfdc_ptr nfdc = (mw_nfdc_ptr)buf;
struct sockaddr_in worker, their;
auto params = make_shared<ndn::nfd::ControlParameters>(parameters);

for (i = 0; i < g_forwardingWorkers; i++) {
  // omitted code to assign 'worker' address

  nfdc->mgr = mgr;
  nfdc->verb = verb;
  nfdc->ret = MW_NFDC_CMD_OK;
  nfdc->netName = netName;
  nfdc->parameters = params;

  sendto(g_nfdcSocket, buf, sizeof(buf), 0, (struct sockaddr*)&worker, addr_len);
  setCommandRx(i, true);

  numbytes = recvfrom(g_nfdcSocket, buf, sizeof(buf), 0, (struct sockaddr*)&their, &addr_len);
  if (numbytes) {
    retval += nfdc->retval;
    ret = nfdc->ret;
  }
  setCommandRx(i, false);
}

 

The relevant data structure is:

typedef struct mw_nfdc_cmd {
  int32_t mgr;
  int32_t verb;
  int32_t ret;
  size_t retval;
  bool netName;
  std::shared_ptr<ndn::Interest> interest;
  std::shared_ptr<ndn::nfd::ControlParameters> parameters;
} mw_nfdc, *mw_nfdc_ptr;

 

Effectively, you are sending the memory representation of std::shared_ptr<ndn::nfd::ControlParameters> instance over a UDP socket. I think this can cause undefined behavior.

I wonder why you chose to send the management command as a UDP packet to the worker thread, instead of sending an encoded command via a pair of message queues?

 

Also, many unit tests are failing. Please check them.

You should use AddressSanitizer to ensure there's no memory leak and undefined behavior.

 

Yours, Junxiao

 

On Fri, Feb 19, 2021 at 7:03 AM Sung Hyuk Byun via Nfd-dev <nfd-dev at lists.cs.ucla.edu <mailto:nfd-dev at lists.cs.ucla.edu> > wrote:

Deal all

 

We are pleased to announce the Multi-Worker NFD (MW-NFD) 0.7.1 which is an high-speed NDN forwarder fully compatible with NFD 0.7.1, and it can be downloaded from https://github.com/etri/mw-nfd. 

 

MW-NFD has parallel forwarding worker who keeps NFD's forwarding architecture, and can have multiple input threads dedicated to each physical port.

We had demonstrated MW-NFD's forwarding performance in ACM ICN 2020 with the paper "MW-NFD (Multi-Worker NFD): An NFD-compatible High-speed NDN Forwarder" ( https://dl.acm.org/doi/10.1145/3405656.3420233 ) 

 

MW-NFD support all management features with nfdc command, and all face types of NFD, except NDN-LP Reliability option in point-to-point faces, which will be supported in future release. 

 

It also has additional forwarding enhancement features : dual_cs and pit-token-hash.

More information can be found at https://github.com/etri/mw-nfd/blob/main/MW-NFD-CONFIG.md .

 

If you have any questions, comments, or bug reports, please let us know through email or this mailing list. 

 

Regards, 

Sung Hyuk Byun 

shbyun at etri.re.kr <mailto:shbyun at etri.re.kr>  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20210222/7c6576a9/attachment.html>