[ovs-dev] [PATCH 1/2] ovs-vlan-test: Add iperf to test basic connectivity.

Jesse Gross jesse at nicira.com
Thu Oct 20 01:33:22 UTC 2011


On Wed, Oct 19, 2011 at 5:28 PM, Ethan Jackson <ethan at 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.



More information about the dev mailing list