From: Simon Horman <horms@verge.net.au>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Simon Kirby <sim@hostway.ca>,
netdev@vger.kernel.org
Subject: Re: TSO/GRO/LRO/somethingO breaks LVS on 2.6.36
Date: Fri, 3 Dec 2010 22:39:53 +0900 [thread overview]
Message-ID: <20101203133953.GA28524@verge.net.au> (raw)
In-Reply-To: <1291382839.8025.40.camel@localhost>
On Fri, Dec 03, 2010 at 01:27:19PM +0000, Ben Hutchings wrote:
> On Fri, 2010-12-03 at 21:36 +0900, Simon Horman wrote:
> > On Fri, Dec 03, 2010 at 12:29:03PM +0100, Eric Dumazet wrote:
> [...]
> > > I believe Simon Horman has some patches for GRO and LVS.
> > >
> > > Please send the results of "ethtool -k eth0" on all your nics / vlans ?
> > >
> > > For TSO, I am not sure why and where it could matter...
> >
> > There is a patch to teach LVS how to cope with GRO in nf-next-2.6
> > and I expect it to be included in 2.6.38. The patch is "ipvs: allow
> > transmit of GRO aggregated skbs" and perhaps it should be considered
> > for 2.6.37 and stable. In general the work around is to disable GRO.
> >
> > The patch does not resolve the incompatibility of LVS with LRO.
> > The work around there is to disable LRO. I'm not entirely sure
> > how to teach LVS to disable LRO automatically, or if its desirable.
> [...]
>
> I think it is desirable, and we already do it for bridging and
> forwarding - we call dev_disable_lro() whenever a device is added to a
> bridge or has forwarding enabled. For IPVS it looks like you would have
> to resolve the server IP address to a device first. Though if the
> administrator assigns the server address to a different interface later
> then the failure mode will be very hard to understand.
Thanks, I'll try and make it so.
next prev parent reply other threads:[~2010-12-03 13:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-03 10:34 TSO/GRO/LRO/somethingO breaks LVS on 2.6.36 Simon Kirby
2010-12-03 11:29 ` Eric Dumazet
2010-12-03 12:36 ` Simon Horman
2010-12-03 12:42 ` Simon Horman
2010-12-03 13:27 ` Ben Hutchings
2010-12-03 13:39 ` Simon Horman [this message]
2010-12-09 2:35 ` Simon Kirby
2010-12-09 2:51 ` Eric Dumazet
2010-12-22 23:39 ` Simon Kirby
2011-01-13 6:34 ` Simon Horman
2011-01-27 0:48 ` Simon Kirby
2011-01-27 1:36 ` Simon Horman
2011-01-27 7:42 ` Eric Dumazet
2011-01-27 14:42 ` Simon Horman
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=20101203133953.GA28524@verge.net.au \
--to=horms@verge.net.au \
--cc=bhutchings@solarflare.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sim@hostway.ca \
/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.