Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/897794/?format=api
{ "id": 897794, "url": "http://patchwork.ozlabs.org/api/patches/897794/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/patch/20180412203600.18829-1-jeffrey.t.kirsher@intel.com/", "project": { "id": 46, "url": "http://patchwork.ozlabs.org/api/projects/46/?format=api", "name": "Intel Wired Ethernet development", "link_name": "intel-wired-lan", "list_id": "intel-wired-lan.osuosl.org", "list_email": "intel-wired-lan@osuosl.org", "web_url": "", "scm_url": "", "webscm_url": "", "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<20180412203600.18829-1-jeffrey.t.kirsher@intel.com>", "list_archive_url": null, "date": "2018-04-12T20:36:00", "name": "[v2] Documentation: e1000e: Update kernel documentation", "commit_ref": null, "pull_url": null, "state": "changes-requested", "archived": false, "hash": "aabbbf73dc8676e1c46d4fa57f8eea622b72a939", "submitter": { "id": 473, "url": "http://patchwork.ozlabs.org/api/people/473/?format=api", "name": "Kirsher, Jeffrey T", "email": "jeffrey.t.kirsher@intel.com" }, "delegate": { "id": 68, "url": "http://patchwork.ozlabs.org/api/users/68/?format=api", "username": "jtkirshe", "first_name": "Jeff", "last_name": "Kirsher", "email": "jeffrey.t.kirsher@intel.com" }, "mbox": "http://patchwork.ozlabs.org/project/intel-wired-lan/patch/20180412203600.18829-1-jeffrey.t.kirsher@intel.com/mbox/", "series": [ { "id": 38709, "url": "http://patchwork.ozlabs.org/api/series/38709/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/list/?series=38709", "date": "2018-04-12T20:36:00", "name": "[v2] Documentation: e1000e: Update kernel documentation", "version": 2, "mbox": "http://patchwork.ozlabs.org/series/38709/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/897794/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/897794/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<intel-wired-lan-bounces@osuosl.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "intel-wired-lan@lists.osuosl.org" ], "Delivered-To": [ "patchwork-incoming@bilbo.ozlabs.org", "intel-wired-lan@lists.osuosl.org" ], "Authentication-Results": [ "ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.138; helo=whitealder.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=<UNKNOWN>)", "ozlabs.org;\n\tdmarc=none (p=none dis=none) header.from=intel.com" ], "Received": [ "from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 40MXhz3JsQz9s1R\n\tfor <incoming@patchwork.ozlabs.org>;\n\tFri, 13 Apr 2018 06:35:15 +1000 (AEST)", "from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id AD728886D2;\n\tThu, 12 Apr 2018 20:35:13 +0000 (UTC)", "from whitealder.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id Mh5EcF4afK75; Thu, 12 Apr 2018 20:35:09 +0000 (UTC)", "from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 1169D886D9;\n\tThu, 12 Apr 2018 20:35:09 +0000 (UTC)", "from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\tby ash.osuosl.org (Postfix) with ESMTP id 4D4451C0E79\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tThu, 12 Apr 2018 20:35:08 +0000 (UTC)", "from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id 494782DDD6\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tThu, 12 Apr 2018 20:35:08 +0000 (UTC)", "from silver.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id uFOOhOUZQPzg for <intel-wired-lan@lists.osuosl.org>;\n\tThu, 12 Apr 2018 20:35:06 +0000 (UTC)", "from mga11.intel.com (mga11.intel.com [192.55.52.93])\n\tby silver.osuosl.org (Postfix) with ESMTPS id 733252DCD3\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tThu, 12 Apr 2018 20:35:06 +0000 (UTC)", "from orsmga004.jf.intel.com ([10.7.209.38])\n\tby fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t12 Apr 2018 13:35:05 -0700", "from jtkirshe-nuc.jf.intel.com ([134.134.177.59])\n\tby orsmga004.jf.intel.com with ESMTP; 12 Apr 2018 13:35:05 -0700" ], "X-Virus-Scanned": [ "amavisd-new at osuosl.org", "amavisd-new at osuosl.org" ], "X-Greylist": "domain auto-whitelisted by SQLgrey-1.7.6", "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.48,443,1517904000\"; d=\"scan'208\";a=\"191065596\"", "From": "Jeff Kirsher <jeffrey.t.kirsher@intel.com>", "To": "intel-wired-lan@lists.osuosl.org", "Date": "Thu, 12 Apr 2018 13:36:00 -0700", "Message-Id": "<20180412203600.18829-1-jeffrey.t.kirsher@intel.com>", "X-Mailer": "git-send-email 2.14.3", "Subject": "[Intel-wired-lan] [PATCH v2] Documentation: e1000e: Update kernel\n\tdocumentation", "X-BeenThere": "intel-wired-lan@osuosl.org", "X-Mailman-Version": "2.1.24", "Precedence": "list", "List-Id": "Intel Wired Ethernet Linux Kernel Driver Development\n\t<intel-wired-lan.osuosl.org>", "List-Unsubscribe": "<https://lists.osuosl.org/mailman/options/intel-wired-lan>, \n\t<mailto:intel-wired-lan-request@osuosl.org?subject=unsubscribe>", "List-Archive": "<http://lists.osuosl.org/pipermail/intel-wired-lan/>", "List-Post": "<mailto:intel-wired-lan@osuosl.org>", "List-Help": "<mailto:intel-wired-lan-request@osuosl.org?subject=help>", "List-Subscribe": "<https://lists.osuosl.org/mailman/listinfo/intel-wired-lan>, \n\t<mailto:intel-wired-lan-request@osuosl.org?subject=subscribe>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "7bit", "Errors-To": "intel-wired-lan-bounces@osuosl.org", "Sender": "\"Intel-wired-lan\" <intel-wired-lan-bounces@osuosl.org>" }, "content": "Updated the e1000e.txt kernel documentation with the latest information.\n\nSigned-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>\n---\nv2: fixed up documentation based on community feedback and internal\n review\n\n---\n Documentation/networking/e1000e.txt | 460 ++++++++++++++++++------------------\n 1 file changed, 233 insertions(+), 227 deletions(-)", "diff": "diff --git a/Documentation/networking/e1000e.txt b/Documentation/networking/e1000e.txt\nindex 12089547baed..e9dd18e1d2c6 100644\n--- a/Documentation/networking/e1000e.txt\n+++ b/Documentation/networking/e1000e.txt\n@@ -2,7 +2,7 @@ Linux* Driver for Intel(R) Ethernet Network Connection\n ======================================================\n \n Intel Gigabit Linux driver.\n-Copyright(c) 1999 - 2013 Intel Corporation.\n+Copyright(c) 1999-2018 Intel Corporation.\n \n Contents\n ========\n@@ -13,300 +13,306 @@ Contents\n - Support\n \n Identifying Your Adapter\n-========================\n+------------------------\n+For information on how to identify your adapter, and for the latest Intel\n+network drivers, refer to the Intel Support website:\n+http://www.intel.com/support\n \n-The e1000e driver supports all PCI Express Intel(R) Gigabit Network\n-Connections, except those that are 82575, 82576 and 82580-based*.\n-\n-* NOTE: The Intel(R) PRO/1000 P Dual Port Server Adapter is supported by\n- the e1000 driver, not the e1000e driver due to the 82546 part being used\n- behind a PCI Express bridge.\n-\n-For more information on how to identify your adapter, go to the Adapter &\n-Driver ID Guide at:\n-\n- http://support.intel.com/support/go/network/adapter/idguide.htm\n-\n-For the latest Intel network drivers for Linux, refer to the following\n-website. In the search field, enter your adapter name or type, or use the\n-networking link on the left to search for your adapter:\n-\n- http://support.intel.com/support/go/network/adapter/home.htm\n \n Command Line Parameters\n-=======================\n-\n+-----------------------\n+If the driver is built as a module, the following optional parameters are used\n+by entering them on the command line with the modprobe command using this\n+syntax:\n+modprobe e1000e [<option>=<VAL1>,<VAL2>,...]\n+\n+There needs to be a <VAL#> for each network port in the system supported by\n+this driver. The values will be applied to each instance, in function order.\n+For example:\n+modprobe e1000e InterruptThrottleRate=16000,16000\n+\n+In this case, there are two network ports supported by e1000e in the system.\n The default value for each parameter is generally the recommended setting,\n unless otherwise noted.\n \n-NOTES: For more information about the InterruptThrottleRate,\n- RxIntDelay, TxIntDelay, RxAbsIntDelay, and TxAbsIntDelay\n- parameters, see the application note at:\n- http://www.intel.com/design/network/applnots/ap450.htm\n+NOTE: For more information about the command line parameters, see the\n+application note at: http://www.intel.com/design/network/applnots/ap450.htm.\n+\n+NOTE: A descriptor describes a data buffer and attributes related to the data\n+buffer. This information is accessed by the hardware.\n+\n \n InterruptThrottleRate\n ---------------------\n-Valid Range: 0,1,3,4,100-100000 (0=off, 1=dynamic, 3=dynamic conservative,\n- 4=simplified balancing)\n-Default Value: 3\n-\n-The driver can limit the amount of interrupts per second that the adapter\n-will generate for incoming packets. It does this by writing a value to the\n-adapter that is based on the maximum amount of interrupts that the adapter\n-will generate per second.\n-\n-Setting InterruptThrottleRate to a value greater or equal to 100\n-will program the adapter to send out a maximum of that many interrupts\n-per second, even if more packets have come in. This reduces interrupt\n-load on the system and can lower CPU utilization under heavy load,\n-but will increase latency as packets are not processed as quickly.\n-\n-The default behaviour of the driver previously assumed a static\n-InterruptThrottleRate value of 8000, providing a good fallback value for\n-all traffic types, but lacking in small packet performance and latency.\n-The hardware can handle many more small packets per second however, and\n-for this reason an adaptive interrupt moderation algorithm was implemented.\n-\n-The driver has two adaptive modes (setting 1 or 3) in which\n-it dynamically adjusts the InterruptThrottleRate value based on the traffic\n-that it receives. After determining the type of incoming traffic in the last\n-timeframe, it will adjust the InterruptThrottleRate to an appropriate value\n-for that traffic.\n-\n-The algorithm classifies the incoming traffic every interval into\n-classes. Once the class is determined, the InterruptThrottleRate value is\n-adjusted to suit that traffic type the best. There are three classes defined:\n-\"Bulk traffic\", for large amounts of packets of normal size; \"Low latency\",\n-for small amounts of traffic and/or a significant percentage of small\n-packets; and \"Lowest latency\", for almost completely small packets or\n-minimal traffic.\n-\n-In dynamic conservative mode, the InterruptThrottleRate value is set to 4000\n-for traffic that falls in class \"Bulk traffic\". If traffic falls in the \"Low\n-latency\" or \"Lowest latency\" class, the InterruptThrottleRate is increased\n-stepwise to 20000. This default mode is suitable for most applications.\n-\n-For situations where low latency is vital such as cluster or\n-grid computing, the algorithm can reduce latency even more when\n-InterruptThrottleRate is set to mode 1. In this mode, which operates\n-the same as mode 3, the InterruptThrottleRate will be increased stepwise to\n-70000 for traffic in class \"Lowest latency\".\n-\n-In simplified mode the interrupt rate is based on the ratio of TX and\n-RX traffic. If the bytes per second rate is approximately equal, the\n-interrupt rate will drop as low as 2000 interrupts per second. If the\n-traffic is mostly transmit or mostly receive, the interrupt rate could\n-be as high as 8000.\n-\n-Setting InterruptThrottleRate to 0 turns off any interrupt moderation\n-and may improve small packet latency, but is generally not suitable\n-for bulk throughput traffic.\n-\n-NOTE: InterruptThrottleRate takes precedence over the TxAbsIntDelay and\n- RxAbsIntDelay parameters. In other words, minimizing the receive\n- and/or transmit absolute delays does not force the controller to\n- generate more interrupts than what the Interrupt Throttle Rate\n- allows.\n-\n-NOTE: When e1000e is loaded with default settings and multiple adapters\n- are in use simultaneously, the CPU utilization may increase non-\n- linearly. In order to limit the CPU utilization without impacting\n- the overall throughput, we recommend that you load the driver as\n- follows:\n-\n- modprobe e1000e InterruptThrottleRate=3000,3000,3000\n-\n- This sets the InterruptThrottleRate to 3000 interrupts/sec for\n- the first, second, and third instances of the driver. The range\n- of 2000 to 3000 interrupts per second works on a majority of\n- systems and is a good starting point, but the optimal value will\n- be platform-specific. If CPU utilization is not a concern, use\n- RX_POLLING (NAPI) and default driver settings.\n+Valid Range:\n+0=off\n+1=dynamic\n+4=simplified balancing\n+<min_ITR>-<max_ITR>\n+Interrupt Throttle Rate controls the number of interrupts each interrupt\n+vector can generate per second. Increasing ITR lowers latency at the cost of\n+increased CPU utilization, though it may help throughput in some circumstances.\n+0 = Setting InterruptThrottleRate to 0 turns off any interrupt moderation\n+ and may improve small packet latency. However, this is generally not\n+ suitable for bulk throughput traffic due to the increased CPU utilization\n+ of the higher interrupt rate.\n+ NOTES:\n+ - On 82599, and X540, and X550-based adapters, disabling InterruptThrottleRate\n+ will also result in the driver disabling HW RSC.\n+ - On 82598-based adapters, disabling InterruptThrottleRate will also\n+ result in disabling LRO (Large Receive Offloads).\n+1 = Setting InterruptThrottleRate to Dynamic mode attempts to moderate\n+ interrupts per vector while maintaining very low latency. This can\n+ sometimes cause extra CPU utilization. If planning on deploying e1000e\n+ in a latency sensitive environment, this parameter should be considered.\n+<min_ITR>-<max_ITR> =\n+ Setting InterruptThrottleRate to a value greater or equal to <min_ITR>\n+ will program the adapter to send at most that many interrupts\n+ per second, even if more packets have come in. This reduces interrupt load\n+ on the system and can lower CPU utilization under heavy load, but will\n+ increase latency as packets are not processed as quickly.\n+\n+NOTE:\n+- InterruptThrottleRate takes precedence over the TxAbsIntDelay and\n+ RxAbsIntDelay parameters. In other words, minimizing the receive and/or\n+ transmit absolute delays does not force the controller to generate more\n+ interrupts than what the Interrupt Throttle Rate allows.\n+\n \n RxIntDelay\n ----------\n-Valid Range: 0-65535 (0=off)\n-Default Value: 0\n-\n+Valid Range: 0-65535 (0=off)\n This value delays the generation of receive interrupts in units of 1.024\n-microseconds. Receive interrupt reduction can improve CPU efficiency if\n-properly tuned for specific network traffic. Increasing this value adds\n-extra latency to frame reception and can end up decreasing the throughput\n-of TCP traffic. If the system is reporting dropped receives, this value\n-may be set too high, causing the driver to run out of available receive\n-descriptors.\n-\n-CAUTION: When setting RxIntDelay to a value other than 0, adapters may\n- hang (stop transmitting) under certain network conditions. If\n- this occurs a NETDEV WATCHDOG message is logged in the system\n- event log. In addition, the controller is automatically reset,\n- restoring the network connection. To eliminate the potential\n- for the hang ensure that RxIntDelay is set to 0.\n+microseconds. Receive interrupt reduction can improve CPU efficiency if\n+properly tuned for specific network traffic. Increasing this value adds extra\n+latency to frame reception and can end up decreasing the throughput of TCP\n+traffic. If the system is reporting dropped receives, this value may be set\n+too high, causing the driver to run out of available receive descriptors.\n+CAUTION: When setting RxIntDelay to a value other than 0, adapters may hang\n+(stop transmitting) under certain network conditions. If this occurs a NETDEV\n+WATCHDOG message is logged in the system event log. In addition, the\n+controller is automatically reset, restoring the network connection. To\n+eliminate the potential for the hang ensure that RxIntDelay is set to 0.\n \n RxAbsIntDelay\n -------------\n-Valid Range: 0-65535 (0=off)\n-Default Value: 8\n-\n+Valid Range: 0-65535 (0=off)\n This value, in units of 1.024 microseconds, limits the delay in which a\n-receive interrupt is generated. Useful only if RxIntDelay is non-zero,\n-this value ensures that an interrupt is generated after the initial\n-packet is received within the set amount of time. Proper tuning,\n-along with RxIntDelay, may improve traffic throughput in specific network\n-conditions.\n+receive interrupt is generated. This value ensures that an interrupt is\n+generated after the initial packet is received within the set amount of time,\n+which is useful only if RxIntDelay is non-zero. Proper tuning, along with\n+RxIntDelay, may improve traffic throughput in specific network conditions.\n+\n \n TxIntDelay\n ----------\n-Valid Range: 0-65535 (0=off)\n-Default Value: 8\n+Valid Range: 0-65535 (0=off)\n+This value delays the generation of transmit interrupts in units of 1.024\n+microseconds. Transmit interrupt reduction can improve CPU efficiency if\n+properly tuned for specific network traffic. If the system is reporting\n+dropped transmits, this value may be set too high causing the driver to run\n+out of available transmit descriptors.\n \n-This value delays the generation of transmit interrupts in units of\n-1.024 microseconds. Transmit interrupt reduction can improve CPU\n-efficiency if properly tuned for specific network traffic. If the\n-system is reporting dropped transmits, this value may be set too high\n-causing the driver to run out of available transmit descriptors.\n \n TxAbsIntDelay\n -------------\n-Valid Range: 0-65535 (0=off)\n-Default Value: 32\n-\n+Valid Range: 0-65535 (0=off)\n This value, in units of 1.024 microseconds, limits the delay in which a\n-transmit interrupt is generated. Useful only if TxIntDelay is non-zero,\n-this value ensures that an interrupt is generated after the initial\n-packet is sent on the wire within the set amount of time. Proper tuning,\n-along with TxIntDelay, may improve traffic throughput in specific\n-network conditions.\n+transmit interrupt is generated. It is useful only if TxIntDelay is non-zero.\n+It ensures that an interrupt is generated after the initial Packet is sent on\n+the wire within the set amount of time. Proper tuning, along with TxIntDelay,\n+may improve traffic throughput in specific network conditions.\n \n-Copybreak\n----------\n-Valid Range: 0-xxxxxxx (0=off)\n-Default Value: 256\n \n-Driver copies all packets below or equaling this size to a fresh RX\n+copybreak\n+---------\n+Valid Range: 0-xxxxxxx (0=off)\n+The driver copies all packets below or equaling this size to a fresh receive\n buffer before handing it up the stack.\n+This parameter differs from other parameters because it is a single (not 1,1,1\n+etc.) parameter applied to all driver instances and it is also available\n+during runtime at /sys/module/e1000e/parameters/copybreak.\n+\n+To use copybreak, type\n+\n+ modprobe e1000e.ko copybreak=128\n \n-This parameter is different than other parameters, in that it is a\n-single (not 1,1,1 etc.) parameter applied to all driver instances and\n-it is also available during runtime at\n-/sys/module/e1000e/parameters/copybreak\n \n SmartPowerDownEnable\n --------------------\n Valid Range: 0-1\n-Default Value: 0 (disabled)\n+Allows Phy to turn off in lower power states. The user can turn off this\n+parameter in supported chipsets.\n \n-Allows PHY to turn off in lower power states. The user can set this parameter\n-in supported chipsets.\n \n KumeranLockLoss\n ---------------\n Valid Range: 0-1\n-Default Value: 1 (enabled)\n+This workaround skips resetting the Phy at shutdown for the initial silicon\n+releases of ICH8 systems.\n \n-This workaround skips resetting the PHY at shutdown for the initial\n-silicon releases of ICH8 systems.\n \n IntMode\n -------\n-Valid Range: 0-2 (0=legacy, 1=MSI, 2=MSI-X)\n-Default Value: 2\n+Valid Range: 0-2 (0 = Legacy Int, 1 = MSI and 2 = MSI-X)\n+IntMode controls allow load time control over the type of interrupt\n+registered for by the driver. MSI-X is required for multiple queue\n+support, and some kernels and combinations of kernel .config options\n+will force a lower level of interrupt support.\n+'cat /proc/interrupts' will show different values for each type of interrupt.\n \n-Allows changing the interrupt mode at module load time, without requiring a\n-recompile. If the driver load fails to enable a specific interrupt mode, the\n-driver will try other interrupt modes, from least to most compatible. The\n-interrupt order is MSI-X, MSI, Legacy. If specifying MSI (IntMode=1)\n-interrupts, only MSI and Legacy will be attempted.\n \n CrcStripping\n ------------\n Valid Range: 0-1\n-Default Value: 1 (enabled)\n-\n-Strip the CRC from received packets before sending up the network stack. If\n+Strip the CRC from received packets before sending up the network stack. If\n you have a machine with a BMC enabled but cannot receive IPMI traffic after\n loading or enabling the driver, try disabling this feature.\n \n+\n WriteProtectNVM\n ---------------\n+\n Valid Range: 0,1\n-Default Value: 1\n \n If set to 1, configure the hardware to ignore all write/erase cycles to the\n GbE region in the ICHx NVM (in order to prevent accidental corruption of the\n NVM). This feature can be disabled by setting the parameter to 0 during initial\n driver load.\n+\n NOTE: The machine must be power cycled (full off/on) when enabling NVM writes\n via setting the parameter to zero. Once the NVM has been locked (via the\n parameter at 1 when the driver loads) it cannot be unlocked except via power\n cycle.\n \n-Additional Configurations\n-=========================\n-\n- Jumbo Frames\n- ------------\n- Jumbo Frames support is enabled by changing the MTU to a value larger than\n- the default of 1500. Use the ifconfig command to increase the MTU size.\n- For example:\n-\n- ifconfig eth<x> mtu 9000 up\n-\n- This setting is not saved across reboots.\n-\n- Notes:\n-\n- - The maximum MTU setting for Jumbo Frames is 9216. This value coincides\n- with the maximum Jumbo Frames size of 9234 bytes.\n-\n- - Using Jumbo frames at 10 or 100 Mbps is not supported and may result in\n- poor performance or loss of link.\n-\n- - Some adapters limit Jumbo Frames sized packets to a maximum of\n- 4096 bytes and some adapters do not support Jumbo Frames.\n-\n- - Jumbo Frames cannot be configured on an 82579-based Network device, if\n- MACSec is enabled on the system.\n-\n- ethtool\n- -------\n- The driver utilizes the ethtool interface for driver configuration and\n- diagnostics, as well as displaying statistical information. We\n- strongly recommend downloading the latest version of ethtool at:\n \n- https://kernel.org/pub/software/network/ethtool/\n+Additional Features and Configurations\n+-------------------------------------------\n \n- NOTE: When validating enable/disable tests on some parts (82578, for example)\n- you need to add a few seconds between tests when working with ethtool.\n-\n- Speed and Duplex\n- ----------------\n- Speed and Duplex are configured through the ethtool* utility. For\n- instructions, refer to the ethtool man page.\n-\n- Enabling Wake on LAN* (WoL)\n- ---------------------------\n- WoL is configured through the ethtool* utility. For instructions on\n- enabling WoL with ethtool, refer to the ethtool man page.\n-\n- WoL will be enabled on the system during the next shut down or reboot.\n- For this driver version, in order to enable WoL, the e1000e driver must be\n- loaded when shutting down or rebooting the system.\n+Jumbo Frames\n+------------\n+Jumbo Frames support is enabled by changing the Maximum Transmission Unit (MTU)\n+to a value larger than the default value of 1500.\n+\n+Use the ifconfig command to increase the MTU size. For example, enter the\n+following where <x> is the interface number:\n+\n+ ifconfig eth<x> mtu 9000 up\n+Alternatively, you can use the ip command as follows:\n+ ip link set mtu 9000 dev eth<x>\n+ ip link set up dev eth<x>\n+\n+This setting is not saved across reboots. The setting change can be made\n+permanent by adding 'MTU=9000' to the file:\n+/etc/sysconfig/network-scripts/ifcfg-eth<x> for RHEL or to the file\n+/etc/sysconfig/network/<config_file> for SLES.\n+\n+NOTE: The maximum MTU setting for Jumbo Frames is 8996. This value coincides\n+with the maximum Jumbo Frames size of 9018 bytes.\n+\n+NOTE: Using Jumbo frames at 10 or 100 Mbps is not supported and may result in\n+poor performance or loss of link.\n+\n+NOTE: The following adapters limit Jumbo Frames sized packets to a maximum of\n+4088 bytes:\n+ - Intel(R) 82578DM Gigabit Network Connection\n+ - Intel(R) 82577LM Gigabit Network Connection\n+- The following adapters do not support Jumbo Frames:\n+ - Intel(R) PRO/1000 Gigabit Server Adapter\n+ - Intel(R) PRO/1000 PM Network Connection\n+ - Intel(R) 82562G 10/100 Network Connection\n+ - Intel(R) 82562G-2 10/100 Network Connection\n+ - Intel(R) 82562GT 10/100 Network Connection\n+ - Intel(R) 82562GT-2 10/100 Network Connection\n+ - Intel(R) 82562V 10/100 Network Connection\n+ - Intel(R) 82562V-2 10/100 Network Connection\n+ - Intel(R) 82566DC Gigabit Network Connection\n+ - Intel(R) 82566DC-2 Gigabit Network Connection\n+ - Intel(R) 82566DM Gigabit Network Connection\n+ - Intel(R) 82566MC Gigabit Network Connection\n+ - Intel(R) 82566MM Gigabit Network Connection\n+ - Intel(R) 82567V-3 Gigabit Network Connection\n+ - Intel(R) 82577LC Gigabit Network Connection\n+ - Intel(R) 82578DC Gigabit Network Connection\n+- Jumbo Frames cannot be configured on an 82579-based Network device if\n+ MACSec is enabled on the system.\n+\n+\n+ethtool\n+-------\n+The driver utilizes the ethtool interface for driver configuration and\n+diagnostics, as well as displaying statistical information. The latest ethtool\n+version is required for this functionality. Download it at:\n+http://ftp.kernel.org/pub/software/network/ethtool/\n+\n+NOTE: When validating enable/disable tests on some parts (for example, 82578),\n+it is necessary to add a few seconds between tests when working with ethtool.\n+\n+\n+Speed and Duplex Configuration\n+------------------------------\n+In addressing speed and duplex configuration issues, you need to distinguish\n+between copper-based adapters and fiber-based adapters.\n+\n+In the default mode, an Intel(R) Ethernet Network Adapter using copper\n+connections will attempt to auto-negotiate with its link partner to determine\n+the best setting. If the adapter cannot establish link with the link partner\n+using auto-negotiation, you may need to manually configure the adapter and link\n+partner to identical settings to establish link and pass packets. This should\n+only be needed when attempting to link with an older switch that does not\n+support auto-negotiation or one that has been forced to a specific speed or\n+duplex mode. Your link partner must match the setting you choose. 1 Gbps speeds\n+and higher cannot be forced. Use the autonegotiation advertising setting to\n+manually set devices for 1 Gbps and higher.\n+\n+Speed, duplex, and autonegotiation advertising are configured through the\n+ethtool* utility. ethtool is included with all versions of Red Hat after Red\n+Hat 7.2. For the latest version, download and install ethtool from the\n+following website:\n+\n+ http://ftp.kernel.org/pub/software/network/ethtool/\n+\n+Caution: Only experienced network administrators should force speed and duplex\n+or change autonegotiation advertising manually. The settings at the switch must\n+always match the adapter settings. Adapter performance may suffer or your\n+adapter may not operate if you configure the adapter differently from your\n+switch.\n+\n+An Intel(R) Ethernet Network Adapter using fiber-based connections, however,\n+will not attempt to auto-negotiate with its link partner since those adapters\n+operate only in full duplex and only at their native speed.\n+\n+\n+Enabling Wake on LAN* (WoL)\n+---------------------------\n+WoL is configured through the ethtool* utility. ethtool is included with all\n+versions of Red Hat after Red Hat 7.2. For other Linux distributions, download\n+and install ethtool from the following website:\n+http://ftp.kernel.org/pub/software/network/ethtool/.\n+\n+For instructions on enabling WoL with ethtool, refer to the website listed\n+above.\n+\n+WoL will be enabled on the system during the next shut down or reboot. For\n+this driver version, in order to enable WoL, the e1000e driver must be loaded\n+prior to shutting down or suspending the system.\n+\n+NOTE: Wake on LAN is only supported on port A for the following devices:\n+- Intel(R) PRO/1000 PT Dual Port Network Connection\n+- Intel(R) PRO/1000 PT Dual Port Server Connection\n+- Intel(R) PRO/1000 PT Dual Port Server Adapter\n+- Intel(R) PRO/1000 PF Dual Port Server Adapter\n+- Intel(R) PRO/1000 PT Quad Port Server Adapter\n+- Intel(R) Gigabit PT Quad Port Server ExpressModule\n \n- In most cases Wake On LAN is only supported on port A for multiple port\n- adapters. To verify if a port supports Wake on Lan run ethtool eth<X>.\n \n Support\n-=======\n-\n+-------\n For general information, go to the Intel support website at:\n-\n- www.intel.com/support/\n+http://www.intel.com/support/\n \n or the Intel Wired Networking project hosted by Sourceforge at:\n-\n- http://sourceforge.net/projects/e1000\n-\n-If an issue is identified with the released source code on the supported\n-kernel with a supported adapter, email the specific information related\n-to the issue to e1000-devel@lists.sf.net\n+http://sourceforge.net/projects/e1000\n+If an issue is identified with the released source code on a supported kernel\n+with a supported adapter, email the specific information related to the issue\n+to e1000-devel@lists.sf.net.\n", "prefixes": [ "v2" ] }