All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: igor@novg.net
Cc: netdev@vger.kernel.org, bugzilla-daemon@bugzilla.kernel.org,
	bugme-daemon@bugzilla.kernel.org,
	Stephen Hemminger <shemminger@linux-foundation.org>,
	Neil Horman <nhorman@tuxdriver.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Bugme-new] [Bug 36602] New: Bridge fails to work normally without net.ipv4.ip_forward=1
Date: Fri, 03 Jun 2011 23:37:46 +0100	[thread overview]
Message-ID: <1307140667.22348.120.camel@localhost> (raw)
In-Reply-To: <20110603123632.139f83ca.akpm@linux-foundation.org>

On Fri, 2011-06-03 at 12:36 -0700, Andrew Morton wrote:
[...]
> > At the bridge, on each interface i've created a vlan, and then bridged them:
> > # vconfig add eth0 102
> > # vconfig add eth1 102
> > # brctl addbr br0
> > # brctl addif br0 eth0.102
> > # brctl addif br0 eth1.102
> > # ip link set br0 mtu 9000 up
> > ...etc...
> > 
> > At this point, the bridge seems to be working, i can ping between host1 &
> > host2, even with jumbo frames without fragmentation.
> > 
> > BUT when i am trying to use iperf & friends to measure raw tcp speed between
> > hosts 1/2, i'm getting something weird like 7-10 MEGABITS per second, or even
> > an iperf hang until ctrl+c.

This sounds like a symptom of doing LRO on a bridged device.  Normally
we turn off LRO for bridge members automatically, but we haven't been
doing that when the bridge members are VLAN devices.

> > If i attach an ip address to the bridge, and measure between hosts and the
> > bridge, it works flawlessly, rendering 9.8Gbit/s in both directions.
> > 
> > While trying to find a solution, when i ran out of options, i've set
> > net.ipv4.ip_forward to 1, and, SURPRISE, the bridge started to work like a
> > charm, at almost 10gig speed.
[...]

Right, that should force LRO off for all devices with IPv4 set up.

This should be fixed by:

commit f11970e383acd6f505f492f1bc07fb1a4d884829
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Tue May 24 08:31:09 2011 +0000

    net: make dev_disable_lro use physical device if passed a vlan dev (v2)

which is in 3.0-rc1.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


      reply	other threads:[~2011-06-03 22:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-36602-10286@https.bugzilla.kernel.org/>
2011-06-03 19:36 ` [Bugme-new] [Bug 36602] New: Bridge fails to work normally without net.ipv4.ip_forward=1 Andrew Morton
2011-06-03 22:37   ` Ben Hutchings [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1307140667.22348.120.camel@localhost \
    --to=bhutchings@solarflare.com \
    --cc=akpm@linux-foundation.org \
    --cc=bugme-daemon@bugzilla.kernel.org \
    --cc=bugzilla-daemon@bugzilla.kernel.org \
    --cc=igor@novg.net \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=shemminger@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.