On Wed, Oct 19, 2011 at 5:28 PM, Ethan Jackson <et...@nicira.com> wrote: >> Implement ovs-vlan-test server logic so that it would restart iperf TCP >> server every-time iperf-server exited because of this bug, >> For TCP (or maybe also for UDP) use a different tool (e.g. nttcp, netperf >> ...). I suppose output from other tools would be a little bit tougher to >> parse than for iperf, >> Limit ovs-vlan-test server lifetime to a single testing session, so that >> user manually has to restart ovs-vlan-test server if he wants to do multiple >> tests in a row, >> Implement all iperf logic inside the ovs-vlan-test python script (would >> python be good enough candidate for this performance wise?); >> >> Will try to come up with something soon. Anyway as a best long term solution >> I see #4, because then we would not have dependency on netper/iperf >> STDOUT/STDERR format. Although that would be a little bit more time >> consuming... > > Someone else may disagree, but I think #1 is the best choice. We are > definitely going to want to run some sort of tcp stream test. I think > iperf is going to be a lot better at implementing this sort of test > than python code (especially on 10 gig links). Since we are going to > need to run iperf anyway for the tcp stream test, we may as well do it > for everything. However, Jesse knows the most about the specific > problems we are targeting, so I would defer to him on this issue.
iperf/netperf are actually a lot simpler than you probably think (think loop around a call to write()...) so I'm not sure that the language actually makes all that much of a difference unless Python tries to something overly clever with I/O. I doubt that it does. That said, I'm not all that eager to reimplement all of iperf, since we'd also have to create a control channel, etc. By the way, does the patch actually run bidirectional tests right now? (I don't see it in a quick scan of the patch.) If not, it's definitely important for all the test types. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
