| View previous topic :: View next topic |
| Author |
Message |
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
 Posted: Tue Jun 25, 2013 6:11 pm Post subject: [SOLVED] change in mtu from hardened-3.8.6 to hardened-3.9.5 |
 |
|
Hallo Forum,
I just upgraded my kernel from hardened-3.8.6 to hardened-3.9.5. After the first reboot I received the following error message during the initialization of my network:
| Code: | | RTNETLINK answers: Invalid argument |
BTW my network cards operate in bond mode by bonding together 2 GB Intel network cards.
Further investigation revelead that the MTU was at 1500 instead of the expected 9216. Also setting the MTU through ifconfig from the cli to 9216 wasn't possible anymore. After further tries with different values, it turned out that obviously the (new) maximum MTU seems to be limited to 9000.
Up to hardened-3.8.6 an MTU of 9216 did not produce an error and ifconfig also showed that value as the active MTU.
Anybody experiencing the same issue?
Thanks and regards,
Atom2
Last edited by Atom2 on Tue Jun 25, 2013 11:17 pm; edited 2 times in total |
|
| Back to top |
|
 |
papahuhn
l33t
Joined: 06 Sep 2004
Posts: 626
|
| Posted: Tue Jun 25, 2013 7:48 pm Post subject: |
|
|
Which driver?
_________________
Death by snoo-snoo! |
|
| Back to top |
|
|
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
| Posted: Tue Jun 25, 2013 8:53 pm Post subject: |
|
|
Thanks for your reply and it is a very good and valid question - I should have made that clear in my initial post ...
In any case, the driver I use is Intel e1000e. lspci shows the two devices as
| Code: | 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 05)
07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection |
The issue is the same whether compiled as a module or directly linked into the kernel.
Thanks again,
Atom2 |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21602
|
| Posted: Tue Jun 25, 2013 10:08 pm Post subject: |
|
|
Are you sure the limit is 9000 and not 9018?
| commit c3d2dbf403367eb5c17f044aa74b772508d745c1: | commit c3d2dbf403367eb5c17f044aa74b772508d745c1
Author: Bruce Allan <bruce.w.allan@intel.com>
Date: Wed Jan 9 01:20:46 2013 +0000
e1000e: correct maximum frame size on 82579
The largest jumbo frame supported by the 82579 hardware is 9018.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> |
|
|
| Back to top |
|
|
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
| Posted: Tue Jun 25, 2013 10:39 pm Post subject: |
|
|
Hi Hu,
interesting find - and a technical document from Intel, page 129 seems to confirm your suspicion of 9018 byte. This seems to hold for both the external card (82579), and my interface (82579LM), which is hardwired onto the motherboard as part of the chipset (my link is actually for the chipset).
To answer your question: An MTU of 9000 works, an MTU of 9001 produces an error message on hardened-3.9.5 (both during startup and when manually changed from the default MTU of 1500 through ifconfig).
On the other hand an MTU of 9216 did *NOT* produce any errors up to and including hardened-3.8.6 - neither during startup nor when set manually with ifconfig and furthermore ifconfig showed 9216 as the currently active MTU value for both cases.
Now what do we make out of this: Either Intel's spec is wrong or the old e1000e driver was flawed and has set something, which does not work plus ifconfig has taken that set value as granted and has outrightly lied about the MTU.
This now leads to another question: Apart from the 18 missing bytes, can we actually trust in ifconfig reporting correct values?
Thanks again,
Atom2 |
|
| Back to top |
|
|
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
| Posted: Tue Jun 25, 2013 11:17 pm Post subject: |
|
|
O.K. - I figured out why 9000 is the current limit: it is the maximum allowed by the driver due to the following piece of code:
| Code: | static int e1000_change_mtu(struct net_device *netdev, int new_mtu)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
/* Jumbo frame support */
if ((max_frame > ETH_FRAME_LEN + ETH_FCS_LEN) &&
!(adapter->flags & FLAG_HAS_JUMBO_FRAMES)) {
e_err("Jumbo Frames not supported.\n");
return -EINVAL;
}
/* Supported frame sizes */
if ((new_mtu < ETH_ZLEN + ETH_FCS_LEN + VLAN_HLEN) ||
(max_frame > adapter->max_hw_frame_size)) {
e_err("Unsupported MTU setting\n");
return -EINVAL;
} |
The relevant piece of code for an example with the requested failing MTU of 9001 is first of all
| Code: | | int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN; |
which sets max_frame to a value of 9019 because of the calculation 9001 + 14 + 4
[Note: 9001 is the new_mtu, ETH_LEN is 14 and ETH_FCS_LEN is 4; both are defined in if_ether.h] and this results in
| Code: | | (max_frame > adapter->max_hw_frame_size) |
to evaluate to true because 9019 > 9018
[Note: max-hw_frame_size is defined in ich8lan.c with your find of 9018)
Thanks
Atom2 |
|
| Back to top |
|
|
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
| Posted: Tue Jun 25, 2013 11:19 pm Post subject: |
|
|
So in a nutshell the current limit for MTU Jumbo Frames in the e1000e driver for a 82579LM card is 9000 bytes.
Regards,
Atom2 |
|
| Back to top |
|
|
_______0
Guru
Joined: 15 Oct 2012
Posts: 521
|
| Posted: Wed Jun 26, 2013 5:06 pm Post subject: |
|
|
in which situation is good to touch MTU? I've never had to configured this on any card.
thanks |
|
| Back to top |
|
|
papahuhn
l33t
Joined: 06 Sep 2004
Posts: 626
|
| Posted: Wed Jun 26, 2013 6:43 pm Post subject: |
|
|
In high-speed networks in order to minimize the amount of hardware interrupts.
_________________
Death by snoo-snoo! |
|
| Back to top |
|
|
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
| Posted: Wed Jun 26, 2013 7:57 pm Post subject: |
|
|
| _______0 wrote: | | in which situation is good to touch MTU? I've never had to configured this on any card. |
This is a good tool to maximize throughput with less CPU overhead. Increasing the MTU is not a must - you can easily do evereything with a standard MTU of 1500 bytes.
Increasing the MTU however requires hardware support from *all* pices of network hardware involved. In other words not only both the sending and the receiving NIC must support it, but also any hardware en route from source to destination must be able to deal with so called Jumbo Frames as otherwise larger packets get fragmented to smaller sizes again.
Required support for Jumbo Frames on a LAN clearly also includes switches to which your NICs are connected. Jumbo Frames usually explicitly have to be enabled to work on switches. Consumer grade switches in most cases do not support Jumbo Frames. |
|
| Back to top |
|
|
|
Networking & Security
