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

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


On Wed, Oct 19, 2011 at 6:33 PM, Jesse Gross <jesse at nicira.com> wrote:
> 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.

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.



More information about the dev mailing list