On Fri, Aug 10, 2012 at 06:36:46PM +0200, Giuseppe Lettieri wrote: > > I'm very interested in seeing some up-to-date performance numbers > > because introducing threads definitely raises the bar when it comes to > > the need for careful programming, and that's only worthwhile if there > > is a correspondingly high payoff.
... > With the original ovs-vswitchd I obtain ~26 Kpps, with the threaded > ovs-vswitchd I obtain ~270 Kpps. That's good enough of a payoff to justify work on a thread or process split. Thanks. ... > The datapath thread goes to 100% CPU in my tests, but this is > expected, since everything is being done in software and no real I/O > is being performed. The main thread goes to ~65%, and this is less > expected (at least, I did not expect it) and we should investigate > why. I'm surprised too. I think that your test only has one or two flows, so I'd expect the forwarding thread to be busy and the main thread to be idle. > Anyway, we should consider the following (Luigi may also say > something more precise on this, or even correct me if I am wrong): > most of the performance benefit comes from two things that are > unrelated to threading: > > 1) use the information returned by the poll syscall to read from > ready ports only; We've had good improvements in a similar issue in dpif-linux by switching to use "epoll". Can kqueue under FreeBSD do something similar? > 2) process several packets per port (if available) before reentering > the poll syscall. That makes sense too. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
