Il giorno 10/ago/2012, alle ore 19:20, Ben Pfaff <b...@nicira.com> ha scritto:
> ... >> 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. It turns out that, in my test, the forwarding thread was never able to found a flow for the incoming packets. When this is the case, the forwarding thread puts the incoming packet in a queue and signals the main thread via a pipe. The main thread then completes the processing, which includes the actual forwarding. This explains why both threads where busy. It is interesting that a 10x forwarding improvement can be obtained even in this scenario. I do not know why my previous test was unable to trigger any flows, but it appears to be related to my use of the local port "br0". In the following setup, instead, flows are used as expected: ip tuntap add tap0 mode tap ip tuntap add tap1 mode tap ovs-vsctl add-bf br0 -- set bridge br0 datapath_type=netdev ovs-vsctl add-port br0 tap0 ovs-vsctl add-port br0 tap1 I use a program that sends packets on the fd of tap0 and another program that reads and discards packets from the fd of tap1. Now it is only the forwarding thread that uses 99% CPU, while the main thread stays idle as expected. The speedup in forwarding rate w.r.t. the unthreaded ovs-vswitchd is around 10x, again. Giuseppe Dr. Ing. Giuseppe Lettieri Dipartimento di Ingegneria della Informazione Universita' di Pisa Largo Lucio Lazzarino 2, 56122 Pisa - Italy Ph. : (+39) 050-2217.649 (direct) .599 (switch) Fax : (+39) 050-2217.600 e-mail: g.letti...@iet.unipi.it _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
