Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/982047/?format=api
{ "id": 982047, "url": "http://patchwork.ozlabs.org/api/patches/982047/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/patch/20181010191613.2770-4-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": "<20181010191613.2770-4-jeffrey.t.kirsher@intel.com>", "list_archive_url": null, "date": "2018-10-10T19:16:04", "name": "[v2,03/12] Documentation: e1000e: Prepare documentation for RST conversion", "commit_ref": null, "pull_url": null, "state": "accepted", "archived": false, "hash": "1e11fd71b334882d2a5e19a1884947a96e90bd32", "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/20181010191613.2770-4-jeffrey.t.kirsher@intel.com/mbox/", "series": [ { "id": 70094, "url": "http://patchwork.ozlabs.org/api/series/70094/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/list/?series=70094", "date": "2018-10-10T19:16:01", "name": "Intel Wired LAN Documentation Updates", "version": 2, "mbox": "http://patchwork.ozlabs.org/series/70094/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/982047/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/982047/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.136; helo=silver.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=<UNKNOWN>)", "ozlabs.org;\n\tdmarc=fail (p=none dis=none) header.from=intel.com" ], "Received": [ "from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 42VkNW1vhwz9sB7\n\tfor <incoming@patchwork.ozlabs.org>;\n\tThu, 11 Oct 2018 06:16:27 +1100 (AEDT)", "from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id B0ACA2E2C5;\n\tWed, 10 Oct 2018 19:16:25 +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 9D8f2cz-rgbP; Wed, 10 Oct 2018 19:16:22 +0000 (UTC)", "from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby silver.osuosl.org (Postfix) with ESMTP id 7B28B2E4AE;\n\tWed, 10 Oct 2018 19:16:22 +0000 (UTC)", "from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\tby ash.osuosl.org (Postfix) with ESMTP id 7CFFC1BF429\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tWed, 10 Oct 2018 19:16:19 +0000 (UTC)", "from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 78B7686B22\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tWed, 10 Oct 2018 19:16:19 +0000 (UTC)", "from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id mZwHNWhAgHgG for <intel-wired-lan@lists.osuosl.org>;\n\tWed, 10 Oct 2018 19:16:17 +0000 (UTC)", "from mga06.intel.com (mga06.intel.com [134.134.136.31])\n\tby fraxinus.osuosl.org (Postfix) with ESMTPS id A5EDB86993\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tWed, 10 Oct 2018 19:16:17 +0000 (UTC)", "from orsmga003.jf.intel.com ([10.7.209.27])\n\tby orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t10 Oct 2018 12:16:16 -0700", "from jtkirshe-desk1.jf.intel.com ([134.134.177.96])\n\tby orsmga003.jf.intel.com with ESMTP; 10 Oct 2018 12:16:16 -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.54,365,1534834800\"; d=\"scan'208\";a=\"90918120\"", "From": "Jeff Kirsher <jeffrey.t.kirsher@intel.com>", "To": "intel-wired-lan@lists.osuosl.org", "Date": "Wed, 10 Oct 2018 12:16:04 -0700", "Message-Id": "<20181010191613.2770-4-jeffrey.t.kirsher@intel.com>", "X-Mailer": "git-send-email 2.17.1", "In-Reply-To": "<20181010191613.2770-1-jeffrey.t.kirsher@intel.com>", "References": "<20181010191613.2770-1-jeffrey.t.kirsher@intel.com>", "Subject": "[Intel-wired-lan] [PATCH v2 03/12] Documentation: e1000e: Prepare\n\tdocumentation for RST conversion", "X-BeenThere": "intel-wired-lan@osuosl.org", "X-Mailman-Version": "2.1.29", "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": "Before making the conversion to the rst (reStructured Text) format, there\nare changes needed to the documentation so that there are no build errors.\n\nAlso fixed old/broken URLs to the correct or updated URL.\n\nSigned-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>\n---\n Documentation/networking/e1000e.txt | 426 ++++++++++++++++------------\n 1 file changed, 248 insertions(+), 178 deletions(-)", "diff": "diff --git a/Documentation/networking/e1000e.txt b/Documentation/networking/e1000e.txt\nindex 12089547baed..33554e5416c5 100644\n--- a/Documentation/networking/e1000e.txt\n+++ b/Documentation/networking/e1000e.txt\n@@ -1,8 +1,10 @@\n+.. SPDX-License-Identifier: GPL-2.0+\n+\n 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) 2008-2018 Intel Corporation.\n \n Contents\n ========\n@@ -12,48 +14,43 @@ Contents\n - Additional Configurations\n - Support\n \n+\n Identifying Your Adapter\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+https://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+Command Line Parameters\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 \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+ modprobe e1000e [<option>=<VAL1>,<VAL2>,...]\n \n- http://support.intel.com/support/go/network/adapter/home.htm\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 \n-Command Line Parameters\n-=======================\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: A descriptor describes a data buffer and attributes related to the data\n+buffer. This information is accessed by the hardware.\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+:Valid Range: 0,1,3,4,100-100000\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+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 \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@@ -81,232 +78,305 @@ 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+ - 0: Off\n+ Turns off any interrupt moderation and may improve small packet latency.\n+ However, this is generally not suitable for bulk throughput traffic due\n+ to the increased CPU utilization of the higher interrupt rate.\n+ - 1: Dynamic mode\n+ This mode attempts to moderate interrupts per vector while maintaining\n+ very low latency. This can sometimes cause extra CPU utilization. If\n+ planning on deploying e1000e in a latency sensitive environment, this\n+ parameter should be considered.\n+ - 3: Dynamic Conservative mode (default)\n+ In dynamic conservative mode, the InterruptThrottleRate value is set to\n+ 4000 for traffic that falls in class \"Bulk traffic\". If traffic falls in\n+ the \"Low latency\" or \"Lowest latency\" class, the InterruptThrottleRate is\n+ increased stepwise to 20000. This default mode is suitable for most\n+ applications.\n+ - 4: Simplified Balancing mode\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+ - 100-100000:\n+ Setting InterruptThrottleRate to a value greater or equal to 100\n+ will program the adapter to send at most that many interrupts per second,\n+ even if more packets have come in. This reduces interrupt load on the\n+ system and can lower CPU utilization under heavy load, but will increase\n+ latency as packets are not processed as quickly.\n+\n+NOTE: 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 RxIntDelay\n ----------\n-Valid Range: 0-65535 (0=off)\n-Default Value: 0\n+:Valid Range: 0-65535 (0=off)\n+:Default Value: 0\n \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+\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+:Valid Range: 0-65535 (0=off)\n+:Default Value: 8\n \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 TxIntDelay\n ----------\n-Valid Range: 0-65535 (0=off)\n-Default Value: 8\n+:Valid Range: 0-65535 (0=off)\n+:Default Value: 8\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+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 TxAbsIntDelay\n -------------\n-Valid Range: 0-65535 (0=off)\n-Default Value: 32\n+:Valid Range: 0-65535 (0=off)\n+:Default Value: 32\n \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+copybreak\n ---------\n-Valid Range: 0-xxxxxxx (0=off)\n-Default Value: 256\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+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-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+ modprobe e1000e.ko copybreak=128\n \n SmartPowerDownEnable\n --------------------\n-Valid Range: 0-1\n-Default Value: 0 (disabled)\n+:Valid Range: 0,1\n+:Default Value: 0 (disabled)\n \n-Allows PHY to turn off in lower power states. The user can set this parameter\n-in supported chipsets.\n+Allows the PHY to turn off in lower power states. The user can turn off this\n+parameter in supported chipsets.\n \n KumeranLockLoss\n ---------------\n-Valid Range: 0-1\n-Default Value: 1 (enabled)\n+:Valid Range: 0,1\n+:Default Value: 1 (enabled)\n \n-This workaround skips resetting the PHY at shutdown for the initial\n-silicon releases of ICH8 systems.\n+This workaround skips resetting the PHY at shutdown for the initial silicon\n+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\n+:Default Value: 0\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+ | Value | Interrupt Mode |\n+ +=======+================+\n+ | 0 | Legacy |\n+ +-------+----------------+\n+ | 1 | MSI |\n+ +-------+----------------+\n+ | 2 | MSI-X |\n+ +-------+----------------+\n+\n+IntMode allows load time control over the type of interrupt registered for by\n+the driver. MSI-X is required for multiple queue support, and some kernels and\n+combinations of kernel .config options will force a lower level of interrupt\n+support.\n+\n+This command will show different values for each type of interrupt::\n+\n+ cat /proc/interrupts\n \n CrcStripping\n ------------\n-Valid Range: 0-1\n-Default Value: 1 (enabled)\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 WriteProtectNVM\n ---------------\n-Valid Range: 0,1\n-Default Value: 1\n+:Valid Range: 0,1\n+:Default Value: 1 (enabled)\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+Debug\n+-----\n+:Valid Range: 0-16 (0=none,...,16=all)\n+:Default Value: 0\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+This parameter adjusts the level of debug messages displayed in the system logs.\n+\n+\n+Additional Features and Configurations\n+======================================\n+\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- ifconfig eth<x> mtu 9000 up\n+Use the ifconfig command to increase the MTU size. For example, enter the\n+following where <x> is the interface number::\n \n- This setting is not saved across reboots.\n+ ifconfig eth<x> mtu 9000 up\n \n- Notes:\n+Alternatively, you can use the ip command as follows::\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+ ip link set mtu 9000 dev eth<x>\n+ ip link set up dev eth<x>\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+This setting is not saved across reboots. The setting change can be made\n+permanent by adding 'MTU=9000' to the file:\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+- For RHEL: /etc/sysconfig/network-scripts/ifcfg-eth<x>\n+- For SLES: /etc/sysconfig/network/<config_file>\n \n- - Jumbo Frames cannot be configured on an 82579-based Network device, if\n- MACSec is enabled on the system.\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- 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+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- https://kernel.org/pub/software/network/ethtool/\n+NOTE: The following adapters limit Jumbo Frames sized packets to a maximum of\n+4088 bytes:\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+ - Intel(R) 82578DM Gigabit Network Connection\n+ - Intel(R) 82577LM Gigabit Network Connection\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+The following adapters do not support Jumbo Frames:\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+ - 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 \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+NOTE: 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+\n+https://www.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.\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.\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 For general information, go to the Intel support website at:\n \n- www.intel.com/support/\n+https://www.intel.com/support/\n \n or the Intel Wired Networking project hosted by Sourceforge at:\n \n- http://sourceforge.net/projects/e1000\n+https://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+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", "03/12" ] }