Assertion failed (vector overflow) during initialization of ToDPDKDevice about fastclick HOT 4 CLOSED

Thanks for reporting the issue, this is indeed a good place to do so.

What's your launch command? And particularly the number of threads. I'll try to reproduce the error. I changed some things arround get_runnable_threads not long ago, I may have introduced a regression...

Tom

from fastclick.

When I fisrt found it I was running with -c 0x3 -n 2, but it also happens with -c 0x1 -n 1 -- -f testconf.click (the stack traces refer to this latter case, but I doubt there is any difference).

I also managed to get a configuration file to cause the crash without requiring our custom elements (it appears that in my instance doing some stretching with compund elements causes Click to schedule initalization differently):

io :: {
  input[0,1] => ToDPDKDevice(0), ToDPDKDevice(1);
  from0 :: FromDPDKDevice(0, MINQUEUES 2, MAXTHREADS 64, RSS_AGGREGATE yes);
  from1 :: FromDPDKDevice(1, MINQUEUES 2, MAXTHREADS 64, RSS_AGGREGATE yes);
  from0, from1 => [0,1]output;
}();
io[0,1] => [0,1]io;

from fastclick.

Ok I reproduced it, I'm looking into it ;)

from fastclick.

Your approach is the good one. It's what's done with FromDevice / ToDevice and what I also did with FromNetmapDevice/ToNetmapDevice. Forgot that with DPDK...

The problem is that in FromDPDKDevice, the get_runnable_thread() function depends on this element being initialized. But to initialize ToDPDKDevice, in our model we need to know which elements will "launch" threads so we can find which threads will end up in the ToDPDKDevice and allocate the minimal number of queues. So ToDPDKDeive call get_runnable_threads() on upstream elements in its own initialization routine. It's still a little unclean. I was thinking of adding a thread-initialization phase or something like that.

But last commit a62349e solve your problem, and no it should not introduce any bug. Thanks for reporting !

from fastclick.