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

Ben Pfaff blp at nicira.com
Wed Oct 19 19:34:13 UTC 2011


You could, however, compare TCP performance with and without a VLAN
being involved.  Packet loss or out-of-order packets will show up as
performance loss.

On Wed, Oct 19, 2011 at 12:14:16PM -0700, Ansis Atteka 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:
> 
>    1. 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?).
>    2. 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