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

Ethan Jackson ethan at nicira.com
Thu Oct 20 00:28:37 UTC 2011


> Here is a bug in iperf that stops me to solve TCP tests in a neat way:
> http://sourceforge.net/tracker/?func=detail&aid=1983829&group_id=128336&atid=711371.
> The problem is that iperf server silently exits after it has done
> bidirectional TCP mode testing with the client (when --tradeoff or
> --dualtest flag were present). Although this bug does not effect UDP or
> unidirectional TCP-send tests.

That's pretty annoying.

> 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.

Ethan


> On Wed, Oct 19, 2011 at 1:04 PM, Jesse Gross <jesse at nicira.com> wrote:
>>
>> Yes, running a TCP stream would generate MTU sized packets and should
>> detect pretty much all problems.  The main reason for running UDP
>> tests with smaller packet size (include MTU sized ones) is to try to
>> narrow down the type of problem (i.e. to distinguish between an MTU
>> issue and a TSO issue).  I don't think that we've seen any cases where
>> the addition of a vlan tag causes packet reordering, so I'm not sure
>> that it's critical.
>>
>> I think that comparing the performance between tagged and untagged
>> traffic is the easiest thing to do.  There are roughly three potential
>> outcomes that I would expect:
>>  * Performance roughly on par for tagged and untagged traffic.
>>  * Performance drop for tagged traffic but still significant
>> throughput.  This is due to the hardware not supporting the same
>> offloads when vlan tags are involved and software fallbacks are used.
>> This is most likely to show up on 10G links since most CPUs are fast
>> enough to handle the emulation at 1G.  This is interesting to note but
>> is a hardware limitation, not a bug.
>>  * Performance close (but probably not exactly) 0 for tagged traffic.
>> This is generally means that there is a problem with TSO and only
>> small packets get through.
>>
>> On Wed, Oct 19, 2011 at 12:14 PM, Ansis Atteka <aatteka at nicira.com> wrote:
>> > Jesse,
>> >
>> > Potentially we could add iperf TCP tests to the ovs-vlan-test and then
>> > IP
>> > packet length would match MTU? Albeit then iperf would not report
>> > packet-loss or out-of-order packet count.
>> >
>> > During the implementation I had following concerns:
>> >
>> > ovs-vlan-test utility uses iperf's STDOUT, STDERR to communicate with it
>> > and
>> > that might be iperf-version specific. Preferred approach would be to use
>> > some kind of a "iperf-type"-library, but I was not able to find one
>> > (maybe
>> > we could develop one ourselves?).
>> > Iperf also has limitation that smallest UDP packet it can send is
>> > 52-bytes
>> >
>> > Thanks,
>> > Ansis
>> >
>> > On Wed, Oct 19, 2011 at 11:21 AM, Jesse Gross <jesse at nicira.com> wrote:
>> >>
>> >> On Tue, Oct 18, 2011 at 9:23 PM, Ansis Atteka <aatteka at nicira.com>
>> >> wrote:
>> >> > ovs-vlan-test runs through a number of tests to identify VLAN issues.
>> >> >  This
>> >> > is useful when trying to debug why a particular driver has issues,
>> >> > but
>> >> > it made
>> >> > the testing environment a bit harder to set up.  This commit adds an
>> >> > iperf
>> >> > test to check basic functionality.  It also useful in detecting
>> >> > performance
>> >> > issues.
>> >> >
>> >> > Issue #6976
>> >>
>> >> I didn't review the implementation details but I have some high level
>> >> concerns about the tests being run:
>> >>  * At least some of the problems that we have encountered are due to
>> >> offloading and some offloads are only available with TCP.  Therefore,
>> >> running only UDP traffic won't catch these.
>> >>  * Another category of issues has do with exactly MTU sized packets.
>> >> I see that the packet sizes you use are the same as the previous
>> >> version but I'm not sure that they are great choices.  The first issue
>> >> is that it is essentially assuming that the MTU is 1500 but ideally we
>> >> would actually detect it.  Once we have it, I would pick a value that
>> >> is exactly MTU size after accounting for the UDP headers.  Right now
>> >> we will probably get that but you have to assume that fragmentation
>> >> results in a maximum size first packet.
>> >
>> >
>
>
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
>



More information about the dev mailing list