From: Ben Hutchings <bhutchings@solarflare.com>
To: Christer Ekholm <che@chrekh.se>
Cc: Stephen Hemminger <shemminger@vyatta.com>,
<netdev@vger.kernel.org>,
"Allan, Bruce W" <bruce.w.allan@intel.com>,
<e1000-devel@lists.sf.net>
Subject: Re: [Bug 43277] New: net/e1000e set mtu larger than 1500 fails
Date: Tue, 22 May 2012 19:59:16 +0100 [thread overview]
Message-ID: <1337713156.2922.12.camel@bwh-desktop.uk.solarflarecom.com> (raw)
In-Reply-To: <20411.56693.728125.121309@ender.chrekh.se>
On Tue, 2012-05-22 at 20:39 +0200, Christer Ekholm wrote:
> Stephen Hemminger writes:
> > On Tue, 22 May 2012 11:19:50 -0700
> > Stephen Hemminger <shemminger@vyatta.com> wrote:
> >
> >
> > I believe the problem is detected here. Check system console log (dmesg).
> > The hardware does not allow receive hashing and checksum offload together
> > in Jumbo mode.
> >
> > /*
> > * IP payload checksum (enabled with jumbos/packet-split when
> > * Rx checksum is enabled) and generation of RSS hash is
> > * mutually exclusive in the hardware.
> > */
> > if ((netdev->features & NETIF_F_RXCSUM) &&
> > (netdev->features & NETIF_F_RXHASH)) {
> > e_err("Jumbo frames cannot be enabled when both receive checksum offload and receive hashing are enabled. Disable one of the receive offload features before enabling jumbos.\n");
> > return -EINVAL;
> > }
>
> Yes you are right.
>
> e1000e 0000:05:00.1: eth1: Jumbo frames cannot be enabled when both receive checksum offload and receive hashing are enabled. Disable one of the receive offload features before enabling jumbos.
>
> How stupid of me to not see that.
>
> After turning rxhash of, setting of mtu to 9000 is possible again.
>
> $ sudo ethtool -K eth1 rxhash off
>
> $ sudo ip link set eth1 mtu 9000
>
>
> Sorry to have wasted your time.
It's not a waste of time.
I think this behaviour is broken: NETIF_F_RXHASH is turned on by default
and user and distribution scripts that set MTU will now be broken until
they know that they need to work around this hardware limitation. And
why should they ever need to know that?
I think the proper thing to do is to automatically turn off
NETIF_F_RXHASH when the MTU is too high for it to work. The netdev
still keeps track of whether it is 'wanted'.
Ben.
--
Ben Hutchings, Staff 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.
next prev parent reply other threads:[~2012-05-22 18:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-22 18:19 Fw: [Bug 43277] New: net/e1000e set mtu larger than 1500 fails Stephen Hemminger
2012-05-22 18:25 ` Stephen Hemminger
2012-05-22 18:28 ` Allan, Bruce W
2012-05-22 18:39 ` Christer Ekholm
2012-05-22 18:59 ` Ben Hutchings [this message]
2012-05-22 21:29 ` Stephen Hemminger
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=1337713156.2922.12.camel@bwh-desktop.uk.solarflarecom.com \
--to=bhutchings@solarflare.com \
--cc=bruce.w.allan@intel.com \
--cc=che@chrekh.se \
--cc=e1000-devel@lists.sf.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox