Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/962619/?format=api
{ "id": 962619, "url": "http://patchwork.ozlabs.org/api/patches/962619/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/patch/20180827193513.12705-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": "<20180827193513.12705-1-jeffrey.t.kirsher@intel.com>", "list_archive_url": null, "date": "2018-08-27T19:35:13", "name": "[v4] Documentation: e1000e: Update kernel documentation", "commit_ref": null, "pull_url": null, "state": "changes-requested", "archived": false, "hash": "43fb252a7c39304dbc459b27dda6e3c534ad82d0", "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/20180827193513.12705-1-jeffrey.t.kirsher@intel.com/mbox/", "series": [ { "id": 62704, "url": "http://patchwork.ozlabs.org/api/series/62704/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/list/?series=62704", "date": "2018-08-27T19:35:13", "name": "[v4] Documentation: e1000e: Update kernel documentation", "version": 4, "mbox": "http://patchwork.ozlabs.org/series/62704/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/962619/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/962619/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.137; helo=fraxinus.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 fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\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 41zhvD3jXXz9s2P\n\tfor <incoming@patchwork.ozlabs.org>;\n\tTue, 28 Aug 2018 05:35:51 +1000 (AEST)", "from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 52660848A0;\n\tMon, 27 Aug 2018 19:35:50 +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 9_NifbzpX2rk; Mon, 27 Aug 2018 19:35:47 +0000 (UTC)", "from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 514E08486F;\n\tMon, 27 Aug 2018 19:35:47 +0000 (UTC)", "from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])\n\tby ash.osuosl.org (Postfix) with ESMTP id 076F41C2051\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tMon, 27 Aug 2018 19:35:46 +0000 (UTC)", "from localhost (localhost [127.0.0.1])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id 041EB8591B\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tMon, 27 Aug 2018 19:35:46 +0000 (UTC)", "from hemlock.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id KDkllyvoJ87z for <intel-wired-lan@lists.osuosl.org>;\n\tMon, 27 Aug 2018 19:35:44 +0000 (UTC)", "from mga05.intel.com (mga05.intel.com [192.55.52.43])\n\tby hemlock.osuosl.org (Postfix) with ESMTPS id 25194858E6\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tMon, 27 Aug 2018 19:35:44 +0000 (UTC)", "from fmsmga007.fm.intel.com ([10.253.24.52])\n\tby fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t27 Aug 2018 12:35:43 -0700", "from jtkirshe-desk1.jf.intel.com ([134.134.177.59])\n\tby fmsmga007.fm.intel.com with ESMTP; 27 Aug 2018 12:35:17 -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.53,296,1531810800\"; d=\"scan'208\";a=\"65601210\"", "From": "Jeff Kirsher <jeffrey.t.kirsher@intel.com>", "To": "intel-wired-lan@lists.osuosl.org", "Date": "Mon, 27 Aug 2018 12:35:13 -0700", "Message-Id": "<20180827193513.12705-1-jeffrey.t.kirsher@intel.com>", "X-Mailer": "git-send-email 2.17.1", "Subject": "[Intel-wired-lan] [PATCH v4] 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 kernel documentation with the latest information.\nAlso remove the command line parameters, which do not exist with the\nin-kernel driver. Converted the documentation to the RST format.\n\nSigned-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>\n---\nv1/v2: initial documentation update\n\nv3: convert to RST format, remove module parameters that do not exist\n and add SPDX header\n\nv4: add back in module parameters documentation\n\n Documentation/networking/e1000e.rst | 361 ++++++++++++++++++++++++++++\n Documentation/networking/e1000e.txt | 312 ------------------------\n Documentation/networking/index.rst | 1 +\n MAINTAINERS | 2 +-\n drivers/net/ethernet/intel/Kconfig | 3 +\n 5 files changed, 366 insertions(+), 313 deletions(-)\n create mode 100644 Documentation/networking/e1000e.rst\n delete mode 100644 Documentation/networking/e1000e.txt", "diff": "diff --git a/Documentation/networking/e1000e.rst b/Documentation/networking/e1000e.rst\nnew file mode 100644\nindex 000000000000..59a989d73a7b\n--- /dev/null\n+++ b/Documentation/networking/e1000e.rst\n@@ -0,0 +1,361 @@\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) 2008-2018 Intel Corporation.\n+\n+Contents\n+========\n+\n+- Identifying Your Adapter\n+- Command Line Parameters\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+http://www.intel.com/support\n+\n+\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+ 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+\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+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 (Default=3)\n+\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+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+ - 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+\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 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+\n+This value, in units of 1.024 microseconds, limits the delay in which a\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+\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+\n+This value, in units of 1.024 microseconds, limits the delay in which a\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+\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+SmartPowerDownEnable\n+--------------------\n+Valid Range: 0-1\n+\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+\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\n+\n+ +-------+----------------+\n+ | Value | Interrupt Mode |\n+ +=======+================+\n+ | 0 | Legacy |\n+ +-------+----------------+\n+ | 1 | MSI |\n+ +-------+----------------+\n+ | 2 | MSI-X |\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+\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+\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+\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+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+\n+Alternatively, you can use the ip command as follows::\n+\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+\n+- For RHEL: /etc/sysconfig/network-scripts/ifcfg-eth<x>\n+- For SLES: /etc/sysconfig/network/<config_file>\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+\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+\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+\n+Support\n+=======\n+For general information, go to the Intel support website at:\n+\n+https://www.intel.com/support/\n+\n+or the Intel Wired Networking project hosted by Sourceforge at:\n+\n+https://sourceforge.net/projects/e1000\n+\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.\ndiff --git a/Documentation/networking/e1000e.txt b/Documentation/networking/e1000e.txt\ndeleted file mode 100644\nindex 12089547baed..000000000000\n--- a/Documentation/networking/e1000e.txt\n+++ /dev/null\n@@ -1,312 +0,0 @@\n-Linux* Driver for Intel(R) Ethernet Network Connection\n-======================================================\n-\n-Intel Gigabit Linux driver.\n-Copyright(c) 1999 - 2013 Intel Corporation.\n-\n-Contents\n-========\n-\n-- Identifying Your Adapter\n-- Command Line Parameters\n-- Additional Configurations\n-- Support\n-\n-Identifying Your Adapter\n-========================\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-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-\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-\n-RxIntDelay\n-----------\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-\n-RxAbsIntDelay\n--------------\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-\n-TxIntDelay\n-----------\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-\n-TxAbsIntDelay\n--------------\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-\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-buffer before handing it up the stack.\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-\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-\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-\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-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-\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-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-\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-\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-\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\ndiff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst\nindex 779c1f141d94..fd315630487c 100644\n--- a/Documentation/networking/index.rst\n+++ b/Documentation/networking/index.rst\n@@ -14,6 +14,7 @@ Contents:\n dpaa2/index\n e100\n e1000\n+ e1000e\n fm10k\n ixgb\n kapi\ndiff --git a/MAINTAINERS b/MAINTAINERS\nindex be1adcd6477c..89a1a53ea768 100644\n--- a/MAINTAINERS\n+++ b/MAINTAINERS\n@@ -7277,7 +7277,7 @@ T:\tgit git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git\n S:\tSupported\n F:\tDocumentation/networking/e100.rst\n F:\tDocumentation/networking/e1000.rst\n-F:\tDocumentation/networking/e1000e.txt\n+F:\tDocumentation/networking/e1000e.rst\n F:\tDocumentation/networking/fm10k.rst\n F:\tDocumentation/networking/igb.txt\n F:\tDocumentation/networking/igbvf.txt\ndiff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig\nindex 7bc5454e379e..9a10cb3b4e3c 100644\n--- a/drivers/net/ethernet/intel/Kconfig\n+++ b/drivers/net/ethernet/intel/Kconfig\n@@ -68,6 +68,9 @@ config E1000E\n \n \t <http://support.intel.com>\n \n+\t More specific information on configuring the driver is in\n+\t <file:Documentation/networking/e1000e.rst>.\n+\n \t To compile this driver as a module, choose M here. The module\n \t will be called e1000e.\n \n", "prefixes": [ "v4" ] }