On 1/8/20 9:18 AM, Aaron Conole wrote: > David Ahern <dsah...@gmail.com> writes: > >> On 12/16/19 2:42 PM, Aaron Conole wrote: >>> Can you try the following and see if your scalability issue is >>> addressed? I think it could be better integrated, but this is a >>> different quick 'n dirty. >> >> your patch reduces the number of threads awakened, but it is still >> really high - 43 out of 71 handler threads in one test. > > Thanks for getting back to me (sorry for the late response, catching > up). I'll take a closer look. I haven't thought about adding > EPOLLEXCLUSIVE to the poll block change, so maybe that will address it > completely, or maybe there's a different approach. >
This seems to have gone quiet for a few months now. In case my previous comments weren't clear, the change in question (69c51582ff786a68fc325c1c50624715482bc460) converted a control plane scaling problem into a datapath scaling problem. It manifests as an increase in squeezed counts and dropped packets (both at the enqueue point and at hand off to the vhost threads) because of the increased time spent on upcalls. I have reverted that commit and several on top of it for our purposes, but this really is something OVS devs should fix. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
