[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