Dear all, I am trying to test the performance of OVS for short-lived TCP connections over a GRE tunnel. The test shows wired results that OVS 2.0.1 consumes twice the CPU usage as that of OVS 1.9.3.
Here is the experiment: 1. Two mininets are connected to each other over a GRE tunnel. (The configuration is the same as this post: http://gregorygee.wordpress.com/2014/01/25/using-linux-gre-tunnels-to-connect-two-mininet-networks/. except that I use local controller) I use mininet 2.1 with Virtualbox. The kernel version used in mininet 2.1 is GNU/Linux 3.8.0-19) The topology is like this. h1 and h3 is connected and able to ping each other. h1<----->s1<------gre----->s2<----->h3 ------------- ------------- mininet1 mininet2 2. Then I use iperf to test the usage of CPU in each mininet. Setting h1(# iperf -s) and h3 (# iperf -c h1 -M 1412) works fine. CPU consumes around 1% in the test in each host (mininet). Then I try to simulate TCP connections from different source address by: 1. Creating a lot of virtual interface in h3 with different ip address by script like: for i in $(seq 1 254) do ifconfig h3-eth0:$i 10.1.0.$i netmask 255.0.0.0 up done 2. In the same way I initiate TCP short-lived connection from h3 to h1 by: iperf -c $h1 -B 10.1.0.$i -M 1412 -n 1k & During the process, I monitor the CPU usage of ovs-vswitchd by "top" command. In h1 ( the iperf server side), OVS 2.0.1 takes around 11-13%, while OVS 1.9.3 takes around 4-6%. In h3 ( the iperf client side) the test also shows the similar resutls. I use "time" command to run the script of iperf. 1.9.3 takes slightly less real time than 2.0.1, although 2.0.1 use less user and sys time. I also run the scripts in the same host between two VMs (no GRE), which shows the similar result. What could be the reason for these results? Is OVS 2.0.1 doing a more complicated job or could it be a bug? I would like to spend more time in testing that since we are trying to upgrade our system to 2.0.1. Could anyone give some suggestions on doing the test? Thanks in advacne. Aaron Shan
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
