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

[Ansis Atteka]

After all I decided that best option actually would be to re-implement the
iperf logic inside the ovs-vlan-test python script itself, because of
following reasons:

   1. flag "--tradeoff" (bidirectional, individual test) does not work for
   TCP:
   http://sourceforge.net/tracker/index.php?func=detail&aid=1949942&group_id=128336&atid=711371
   2. iperf server process silently exits for TCP tests
   http://sourceforge.net/tracker/?func=detail&aid=1983829&group_id=128336&atid=711371
   3. ovs-vlan-test parser will not depend on iperf's STDOUT or STDERR
   format (the format potentially might change between different iperf
   versions)
   4. ovs-vlan-test will not have dependency on iperf or python-twisted
   packages anymore (just pure python standard library that has socket support)
   5. most likely we would prefer if socket would belong to ovs-vlan-test
   script process instead of iperf, so that in future we could use
   setsockopt/getsockopt calls to get more control over TCP

I already implemented TCP tests in pure python; UDP tests will be ready
soon. Within localhost boundaries and non-blocking sockets in Python I was
able to get close to 10 Gbps of traffic.

Thanks,
Ansis

On Wed, Oct 19, 2011 at 8:45 PM, Jesse Gross <jesse at nicira.com> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20111021/828760a7/attachment-0003.html>