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

[Jesse Gross]

On Wed, Oct 19, 2011 at 6:55 PM, Ansis Atteka <aatteka at nicira.com> wrote:
>
> 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.
>
> I actually did quick investigation for this. With Python (blocking sockets)
> I was able to push 6 Gbps of TCP traffic within localhost boundaries while
> with Iperf I was able to push 27Gbps (Xeon X3430)
>
> Not sure how much numbers would change if I would do this from event-loop
> and send traffic to a different host. Hard part would be UDP flow control
> that would require timer based approach.

OK, that's interesting.

>>
>> That said, I'm not all that eager to reimplement all of iperf, since
>> we'd also have to create a control channel, etc.
>
> I think that we can potentially embed all the Control Channel information in
> the first few bytes of the data channel (e.g. specify direction; and in case
> of UDP specify Target Bandwidth and datagram sizes).

You also have to report the received packet rate back to other side.
All of this is doable, of course, it's just something that I hope we
don't have to spend time on.

>> 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.
>
> Currently It does UDP bidirectional tests (Iperf is started with -d flag)

Great, thanks.

By the way, I think all of the UDP tests will either succeed or fail
so you probably don't need to ask for a particular bandwidth but can
just pick a low rate.