On Wed, Oct 19, 2011 at 6:33 PM, Jesse Gross <je...@nicira.com> wrote: > 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.
Oh and I agree that #1 makes the most sense to work around this bug. We could do one of the other possibilities if there was another compelling reason but I don't think this is a good enough reason to switch by itself. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
