Hey Han,
> The miss_handlers are woken up frequently by the dispatcher outside of the > for (;;) loop, because the for loop breaks when dpif_recv() returns EAGAIN, > which happens far more frequently than there are 50 pending upcalls for a > handler. I am trying to figure out a quick but safe solution for this high > CPU > issue: increase batch mode probability while avoid hanging forever. > This is the case when the rate of incoming upcalls is slower than the "dispatcher" reading speed. After "dispatcher" breaks out the for loop, it is necessary to wake up "handler" threads with upcalls, since the processing latency matters. A batch mode may help, but more research needs to be done on reducing the latency. Have you done any experiment on related issues? > For the second question: > > 2. why ovs-vswitchd occupies so much CPU in short-lived flow test before > my > > change? And why it drops so dramatically? What's the contention between > > ovs-vswitchd and miss_handler? > > I didn't find the exact answer yet, but I did observe that there are many > mutex > contentions by checking strace results. Sorry that I am still new to OVS > code, so > need more time to dig out :) > > Yes, we also know that. And we will start solving this soon. > Alex, I just saw your another patch for fairness of dispatcher algorithm, > do you > have any thoughts on below proposal for more scalable multi-threading, > removing dispatcher completely? Thanks! > > > > A better solution for this bottleneck of dispatcher, in my opinion, > could be that > > each handler thread receives upcalls assigned to them from kernel > directly thus > > no conditional wait and signal involved, which avoid unnecessary context > switch > > and futex scalling problem in multicore env. The selection of handler > can be > > done by kernel with same kind of hash, but put into different queues > > per-handler, and this way packet order is preserved. Can this be a valid > > proposal? > > > Yes, I agree, this sounds like the direction we will go in the long term. But for now, we are focusing on partially addressing this in userspace. Since: - we want to address the fairness issue as well. And it is much easier to model the solution in userspace first. - the goal is to guarantee the upcall handling fairness even under DOS type attack.
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
