Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/870106/?format=api
{ "id": 870106, "url": "http://patchwork.ozlabs.org/api/patches/870106/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/patch/20180206210029.27875-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": "<20180206210029.27875-1-jeffrey.t.kirsher@intel.com>", "list_archive_url": null, "date": "2018-02-06T21:00:29", "name": "[net-next] Documentation: Update Intel wired LAN docs", "commit_ref": null, "pull_url": null, "state": "changes-requested", "archived": false, "hash": "d216e54132f2453b034cf55385d28c00e5758be2", "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/20180206210029.27875-1-jeffrey.t.kirsher@intel.com/mbox/", "series": [ { "id": 27258, "url": "http://patchwork.ozlabs.org/api/series/27258/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/list/?series=27258", "date": "2018-02-06T21:00:29", "name": "[net-next] Documentation: Update Intel wired LAN docs", "version": 1, "mbox": "http://patchwork.ozlabs.org/series/27258/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/870106/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/870106/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>)", "Received": [ "from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\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 3zbcQr4NZLz9s7F\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 7 Feb 2018 08:04:36 +1100 (AEDT)", "from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id E73602F37C;\n\tTue, 6 Feb 2018 21:04:34 +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 LVJjyFW0ijQc; Tue, 6 Feb 2018 21:04:13 +0000 (UTC)", "from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby silver.osuosl.org (Postfix) with ESMTP id E0A272F3FD;\n\tTue, 6 Feb 2018 21:04:13 +0000 (UTC)", "from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\tby ash.osuosl.org (Postfix) with ESMTP id 5BD6D1C2355\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tTue, 6 Feb 2018 21:00:36 +0000 (UTC)", "from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 48E2E87A43\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tTue, 6 Feb 2018 21:00:36 +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 SM9yfJ69X3mL for <intel-wired-lan@lists.osuosl.org>;\n\tTue, 6 Feb 2018 21:00:28 +0000 (UTC)", "from mga17.intel.com (mga17.intel.com [192.55.52.151])\n\tby whitealder.osuosl.org (Postfix) with ESMTPS id 3AD0987557\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tTue, 6 Feb 2018 21:00:28 +0000 (UTC)", "from orsmga008.jf.intel.com ([10.7.209.65])\n\tby fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t06 Feb 2018 13:00:27 -0800", "from jtkirshe-nuc.jf.intel.com ([134.134.177.59])\n\tby orsmga008.jf.intel.com with ESMTP; 06 Feb 2018 13:00:26 -0800" ], "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.46,470,1511856000\"; d=\"scan'208\";a=\"16001739\"", "From": "Jeff Kirsher <jeffrey.t.kirsher@intel.com>", "To": "intel-wired-lan@lists.osuosl.org", "Date": "Tue, 6 Feb 2018 13:00:29 -0800", "Message-Id": "<20180206210029.27875-1-jeffrey.t.kirsher@intel.com>", "X-Mailer": "git-send-email 2.14.3", "MIME-Version": "1.0", "X-Mailman-Approved-At": "Tue, 06 Feb 2018 21:04:10 +0000", "Subject": "[Intel-wired-lan] [net-next] Documentation: Update Intel wired LAN\n\tdocs", "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>", "Content-Type": "text/plain; charset=\"utf-8\"", "Content-Transfer-Encoding": "base64", "Errors-To": "intel-wired-lan-bounces@osuosl.org", "Sender": "\"Intel-wired-lan\" <intel-wired-lan-bounces@osuosl.org>" }, "content": "Updated the kernel documentation on e1000e, fm10k, i40e/vf, igb/vf and\nixgbe/vf.\n\nSigned-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>\n---\n Documentation/networking/e1000e.txt | 436 ++++++++--------\n Documentation/networking/fm10k.txt | 389 +++++++++++++++\n Documentation/networking/i40e.txt | 906 +++++++++++++++++++++++++++++-----\n Documentation/networking/i40evf.txt | 354 ++++++++++++-\n Documentation/networking/igb.txt | 282 ++++++++---\n Documentation/networking/igbvf.txt | 82 +--\n Documentation/networking/ixgbe.txt | 614 ++++++++++++++---------\n Documentation/networking/ixgbevf.txt | 63 ++\n 8 files changed, 2378 insertions(+), 748 deletions(-)\n create mode 100644 Documentation/networking/fm10k.txt", "diff": "diff --git a/Documentation/networking/e1000e.txt b/Documentation/networking/e1000e.txt\nindex 12089547baed..98681a56ab1d 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) 2014-2016 Intel Corporation.\n \n Contents\n ========\n@@ -13,300 +13,310 @@ 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+Additional Features and Configurations\n+-------------------------------------------\n+\n \n- ifconfig eth<x> mtu 9000 up\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- This setting is not saved across reboots.\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- 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+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- - Using Jumbo frames at 10 or 100 Mbps is not supported and may result in\n- poor performance or loss of link.\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- - Some adapters limit Jumbo Frames sized packets to a maximum of\n- 4096 bytes and some adapters do not support Jumbo Frames.\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- - Jumbo Frames cannot be configured on an 82579-based Network device, if\n- MACSec is enabled on the system.\n+ http://ftp.kernel.org/pub/software/network/ethtool/\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+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- https://kernel.org/pub/software/network/ethtool/\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- 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+Enabling Wake on LAN* (WoL)\n+---------------------------\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+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- 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+For instructions on enabling WoL with ethtool, refer to the website listed\n+above.\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+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-Support\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-For general information, go to the Intel support website at:\n \n- www.intel.com/support/\n+Support\n+-------\n+For general information, go to the Intel support website at:\n+www.intel.com/support/\n \n or the Intel Wired Networking project hosted by Sourceforge at:\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 \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/fm10k.txt b/Documentation/networking/fm10k.txt\nnew file mode 100644\nindex 000000000000..af7d9ef529ed\n--- /dev/null\n+++ b/Documentation/networking/fm10k.txt\n@@ -0,0 +1,389 @@\n+README for Intel(R) Ethernet Multi-host Controller Driver\n+=========================================================\n+\n+February 23, 2017\n+Copyright(c) 2015-2017 Intel Corporation.\n+\n+Contents\n+========\n+- Identifying Your Adapter\n+- Additional Configurations\n+- Performance Tuning\n+- Known Issues\n+- Support\n+\n+Identifying Your Adapter\n+------------------------\n+The driver in this release is compatible with devices based on the Intel(R)\n+Ethernet Multi-host Controller.\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+SFP+ Devices with Pluggable Optics\n+----------------------------------\n+\n+82599-BASED ADAPTERS\n+--------------------\n+\n+NOTES:\n+- If your 82599-based Intel(R) Network Adapter came with Intel optics or is an\n+ Intel(R) Ethernet Server Adapter X520-2, then it only supports Intel optics\n+ and/or the direct attach cables listed below.\n+- When 82599-based SFP+ devices are connected back to back, they should be\n+ set to the same Speed setting via ethtool. Results may vary if you mix\n+ speed settings.\n+\n+Supplier\tType\t\t\t\t\tPart Numbers\n+--------\t----\t\t\t\t\t------------\n+SR Modules\n+Intel\t\tDUAL RATE 1G/10G SFP+ SR (bailed)\tFTLX8571D3BCV-IT\n+Intel\t\tDUAL RATE 1G/10G SFP+ SR (bailed)\tAFBR-703SDZ-IN2\n+Intel\t\tDUAL RATE 1G/10G SFP+ SR (bailed)\tAFBR-703SDDZ-IN1\n+LR Modules\n+Intel\t\tDUAL RATE 1G/10G SFP+ LR (bailed)\tFTLX1471D3BCV-IT\n+Intel\t\tDUAL RATE 1G/10G SFP+ LR (bailed)\tAFCT-701SDZ-IN2\n+Intel\t\tDUAL RATE 1G/10G SFP+ LR (bailed)\tAFCT-701SDDZ-IN1\n+\n+The following is a list of 3rd party SFP+ modules that have received some\n+testing. Not all modules are applicable to all devices.\n+\n+Supplier\tType\t\t\t\t\tPart Numbers\n+--------\t----\t\t\t\t\t------------\n+Finisar\t\tSFP+ SR bailed, 10g single\n+rate\t\tFTLX8571D3BCL\n+Avago\t\tSFP+ SR bailed, 10g single rate\t\tAFBR-700SDZ\n+Finisar\t\tSFP+ LR bailed, 10g single\n+rate\t\tFTLX1471D3BCL\n+Finisar\t\tDUAL RATE 1G/10G SFP+ SR (No\n+Bail)\tFTLX8571D3QCV-IT\n+Avago\t\tDUAL RATE 1G/10G SFP+ SR (No Bail)\tAFBR-703SDZ-IN1\n+Finisar\t\tDUAL RATE 1G/10G SFP+ LR (No\n+Bail)\tFTLX1471D3QCV-IT\n+Avago\t\tDUAL RATE 1G/10G SFP+ LR (No Bail)\tAFCT-701SDZ-IN1\n+\n+Finisar\t\t1000BASE-T\n+SFP\t\t\t\tFCLF8522P2BTL\n+Avago\t\t1000BASE-T\t\t\t\tABCU-5710RZ\n+HP\t\t1000BASE-SX SFP\t\t\t\t453153-001\n+\n+82599-based adapters support all passive and active limiting direct attach\n+cables that comply with SFF-8431 v4.1 and SFF-8472 v10.4 specifications.\n+\n+\n+Laser turns off for SFP+ when ifconfig ethX down\n+------------------------------------------------\n+\n+\"ifconfig ethX down\" turns off the laser for 82599-based SFP+ fiber adapters.\n+\"ifconfig ethX up\" turns on the laser.\n+Alternatively, you can use \"ip link set [down/up] dev ethX\" to turn the\n+laser off and on.\n+\n+\n+82599-based QSFP+ Adapters\n+--------------------------\n+\n+NOTES:\n+- If your 82599-based Intel(R) Network Adapter came with Intel optics, it\n+ only supports Intel optics.\n+- 82599-based QSFP+ adapters only support 4x10 Gbps connections.\n+ 1x40 Gbps connections are not supported. QSFP+ link partners must be\n+ configured for 4x10 Gbps.\n+- 82599-based QSFP+ adapters do not support automatic link speed detection.\n+ The link speed must be configured to either 10 Gbps or 1 Gbps to match the\n+ link partners speed capabilities. Incorrect speed configurations will result\n+ in failure to link.\n+- Intel(R) Ethernet Converged Network Adapter X520-Q1 only supports the\n+ optics and direct attach cables listed below.\n+\n+\n+Supplier\tType\t\t\t\tPart Numbers\n+--------\t----\t\t\t\t------------\n+Intel\tDUAL RATE 1G/10G QSFP+ SRL (bailed)\tE10GQSFPSR\n+\n+82599-based QSFP+ adapters support all passive and active limiting QSFP+\n+direct attach cables that comply with SFF-8436 v4.1 specifications.\n+\n+\n+82598-BASED ADAPTERS\n+--------------------\n+\n+NOTES:\n+- Intel(r) Ethernet Network Adapters that support removable optical modules\n+ only support their original module type (for example, the Intel(R) 10 Gigabit\n+ SR Dual Port Express Module only supports SR optical modules). If you plug\n+ in a different type of module, the driver will not load.\n+- Hot Swapping/hot plugging optical modules is not supported.\n+- Only single speed, 10 gigabit modules are supported.\n+- LAN on Motherboard (LOMs) may support DA, SR, or LR modules. Other module\n+ types are not supported. Please see your system documentation for details.\n+\n+ The following is a list of SFP+ modules and direct attach cables that have\n+ received some testing. Not all modules are applicable to all devices.\n+\n+Supplier\tType\t\t\t\t\tPart Numbers\n+--------\t----\t\t\t\t\t------------\n+Finisar\t\tSFP+ SR bailed, 10g single\n+rate\t\tFTLX8571D3BCL\n+Avago\t\tSFP+ SR bailed, 10g single rate\t\tAFBR-700SDZ\n+Finisar\t\tSFP+ LR bailed, 10g single\n+rate\t\tFTLX1471D3BCL\n+\n+82598-based adapters support all passive direct attach cables that comply with\n+SFF-8431 v4.1 and SFF-8472 v10.4 specifications. Active direct attach cables\n+are not supported.\n+\n+Third party optic modules and cables referred to above are listed only for the\n+purpose of highlighting third party specifications and potential\n+compatibility, and are not recommendations or endorsements or sponsorship of\n+any third party's product by Intel. Intel is not endorsing or promoting\n+products made by any third party and the third party reference is provided\n+only to share information regarding certain optic modules and cables with the\n+above specifications. There may be other manufacturers or suppliers, producing\n+or supplying optic modules and cables with similar or matching descriptions.\n+Customers must use their own discretion and diligence to purchase optic\n+modules and cables from any third party of their choice. Customers are solely\n+responsible for assessing the suitability of the product and/or devices and\n+for the selection of the vendor for purchasing any product. THE OPTIC MODULES\n+AND CABLES REFERRED TO ABOVE ARE NOT WARRANTED OR SUPPORTED BY INTEL. INTEL\n+ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED\n+WARRANTY, RELATING TO SALE AND/OR USE OF SUCH THIRD PARTY PRODUCTS OR\n+SELECTION OF VENDOR BY CUSTOMERS.\n+\n+\n+Flow Control\n+------------\n+The Intel(R) Ethernet Switch Host Interface Driver does not support Flow\n+Control. It will not send pause frames. This may result in dropped frames.\n+\n+\n+Intel(R) Ethernet Flow Director\n+-------------------------------\n+The Intel Ethernet Flow Director performs the following tasks:\n+\n+- Directs receive packets according to their flows to different queues.\n+- Enables tight control on routing a flow in the platform.\n+- Matches flows and CPU cores for flow affinity.\n+- Supports multiple parameters for flexible flow classification and load\n+ balancing (in SFP mode only).\n+\n+NOTE: An included script (set_irq_affinity) automates setting the IRQ to CPU\n+affinity.\n+\n+ethtool commands:\n+\n+To enable or disable the Intel Ethernet Flow Director:\n+\n+ # ethtool -K ethX ntuple <on|off>\n+\n+When disabling ntuple filters, all the user programed filters are flushed from\n+the driver cache and hardware. All needed filters must be re-added when ntuple\n+is re-enabled.\n+\n+To add a filter that directs packet to queue 2, use -U or -N switch:\n+\n+ # ethtool -N ethX flow-type tcp4 src-ip 192.168.10.1 dst-ip \\\n+ 192.168.10.2 src-port 2000 dst-port 2001 action 2 [loc 1]\n+\n+To see the list of filters currently present:\n+ # ethtool <-u|-n> ethX\n+\n+\n+FdirPballoc\n+-----------\n+Valid Range: 1-3\n+Specifies the Flow Director allocated packet buffer size.\n+1 = 64k\n+2 = 128k\n+3 = 256k\n+\n+\n+AtrSampleRate\n+-------------\n+Valid Range: 0-255\n+This parameter is used with the Flow Director and is the software ATR transmit\n+packet sample rate. For example, when AtrSampleRate is set to 20, every 20th\n+packet looks to see if the packet will create a new flow. A value of 0\n+indicates that ATR should be disabled and no samples will be taken.\n+\n+\n+Node\n+----\n+Valid Range: 0-n\n+0 - n: where n is the number of the NUMA node that should be used to allocate\n+memory for this adapter port.\n+-1: uses the driver default of allocating memory on whichever processor is\n+running modprobe.\n+The Node parameter allows you to choose which NUMA node you want to have the\n+adapter allocate memory from. All driver structures, in-memory queues, and\n+receive buffers will be allocated on the node specified. This parameter is\n+only useful when interrupt affinity is specified; otherwise, part of the\n+interrupt time could run on a different core than where the memory is\n+allocated causing slower memory access and impacting throughput, CPU, or both.\n+\n+\n+max_vfs\n+-------\n+This parameter adds support for SR-IOV. It causes the driver to spawn up to\n+max_vfs worth of virtual functions.\n+Valid Range:0-64\n+\n+NOTE: This parameter is only used on kernel 3.7.x and below. On kernel 3.8.x\n+and above, use sysfs to enable VFs. Also, for Red Hat distributions, this\n+parameter is only used on version 6.6 and older. For version 6.7 and newer, use\n+sysfs. For example:\n+#echo $num_vf_enabled > /sys/class/net/$dev/device/sriov_numvfs\t//enable\n+VFs\n+#echo 0 > /sys/class/net/$dev/device/sriov_numvfs\t//disable VFs\n+\n+The parameters for the driver are referenced by position. Thus, if you have a\n+dual port adapter, or more than one adapter in your system, and want N virtual\n+functions per port, you must specify a number for each port with each parameter\n+separated by a comma. For example:\n+\n+ modprobe fm10k max_vfs=4\n+\n+This will spawn 4 VFs on the first port.\n+\n+ modprobe fm10k max_vfs=2,4\n+\n+This will spawn 2 VFs on the first port and 4 VFs on the second port.\n+\n+NOTE: Caution must be used in loading the driver with these parameters.\n+Depending on your system configuration, number of slots, etc., it is impossible\n+to predict in all cases where the positions would be on the command line.\n+\n+NOTE: Neither the device nor the driver control how VFs are mapped into config\n+space. Bus layout will vary by operating system. On operating systems that\n+support it, you can check sysfs to find the mapping.\n+\n+\n+NOTE: When SR-IOV mode is enabled, hardware VLAN filtering and VLAN tag\n+stripping/insertion will remain enabled. Please remove the old VLAN filter\n+before the new VLAN filter is added. For example,\n+ip link set eth0 vf 0 vlan 100\t// set vlan 100 for VF 0\n+ip link set eth0 vf 0 vlan 0\t// Delete vlan 100\n+ip link set eth0 vf 0 vlan 200\t// set a new vlan 200 for VF 0\n+\n+\n+Additional Features and Configurations\n+-------------------------------------------\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+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 15342. This value coincides\n+with the maximum Jumbo Frames size of 15364 bytes.\n+\n+NOTE: This driver will attempt to use multiple page sized buffers to receive\n+each jumbo packet. This should help to avoid buffer starvation issues when\n+allocating receive packets.\n+\n+\n+Generic Receive Offload, aka GRO\n+--------------------------------\n+\n+The driver supports the in-kernel software implementation of GRO. GRO has\n+shown that by coalescing Rx traffic into larger chunks of data, CPU\n+utilization can be significantly reduced when under large Rx load. GRO is an\n+evolution of the previously-used LRO interface. GRO is able to coalesce\n+other protocols besides TCP. It's also safe to use with configurations that\n+are problematic for LRO, namely bridging and iSCSI.\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+Supported ethtool Commands and Options for Filtering\n+----------------------------------------------------\n+-n --show-nfc\n+ Retrieves the receive network flow classification configurations.\n+\n+rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6\n+ Retrieves the hash options for the specified network traffic type.\n+\n+-N --config-nfc\n+ Configures the receive network flow classification.\n+\n+rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6\n+m|v|t|s|d|f|n|r...\n+ Configures the hash options for the specified network traffic type.\n+\n+ udp4 UDP over IPv4\n+ udp6 UDP over IPv6\n+\n+ f Hash on bytes 0 and 1 of the Layer 4 header of the rx packet.\n+ n Hash on bytes 2 and 3 of the Layer 4 header of the rx packet.\n+\n+\n+FCoE\n+----\n+\n+This release of the fm10k driver contains new code to enable users to use\n+Fiber Channel over Ethernet (FCoE) and Data Center Bridging (DCB)\n+functionality that is supported by the 82598-based hardware. This code has\n+no default effect on the regular driver operation, and configuring DCB and\n+FCoE is outside the scope of this driver README. Refer to\n+http://www.open-fcoe.org/ for FCoE project information and contact\n+fm10k-eedc@lists.sourceforge.net for DCB information.\n+\n+\n+MAC and VLAN anti-spoofing feature\n+----------------------------------\n+\n+When a malicious driver attempts to send a spoofed packet, it is dropped by the\n+hardware and not transmitted.\n+\n+An interrupt is sent to the PF driver notifying it of the spoof attempt. When a\n+spoofed packet is detected, the PF driver will send the following message to\n+the system log (displayed by the \"dmesg\" command):\n+NOTE: This feature can be disabled for a specific Virtual Function (VF):\n+ip link set <pf dev> vf <vf id> spoofchk {off|on}\n+\n+\n+Known Issues/Troubleshooting\n+----------------------------\n+\n+\n+Enabling SR-IOV in a 64-bit Microsoft* Windows Server* 2012/R2 guest OS under\n+Linux KVM\n+--------------------------------------------------------------------------------\n+KVM Hypervisor/VMM supports direct assignment of a PCIe device to a VM. This\n+includes traditional PCIe devices, as well as SR-IOV-capable devices based on\n+the Intel Ethernet Controller XL710.\n+\n+\n+Support\n+-------\n+For general information, go to the Intel support website at:\n+www.intel.com/support/\n+\n+or the Intel Wired Networking project hosted by Sourceforge at:\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+\n+\ndiff --git a/Documentation/networking/i40e.txt b/Documentation/networking/i40e.txt\nindex 57e616ed10b0..511098eee5ec 100644\n--- a/Documentation/networking/i40e.txt\n+++ b/Documentation/networking/i40e.txt\n@@ -1,190 +1,836 @@\n-Linux Base Driver for the Intel(R) Ethernet Controller XL710 Family\n-===================================================================\n \n-Intel i40e Linux driver.\n-Copyright(c) 2013 Intel Corporation.\n+i40e Linux* Base Driver for the Intel(R) Ethernet Controller 700 Series\n+===============================================================================\n+\n+November 28, 2017\n+\n+===============================================================================\n \n Contents\n-========\n+--------\n \n+- Overview\n - Identifying Your Adapter\n-- Additional Configurations\n-- Performance Tuning\n-- Known Issues\n-- Support\n+- Intel(R) Ethernet Flow Director\n+- Additional Features & Configurations\n+\n+\n+================================================================================\n+\n+\n+TC0 must be enabled when setting up DCB on a switch\n+---------------------------------------------------\n+The kernel assumes that TC0 is available, and will disable Priority Flow\n+Control (PFC) on the device if TC0 is not available. To fix this, ensure TC0 is\n+enabled when setting up DCB on your switch.\n+\n+\n+This driver supports kernel versions 2.6.32 and newer.\n+\n+Driver information can be obtained using ethtool, lspci, and ifconfig.\n+Instructions on updating ethtool can be found in the section Additional\n+Configurations later in this document.\n+\n+For questions related to hardware requirements, refer to the documentation\n+supplied with your Intel adapter. All hardware requirements listed apply to use\n+with Linux.\n+\n+NOTE: 1 Gb devices based on the Intel(R) Ethernet Network Connection X722 do\n+not support the following features:\n+ * Data Center Bridging (DCB)\n+ * QOS\n+ * VMQ\n+ * SR-IOV\n+ * Task Encapsulation offload (VXLAN, NVGRE)\n+ * Energy Efficient Ethernet (EEE)\n+ * Auto-media detect\n \n \n Identifying Your Adapter\n-========================\n+------------------------\n+The driver in this release is compatible with devices based on the following:\n+ * Intel(R) Ethernet Controller X710\n+ * Intel(R) Ethernet Controller XL710\n+ * Intel(R) Ethernet Network Connection X722\n+ * Intel(R) Ethernet Controller XXV710\n+\n+For the best performance, make sure the latest NVM/FW is installed on your\n+device and that you are using the newest drivers.\n+\n+For information on how to identify your adapter, and for the latest NVM/FW\n+images and Intel network drivers, refer to the Intel Support website:\n+http://www.intel.com/support\n+\n+\n+SFP+ and QSFP+ Devices:\n+-----------------------\n+For information about supported media, refer to this document:\n+http://www.intel.com/content/dam/www/public/us/en/documents/release-notes/xl710-\n+ethernet-controller-feature-matrix.pdf\n+NOTE: Some adapters based on the Intel(R) Ethernet Controller 700 Series only\n+support Intel Ethernet Optics modules. On these adapters, other modules are not\n+supported and will not function.\n+\n+NOTE: For connections based on Intel(R) Ethernet Controller 700 Series, support\n+is dependent on your system board. Please see your vendor for details.\n+\n+NOTE:In all cases Intel recommends using Intel Ethernet Optics; other modules\n+may function but are not validated by Intel. Contact Intel for supported media\n+types.\n+\n+NOTE: In systems that do not have adequate airflow to cool the adapter and\n+optical modules, you must use high temperature optical modules.\n+\n+\n+================================================================================\n+\n+\n+Use sysfs to enable VFs. For example:\n+#echo $num_vf_enabled > /sys/class/net/$dev/device/sriov_numvfs\t//enable\n+VFs\n+#echo 0 > /sys/class/net/$dev/device/sriov_numvfs\t//disable VFs\n+\n+NOTE: Neither the device nor the driver control how VFs are mapped into config\n+space. Bus layout will vary by operating system. On operating systems that\n+support it, you can check sysfs to find the mapping.\n+Some hardware configurations support fewer SR-IOV instances, as the whole\n+XL710 controller (all functions) is limited to 128 SR-IOV interfaces in total.\n+NOTE: When SR-IOV mode is enabled, hardware VLAN\n+filtering and VLAN tag stripping/insertion will remain enabled. Please remove\n+the old VLAN filter before the new VLAN filter is added. For example,\n+ip link set eth0 vf 0 vlan 100\t// set vlan 100 for VF 0\n+ip link set eth0 vf 0 vlan 0\t// Delete vlan 100\n+ip link set eth0 vf 0 vlan 200\t// set a new vlan 200 for VF 0\n+\n+\n+Configuring SR-IOV for improved network security\n+------------------------------------------------\n+In a virtualized environment, on Intel(R) Ethernet Server Adapters that support\n+SR-IOV, the virtual function (VF) may be subject to malicious behavior.\n+Software-generated layer two frames, like IEEE 802.3x (link flow control), IEEE\n+802.1Qbb (priority based flow-control), and others of this type, are not\n+expected and can throttle traffic between the host and the virtual switch,\n+reducing performance. To resolve this issue, configure all SR-IOV enabled ports\n+for VLAN tagging. This configuration allows unexpected, and potentially\n+malicious, frames to be dropped.\n+\n+\n+Configuring VLAN tagging on SR-IOV enabled adapter ports\n+--------------------------------------------------------\n+To configure VLAN tagging for the ports on an SR-IOV enabled adapter, use the\n+following command. The VLAN configuration should be done before the VF driver\n+is loaded or the VM is booted.\n+\n+$ ip link set dev <PF netdev id> vf <id> vlan <vlan id>\n+\n+For example, the following instructions will configure PF eth0 and the first VF\n+on VLAN 10.\n+$ ip link set dev eth0 vf 0 vlan 10\n+\n+\n+VLAN Tag Packet Steering\n+------------------------\n+Allows you to send all packets with a specific VLAN tag to a particular SR-IOV\n+virtual function (VF). Further, this feature allows you to designate a\n+particular VF as trusted, and allows that trusted VF to request selective\n+promiscuous mode on the Physical Function (PF).\n+\n+To set a VF as trusted or untrusted, enter the following command in the\n+Hypervisor:\n+ # ip link set dev eth0 vf 1 trust [on|off]\n+\n+Once the VF is designated as trusted, use the following commands in the VM to\n+set the VF to promiscuous mode.\n+ For promiscuous all:\n+ #ip link set eth2 promisc on\n+ Where eth2 is a VF interface in the VM\n+ For promiscuous Multicast:\n+ #ip link set eth2 allmulticast on\n+ Where eth2 is a VF interface in the VM\n+\n+NOTE: By default, the ethtool priv-flag vf-true-promisc-support is set to\n+\"off\",meaning that promiscuous mode for the VF will be limited. To set the\n+promiscuous mode for the VF to true promiscuous and allow the VF to see all\n+ingress traffic, use the following command.\n+ #ethtool -set-priv-flags p261p1 vf-true-promisc-support on\n+The vf-true-promisc-support priv-flag does not enable promiscuous mode; rather,\n+it designates which type of promiscuous mode (limited or true) you will get\n+when you enable promiscuous mode using the ip link commands above. Note that\n+this is a global setting that affects the entire device. However,the\n+vf-true-promisc-support priv-flag is only exposed to the first PF of the\n+device. The PF remains in limited promiscuous mode (unless it is in MFP mode)\n+regardless of the vf-true-promisc-support setting.\n+\n+Now add a VLAN interface on the VF interface.\n+ #ip link add link eth2 name eth2.100 type vlan id 100\n+\n+Note that the order in which you set the VF to promiscuous mode and add the\n+VLAN interface does not matter (you can do either first). The end result in\n+this example is that the VF will get all traffic that is tagged with VLAN 100.\n+\n+\n+Enabling a VF link if the port is disconnected\n+----------------------------------------------\n+If the physical function (PF) link is down, you can force link up (from the\n+host PF) on any virtual functions (VF) bound to the PF. Note that this requires\n+kernel support (Redhat kernel 3.10.0-327 or newer, upstream kernel 3.11.0 or\n+newer, and associated iproute2 user space support). If the following command\n+does not work, it may not be supported by your system. The following command\n+forces link up on VF 0 bound to PF eth0:\n+ ip link set eth0 vf 0 state enable\n+\n+\n+Do not unload port driver if VF with active VM is bound to it\n+-------------------------------------------------------------\n+Do not unload a port's driver if a Virtual Function (VF) with an active Virtual\n+Machine (VM) is bound to it. Doing so will cause the port to appear to hang.\n+Once the VM shuts down, or otherwise releases the VF, the command will complete.\n+\n+\n+Intel(R) Ethernet Flow Director\n+-------------------------------\n+The Intel Ethernet Flow Director performs the following tasks:\n+\n+- Directs receive packets according to their flows to different queues.\n+- Enables tight control on routing a flow in the platform.\n+- Matches flows and CPU cores for flow affinity.\n+- Supports multiple parameters for flexible flow classification and load\n+ balancing (in SFP mode only).\n+\n+NOTE: An included script (set_irq_affinity) automates setting the IRQ to CPU\n+affinity.\n+\n+NOTE: The Linux i40edriver supports the following flow types: IPv4, TCPv4, and\n+UDPv4. For a given flow type, it supports valid combinations of IP addresses\n+(source or destination) and UDP/TCP ports (source and destination). For\n+example, you can supply only a source IP address, a source IP address and a\n+destination port, or any combination of one or more of these four parameters.\n+\n+NOTE: The Linux i40edriver allows you to filter traffic based on a user-defined\n+flexible two-byte pattern and offset by using the ethtool user-def and mask\n+fields. Only L3 and L4 flow types are supported for user-defined flexible\n+filters. For a given flow type, you must clear all Intel Ethernet Flow Director\n+filters before changing the input set (for that flow type).\n+\n+ethtool commands:\n+\n+To enable or disable the Intel Ethernet Flow Director:\n+\n+ # ethtool -K ethX ntuple <on|off>\n+\n+When disabling ntuple filters, all the user programed filters are flushed from\n+the driver cache and hardware. All needed filters must be re-added when ntuple\n+is re-enabled.\n+\n+To add a filter that directs packet to queue 2, use -U or -N switch:\n+\n+ # ethtool -N ethX flow-type tcp4 src-ip 192.168.10.1 dst-ip \\\n+ 192.168.10.2 src-port 2000 dst-port 2001 action 2 [loc 1]\n+\n+To set a filter using only the source and destination IP address:\n+\n+ # ethtool -N ethX flow-type tcp4 src-ip 192.168.10.1 dst-ip \\\n+ 192.168.10.2 action 2 [loc 1]\n+\n+To set a filter based on a user defined pattern and offset:\n+\n+ # ethtool -N ethX flow-type tcp4 src-ip 192.168.10.1 dst-ip \\\n+ 192.168.10.2 user-def 0xffffffff00000001 m 0x40 action 2 [loc 1]\n+\n+ where the value of the user-def field (0xffffffff00000001) is the\n+ pattern and m 0x40 is the offset.\n+\n+Note that in this case the mask (m 0x40) parameter is used with the user-def\n+field, whereas for cloud filter support the mask parameter is not used.\n+\n+To see the list of filters currently present:\n+ # ethtool <-u|-n> ethX\n+\n+Application Targeted Routing (ATR) Perfect Filters\n+--------------------------------------------------\n+ATR is enabled by default when the kernel is in multiple transmit queue mode.\n+An ATR Intel Ethernet Flow Director filter rule is added when a TCP-IP flow\n+starts and is deleted when the flow ends. When a TCP-IP Intel Ethernet Flow\n+Director rule is added from ethtool (Sideband filter), ATR is turned off by the\n+driver. To re-enable ATR, the sideband can be disabled with the ethtool -K\n+option. If sideband is re-enabled after ATR is re-enabled, ATR remains enabled\n+until a TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR\n+is automatically re-enabled.\n+\n+Packets that match the ATR rules are counted in fdir_atr_match stats in\n+ethtool, which also can be used to verify whether ATR rules still exist.\n+\n+Sideband Perfect Filters\n+------------------------\n+Sideband Perfect Filters are used to direct traffic that matches specified\n+characteristics. They are enabled through ethtool's ntuple interface. To add a\n+new filter use the following command:\n+ ethtool -U <device> flow-type <type> src-ip <ip> dst-ip <ip> src-port <port>\n+dst-port <port> action <queue>\n+Where:\n+ <device> - the ethernet device to program\n+ <type> - can be ip4, tcp4, udp4, or sctp4\n+ <ip> - the ip address to match on\n+ <port> - the port number to match on\n+ <queue> - the queue to direct traffic towards (-1 discards the matched\n+traffic)\n+Use the following command to display all of the active filters:\n+ ethtool -u <device>\n+Use the following command to delete a filter:\n+ ethtool -U <device> delete <N>\n+Where <N> is the filter id displayed when printing all the active filters, and\n+may also have been specified using \"loc <N>\" when adding the filter.\n+\n+The following example matches TCP traffic sent from 192.168.0.1, port 5300,\n+directed to 192.168.0.5, port 80, and sends it to queue 7:\n+ ethtool -U enp130s0 flow-type tcp4 src-ip 192.168.0.1 dst-ip 192.168.0.5\n+ src-port 5300 dst-port 7 action 7\n+\n+For each flow-type, the programmed filters must all have the same matching\n+input set. For example, issuing the following two commands is acceptable:\n+ ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.1 src-port 5300 action 7\n+ ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.5 src-port 55 action 10\n+Issuing the next two commands, however, is not acceptable, since the first\n+specifies src-ip and the second specifies dst-ip:\n+ ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.1 src-port 5300 action 7\n+ ethtool -U enp130s0 flow-type ip4 dst-ip 192.168.0.5 src-port 55 action 10\n+The second command will fail with an error. You may program multiple filters\n+with the same fields, using different values, but, on one device, you may not\n+program two tcp4 filters with different matching fields.\n+\n+Matching on a sub-portion of a field is not supported by the i40edriver, thus\n+partial mask fields are not supported.\n+\n+The driver also supports matching user-defined data within the packet payload.\n+This flexible data is specified using the \"user-def\" field of the ethtool\n+command in the following way:\n++----------------------------+--------------------------+\n+| 31 28 24 20 16 | 15 12 8 4 0 |\n++----------------------------+--------------------------+\n+| offset into packet payload | 2 bytes of flexible data |\n++----------------------------+--------------------------+\n+\n+For example,\n+ ... user-def 0x4FFFF ...\n+\n+tells the filter to look 4 bytes into the payload and match that value against\n+0xFFFF. The offset is based on the beginning of the payload, and not the\n+beginning of the packet. Thus\n+\n+ flow-type tcp4 ... user-def 0x8BEAF ...\n+\n+would match TCP/IPv4 packets which have the value 0xBEAF 8 bytes into the\n+TCP/IPv4 payload.\n+\n+Note that ICMP headers are parsed as 4 bytes of header and 4 bytes of payload.\n+Thus to match the first byte of the payload, you must actually add 4 bytes to\n+the offset. Also note that ip4 filters match both ICMP frames as well as raw\n+(unknown) ip4 frames, where the payload will be the L3 payload of the IP4 frame.\n+\n+The maximum offset is 64. The hardware will only read up to 64 bytes of data\n+from the payload. The offset must be even because the flexible data is 2 bytes\n+long and must be aligned to byte 0 of the packet payload.\n+\n+The user-defined flexible offset is also considered part of the input set and\n+cannot be programmed separately for multiple filters of the same type. However,\n+the flexible data is not part of the input set and multiple filters may use the\n+same offset but match against different data.\n+\n+To create filters that direct traffic to a specific Virtual Function, use the\n+\"action\" parameter. Specify the action as a 64 bit value, where the lower 32\n+bits represents the queue number, while the next 8 bits represent which VF.\n+Note that 0 is the PF, so the VF identifier is offset by 1. For example:\n+\n+ ... action 0x800000002 ...\n+\n+specifies to direct traffic to Virtual Function 7 (8 minus 1) into queue 2 of\n+that VF.\n+\n+Note that these filters will not break internal routing rules, and will not\n+route traffic that otherwise would not have been sent to the specified Virtual\n+Function.\n+\n+\n+Additional Features and Configurations\n+-------------------------------------------\n+\n+\n+Setting the link-down-on-close Private Flag\n+-------------------------------------------\n+When the link-down-on-close private flag is set to \"on\", the port's link will\n+go down when the interface is brought down using the ifconfig ethX down command.\n+\n+Use ethtool to view and set link-down-on-close, as follows:\n+ ethtool --show-priv-flags ethX\n+ ethtool --set-priv-flags ethX link-down-on-close [on|off]\n+\n+\n+Viewing Link Messages\n+---------------------\n+Link messages will not be displayed to the console if the distribution is\n+restricting system messages. In order to see network driver link messages on\n+your console, set dmesg to eight by entering the following:\n+dmesg -n 8\n+\n+NOTE: This setting is not saved across reboots.\n \n-The driver in this release is compatible with the Intel Ethernet\n-Controller XL710 Family.\n \n-For more information on how to identify your adapter, go to the Adapter &\n-Driver ID Guide at:\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- http://support.intel.com/support/network/sb/CS-012904.htm\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-Enabling the driver\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-The driver is enabled via the standard kernel configuration system,\n-using the make command:\n+NOTE: The maximum MTU setting for Jumbo Frames is 9702. This value coincides\n+with the maximum Jumbo Frames size of 9728 bytes.\n \n- Make oldconfig/silentoldconfig/menuconfig/etc.\n+NOTE: This driver will attempt to use multiple page sized buffers to receive\n+each jumbo packet. This should help to avoid buffer starvation issues when\n+allocating receive packets.\n \n-The driver is located in the menu structure at:\n \n-\t-> Device Drivers\n-\t -> Network device support (NETDEVICES [=y])\n-\t -> Ethernet driver support\n-\t -> Intel devices\n-\t -> Intel(R) Ethernet Controller XL710 Family\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-Additional Configurations\n-=========================\n+Supported ethtool Commands and Options for Filtering\n+----------------------------------------------------\n+-n --show-nfc\n+ Retrieves the receive network flow classification configurations.\n \n- Generic Receive Offload (GRO)\n- -----------------------------\n- The driver supports the in-kernel software implementation of GRO. GRO has\n- shown that by coalescing Rx traffic into larger chunks of data, CPU\n- utilization can be significantly reduced when under large Rx load. GRO is\n- an evolution of the previously-used LRO interface. GRO is able to coalesce\n- other protocols besides TCP. It's also safe to use with configurations that\n- are problematic for LRO, namely bridging and iSCSI.\n+rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6\n+ Retrieves the hash options for the specified network traffic type.\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\n- ethtool version is required for this functionality.\n+-N --config-nfc\n+ Configures the receive network flow classification.\n \n- The latest release of ethtool can be found from\n- https://www.kernel.org/pub/software/network/ethtool\n+rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6\n+m|v|t|s|d|f|n|r...\n+ Configures the hash options for the specified network traffic type.\n \n+ udp4 UDP over IPv4\n+ udp6 UDP over IPv6\n \n- Flow Director n-ntuple traffic filters (FDir)\n- ---------------------------------------------\n- The driver utilizes the ethtool interface for configuring ntuple filters,\n- via \"ethtool -N <device> <filter>\".\n+ f Hash on bytes 0 and 1 of the Layer 4 header of the rx packet.\n+ n Hash on bytes 2 and 3 of the Layer 4 header of the rx packet.\n \n- The sctp4, ip4, udp4, and tcp4 flow types are supported with the standard\n- fields including src-ip, dst-ip, src-port and dst-port. The driver only\n- supports fully enabling or fully masking the fields, so use of the mask\n- fields for partial matches is not supported.\n \n- Additionally, the driver supports using the action to specify filters for a\n- Virtual Function. You can specify the action as a 64bit value, where the\n- lower 32 bits represents the queue number, while the next 8 bits represent\n- which VF. Note that 0 is the PF, so the VF identifier is offset by 1. For\n- example:\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- ... action 0x800000002 ...\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- Would indicate to direct traffic for Virtual Function 7 (8 minus 1) on queue\n- 2 of that VF.\n+NOTE: You cannot set the speed for devices based on the Intel(R) Ethernet\n+Network Adapter XXV710 based devices.\n \n- The driver also supports using the user-defined field to specify 2 bytes of\n- arbitrary data to match within the packet payload in addition to the regular\n- fields. The data is specified in the lower 32bits of the user-def field in\n- the following way:\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- +----------------------------+---------------------------+\n- | 31 28 24 20 16 | 15 12 8 4 0|\n- +----------------------------+---------------------------+\n- | offset into packet payload | 2 bytes of flexible data |\n- +----------------------------+---------------------------+\n+ http://ftp.kernel.org/pub/software/network/ethtool/\n \n- As an example,\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- ... user-def 0x4FFFF ....\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- means to match the value 0xFFFF 4 bytes into the packet payload. Note that\n- the offset is based on the beginning of the payload, and not the beginning\n- of the packet. Thus\n \n- flow-type tcp4 ... user-def 0x8BEAF ....\n+NAPI\n+----\n+NAPI (Rx polling mode) is supported in the i40e driver.\n+For more information on NAPI, see\n+https://www.linuxfoundation.org/collaborate/workgroups/networking/napi\n \n- would match TCP/IPv4 packets which have the value 0xBEAF 8bytes into the\n- TCP/IPv4 payload.\n \n- For ICMP, the hardware parses the ICMP header as 4 bytes of header and 4\n- bytes of payload, so if you want to match an ICMP frames payload you may need\n- to add 4 to the offset in order to match the data.\n+Flow Control\n+------------\n+Ethernet Flow Control (IEEE 802.3x) can be configured with ethtool to enable\n+receiving and transmitting pause frames for i40e. When transmit is enabled,\n+pause frames are generated when the receive packet buffer crosses a predefined\n+threshold. When receive is enabled, the transmit unit will halt for the time\n+delay specified when a pause frame is received.\n \n- Furthermore, the offset can only be up to a value of 64, as the hardware\n- will only read up to 64 bytes of data from the payload. It must also be even\n- as the flexible data is 2 bytes long and must be aligned to byte 0 of the\n- packet payload.\n+NOTE: You must have a flow control capable link partner.\n \n- When programming filters, the hardware is limited to using a single input\n- set for each flow type. This means that it is an error to program two\n- different filters with the same type that don't match on the same fields.\n- Thus the second of the following two commands will fail:\n+Flow Control is by default.\n \n- ethtool -N <device> flow-type tcp4 src-ip 192.168.0.7 action 5\n- ethtool -N <device> flow-type tcp4 dst-ip 192.168.15.18 action 1\n+Use ethtool to change the flow control settings.\n \n- This is because the first filter will be accepted and reprogram the input\n- set for TCPv4 filters, but the second filter will be unable to reprogram the\n- input set until all the conflicting TCPv4 filters are first removed.\n+To enable or disable rx or tx Flow Control:\n+ethtool -A eth? rx <on|off> tx <on|off>\n+Note: This command only enables or disables Flow Control if auto-negotiation is\n+disabled. If auto-negotiation is enabled, this command changes the parameters\n+used for auto-negotiation with the link partner.\n \n- Note that the user-defined flexible offset is also considered part of the\n- input set and cannot be programmed separately for multiple filters of the\n- same type. However, the flexible data is not part of the input set and\n- multiple filters may use the same offset but match against different data.\n+To enable or disable auto-negotiation:\n+ethtool -s eth? autoneg <on|off>\n+Note: Flow Control auto-negotiation is part of link auto-negotiation. Depending\n+on your device, you may not be able to change the auto-negotiation setting.\n \n- Data Center Bridging (DCB)\n- --------------------------\n- DCB configuration is not currently supported.\n \n- FCoE\n- ----\n- The driver supports Fiber Channel over Ethernet (FCoE) and Data Center\n- Bridging (DCB) functionality. Configuring DCB and FCoE is outside the scope\n- of this driver doc. Refer to http://www.open-fcoe.org/ for FCoE project\n- information and http://www.open-lldp.org/ or email list\n- e1000-eedc@lists.sourceforge.net for DCB information.\n+RSS Hash Flow\n+-------------\n \n- MAC and VLAN anti-spoofing feature\n- ----------------------------------\n- When a malicious driver attempts to send a spoofed packet, it is dropped by\n- the hardware and not transmitted. An interrupt is sent to the PF driver\n- notifying it of the spoof attempt.\n+Allows you to set the hash bytes per flow type and any combination of one or\n+more options for Receive Side Scaling (RSS) hash byte configuration.\n \n- When a spoofed packet is detected the PF driver will send the following\n- message to the system log (displayed by the \"dmesg\" command):\n+#ethtool -N <dev> rx-flow-hash <type> <option>\n \n- Spoof event(s) detected on VF (n)\n+Where <type> is:\n+ tcp4\tsignifying TCP over IPv4\n+ udp4\tsignifying UDP over IPv4\n+ tcp6\tsignifying TCP over IPv6\n+ udp6\tsignifying UDP over IPv6\n+And <option> is one or more of:\n+ s\tHash on the IP source address of the rx packet.\n+ d\tHash on the IP destination address of the rx packet.\n+ f\tHash on bytes 0 and 1 of the Layer 4 header of the rx packet.\n+ n\tHash on bytes 2 and 3 of the Layer 4 header of the rx packet.\n \n- Where n=the VF that attempted to do the spoofing.\n \n+MAC and VLAN anti-spoofing feature\n+----------------------------------\n \n-Performance Tuning\n-==================\n+When a malicious driver attempts to send a spoofed packet, it is dropped by the\n+hardware and not transmitted.\n+NOTE: This feature can be disabled for a specific Virtual Function (VF):\n+ip link set <pf dev> vf <vf id> spoofchk {off|on}\n \n-An excellent article on performance tuning can be found at:\n \n-http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf\n+IEEE 1588 Precision Time Protocol (PTP) Hardware Clock (PHC)\n+------------------------------------------------------------\n \n+Precision Time Protocol (PTP) is used to synchronize clocks in a computer\n+network. PTP support varies among Intel devices that support this driver. Use\n+\"ethtool -T <netdev name>\" to get a definitive list of PTP capabilities\n+supported by the device.\n \n-Known Issues\n-============\n \n \n-Support\n-=======\n+IEEE 802.1ad (QinQ) Support\n+---------------------------\n \n-For general information, go to the Intel support website at:\n+The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN\n+IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as\n+\"tags,\" and multiple VLAN IDs are thus referred to as a \"tag stack.\" Tag stacks\n+allow L2 tunneling and the ability to segregate traffic within a particular\n+VLAN ID, among other uses.\n+\n+The following are examples of how to configure 802.1ad (QinQ):\n+ ip link add link eth0 eth0.24 type vlan proto 802.1ad id 24\n+ ip link add link eth0.24 eth0.24.371 type vlan proto 802.1Q id 371\n+Where \"24\" and \"371\" are example VLAN IDs.\n+\n+NOTES:\n+- 802.1ad (QinQ)is supported in 3.19 and later kernels.\n+- Receive checksum offloads, cloud filters, and VLAN acceleration are not\n+supported for 802.1ad (QinQ) packets.\n+\n+\n+VXLAN and GENEVE Overlay HW Offloading\n+--------------------------------------\n+\n+Virtual Extensible LAN (VXLAN) allows you to extend an L2 network over an L3\n+network, which may be useful in a virtualized or cloud environment. Some\n+Intel(R) Ethernet Network devices perform VXLAN processing, offloading it from\n+the operating system. This reduces CPU utilization.\n+\n+VXLAN offloading is controlled by the tx and rx checksum offload options\n+provided by ethtool. That is, if tx checksum offload is enabled, and the\n+adapter has the capability, VXLAN offloading is also enabled.\n+\n+Support for VXLAN and GENEVE HW offloading is dependent on kernel support of\n+the HW offloading features.\n+\n+\n+Multiple Functions per Port\n+---------------------------\n+\n+Some adapters based on the Intel Ethernet Controller X710/XL710 support\n+multiple functions on a single physical port. Configure these functions through\n+the System Setup/BIOS.\n+\n+Minimum TX Bandwidth is the guaranteed minimum data transmission bandwidth, as\n+a percentage of the full physical port link speed, that the partition will\n+receive. The bandwidth the partition is awarded will never fall below the level\n+you specify.\n+\n+The range for the minimum bandwidth values is:\n+1 to ((100 minus # of partitions on the physical port) plus 1)\n+For example, if a physical port has 4 partitions, the range would be:\n+1 to ((100 - 4) + 1 = 97)\n+\n+The Maximum Bandwidth percentage represents the maximum transmit bandwidth\n+allocated to the partition as a percentage of the full physical port link\n+speed. The accepted range of values is 1-100. The value is used as a limiter,\n+should you chose that any one particular function not be able to consume 100%\n+of a port's bandwidth (should it be available). The sum of all the values for\n+Maximum Bandwidth is not restricted, because no more than 100% of a port's\n+bandwidth can ever be used.\n+\n+NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions\n+per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says\n+\"add vsi failed for VF N, aq_err 16\". To workaround the issue, enable less than\n+64 virtual functions (VFs).\n+\n+\n+Data Center Bridging (DCB)\n+--------------------------\n+\n+NOTE:\n+The kernel assumes that TC0 is available, and will disable Priority Flow\n+Control (PFC) on the device if TC0 is not available. To fix this, ensure TC0 is\n+enabled when setting up DCB on your switch.\n+\n+\n+DCB is a configuration Quality of Service implementation in hardware. It uses\n+the VLAN priority tag (802.1p) to filter traffic. That means that there are 8\n+different priorities that traffic can be filtered into. It also enables\n+priority flow control (802.1Qbb) which can limit or eliminate the number of\n+dropped packets during network stress. Bandwidth can be allocated to each of\n+these priorities, which is enforced at the hardware level (802.1Qaz).\n+\n+Adapter firmware implements LLDP and DCBX protocol agents as per 802.1AB and\n+802.1Qaz respectively. The firmware based DCBX agent runs in willing mode only\n+and can accept settings from a DCBX capable peer. Software configuration of\n+DCBX parameters via dcbtool/lldptool are not supported.\n+\n+NOTE: Firmware LLDP can be disabled by setting the private flag disable-fw-lldp.\n+\n+The i40e driver implements the DCB netlink interface layer to allow user-space\n+to communicate with the driver and query DCB configuration for the port.\n+\n+\n+Interrupt Rate Limiting\n+-----------------------\n+\n+The Intel(R) Ethernet Controller XL710 family supports an interrupt rate\n+limiting mechanism. The user can control, via ethtool, the number of\n+microseconds between interrupts.\n+\n+Syntax:\n+# ethtool -C ethX rx-usecs-high N\n+\n+Valid Range: 0-235 (0=no limit)\n+\n+The range of 0-235 microseconds provides an effective range of 4,310 to 250,000\n+interrupts per second. The value of rx-usecs-high can be set independently of\n+rx-usecs and tx-usecs in the same ethtool command, and is also independent of\n+the adaptive interrupt moderation algorithm. The underlying hardware supports\n+granularity in 4-microsecond intervals, so adjacent values may result in the\n+same interrupt rate.\n+\n+One possible use case is the following:\n+# ethtool -C ethX adaptive-rx off adaptive-tx off rx-usecs-high 20 rx-usecs 5\n+tx-usecs 5\n+\n+The above command would disable adaptive interrupt moderation, and allow a\n+maximum of 5 microseconds before indicating a receive or transmit was complete.\n+However, instead of resulting in as many as 200,000 interrupts per second, it\n+limits total interrupts per second to 50,000 via the rx-usecs-high parameter.\n+\n+\n+Performance Optimization:\n+-------------------------\n+\n+Driver defaults are meant to fit a wide variety of workloads, but if further\n+optimization is required we recommend experimenting with the following settings.\n+\n+NOTE: For better performance when processing small (64B) frame sizes, try\n+enabling Hyper threading in the BIOS in order to increase the number of logical\n+cores in the system and subsequently increase the number of queues available to\n+the adapter.\n \n- http://support.intel.com\n+Virtualized Environments:\n+\n+1. Disable XPS on both ends by using the included virt_perf_default script\n+ or by running the following command as root:\n+ for file in `ls /sys/class/net/<ethX>/queues/tx-*/xps_cpus`;\n+ do echo 0 > $file; done\n+\n+2. Using the appropriate mechanism (vcpupin) in the vm, pin the cpu's to\n+ individual lcpu's, making sure to use a set of cpu's included in the\n+ device's local_cpulist: /sys/class/net/<ethX>/device/local_cpulist.\n+\n+3. Configure as many rx/tx queues in the VM as available. Do not rely on\n+ the default setting of 1.\n+\n+\n+Non-virtualized Environments\n+\n+Pin the adapter's IRQs to specific cores by disabling the irqbalance service\n+and using the included set_irq_affinity script. Please see the script's help\n+text for further options.\n+\n+ - The following settings will distribute the IRQs across all the cores\n+ evenly:\n+\n+ # scripts/set_irq_affinity -x all <interface1> , [ <interface2>, ... ]\n+\n+ - The following settings will distribute the IRQs across all the cores that\n+ are local to the adapter (same NUMA node):\n+\n+ # scripts/set_irq_affinity -x local <interface1> ,[ <interface2>, ... ]\n+\n+For very CPU intensive workloads, we recommend pinning the IRQs to all cores.\n+\n+For IP Forwarding: Disable Adaptive ITR and lower rx and tx interrupts per\n+queue using ethtool.\n+\n+ - Setting rx-usecs and tx-usecs to 125 will limit interrupts to about 8000\n+ interrupts per second per queue.\n+\n+ # ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 125\n+ tx-usecs 125\n+\n+For lower CPU utilization: Disable Adaptive ITR and lower rx and tx interrupts\n+per queue using ethtool.\n+\n+ - Setting rx-usecs and tx-usecs to 250 will limit interrupts to about 4000\n+ interrupts per second per queue.\n+\n+ # ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 250\n+ tx-usecs 250\n+\n+For lower latency: Disable Adaptive ITR and ITR by setting rx and tx to 0 using\n+ethtool.\n+\n+ # ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 0\n+ tx-usecs 0\n+\n+\n+Application Device Queues (ADq)\n+-------------------------------\n+\n+Application Device Queues (ADq) allows you to dedicate one or more queues to a\n+specific application. This can reduce latency for the specified application,\n+and allow Tx traffic to be rate limited per application. Follow the steps below\n+to set ADq.\n+\n+NOTE: Run all tc commands from the iproute2 <pathtoiproute2>/tc/ directory.\n+ 1. Create traffic classes (TCs). Maximum of 8 TCs can be created per\n+ interface. The shaper bw_rlimit parameter is optional.\n+ Example:\n+ Sets up two tcs, tc0 and tc1, with 16 queues each and max tx rate set\n+ to 1Gbit for tc0 and 3Gbit for tc1.\n+ # tc qdisc add dev <interface> root mqprio num_tc 2 map 0 0 0 0 1 1 1 1\n+ queues 16@0 16@16 hw 1 mode channel shaper bw_rlimit min_rate 1Gbit 2Gbit\n+ max_rate 1Gbit 3Gbit\n+\n+ map: priority mapping for up to 16 priorities to tcs\n+ (e.g. map 0 0 0 0 1 1 1 1 sets priorities 0-3 to use tc0 and 4-7 to\n+ use tc1)\n+\n+ queues: for each tc, <num queues>@<offset> (e.g. queues 16@0 16@16 assigns\n+ 16 queues to tc0 at offset 0 and 16 queues to tc1 at offset 16. Max total\n+ number of queues for all tcs is 64 or number of cores, whichever is\n+ lower.)\n+\n+ hw 1 mode channel: ‘channel’ with ‘hw’ set to 1 is a new new hardware\n+ offload mode in mqprio that makes full use of the mqprio options, the\n+ TCs, the queue configurations, and the QoS parameters.\n+\n+ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.\n+ Totals must be equal or less than port speed.\n+ For example: min_rate 1Gbit 3Gbit:\n+ Verify bandwidth limit using network monitoring tools such as ifstat\n+ or sar –n DEV [interval] [number of samples]\n+\n+NOTE: Setting up channels via ethtool (ethtool -L) is not supported when the\n+TCs are configured using mqprio.\n+\n+ 2. Enable HW TC offload on interface:\n+ # ethtool -K <interface> hw-tc-offload on\n+ 3. Apply TCs to ingress (RX) flow of interface:\n+ # tc qdisc add dev <interface> ingress\n+NOTES:\n+- You must have kernel version 4.15 or later and the sch_mqprio, act_mirred\n+ and cls_flower modules loaded to set ADq\n+- You must have iproute2 latest version\n+- NVM version 6.01 or later is required.\n+- ADq cannot be enabled when any the following features are enabled: Data\n+ Center Bridging (DCB), Multiple Functions per Port (MFP), or Sideband\n+ Filters.\n+- If another driver (for example, DPDK) has set cloud filters, you cannot\n+ enable ADq.\n+\n+\n+================================================================================\n+\n+\n+Support\n+-------\n+For general information, go to the Intel support website at:\n+www.intel.com/support/\n \n or the Intel Wired Networking project hosted by Sourceforge at:\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+\n+\n+================================================================================\n+\n+\n+License\n+-------\n+This program is free software; you can redistribute it and/or modify it under\n+the terms and conditions of the GNU General Public License, version 2, as\n+published by the Free Software Foundation.\n+\n+This program is distributed in the hope it will be useful, but WITHOUT ANY\n+WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A\n+PARTICULAR PURPOSE. See the GNU General Public License for more details.\n+\n+You should have received a copy of the GNU General Public License along with\n+this program; if not, write to the Free Software Foundation, Inc., 51 Franklin\n+St - Fifth Floor, Boston, MA 02110-1301 USA.\n+\n+The full GNU General Public License is included in this distribution in the\n+file called \"COPYING\".\n+\n+Copyright(c) 1999-2017 Intel Corporation.\n+================================================================================\n+\n+\n+Trademarks\n+----------\n+Intel and Itanium are trademarks or registered trademarks of Intel Corporation\n+or its subsidiaries in the United States and/or other countries.\n+\n+* Other names and brands may be claimed as the property of others.\n \n- http://e1000.sourceforge.net\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.sourceforge.net and copy\n-netdev@vger.kernel.org.\ndiff --git a/Documentation/networking/i40evf.txt b/Documentation/networking/i40evf.txt\nindex e9b3035b95d0..5bfef8791387 100644\n--- a/Documentation/networking/i40evf.txt\n+++ b/Documentation/networking/i40evf.txt\n@@ -1,54 +1,346 @@\n-Linux* Base Driver for Intel(R) Network Connection\n-==================================================\n+Linux* Driver for Intel(R) Ethernet Virtual Function 700 Series\n+======================================================\n \n-Intel Ethernet Adaptive Virtual Function Linux driver.\n-Copyright(c) 2013-2017 Intel Corporation.\n+November 28, 2017\n+\n+======================================================\n \n Contents\n ========\n-\n-- Identifying Your Adapter\n-- Known Issues/Troubleshooting\n+- Overview\n+- Additional Configurations\n+- Known Issues\n - Support\n+- License\n+\n+================================================================================\n+\n+\n+This driver supports XL710- and X710-based virtual function devices\n+with CONFIG_PCI_IOV enabled.\n+\n+SR-IOV requires the correct platform and OS support.\n \n-This file describes the i40evf Linux* Base Driver.\n+The guest OS loading this driver must support MSI-X interrupts.\n \n-The i40evf driver supports the below mentioned virtual function\n-devices and can only be activated on kernels running the i40e or\n-newer Physical Function (PF) driver compiled with CONFIG_PCI_IOV.\n-The i40evf driver requires CONFIG_PCI_MSI to be enabled.\n+For questions related to hardware requirements, refer to the documentation\n+supplied with your Intel adapter. All hardware requirements listed apply to use\n+with Linux.\n+\n+Driver information can be obtained using ethtool, lspci, and ifconfig.\n+Instructions on updating ethtool can be found in the section Additional\n+Configurations later in this document.\n+\n+The i40evf driver supports virtual functions generated by the i40e driver,\n+with one or more VFs enabled through sysfs.\n \n-The guest OS loading the i40evf driver must support MSI-X interrupts.\n \n-Supported Hardware\n-==================\n-Intel XL710 X710 Virtual Function\n-Intel Ethernet Adaptive Virtual Function\n-Intel X722 Virtual Function\n \n Identifying Your Adapter\n-========================\n+------------------------\n+The driver in this release is compatible with devices based on the following:\n+ * Intel(R) Ethernet Controller X710\n+ * Intel(R) Ethernet Controller XL710\n+ * Intel(R) Ethernet Network Connection X722\n+ * Intel(R) Ethernet Controller XXV710\n+\n+For the best performance, make sure the latest NVM/FW is installed on your\n+device and that you are using the newest drivers.\n+\n+For information on how to identify your adapter, and for the latest NVM/FW\n+images and Intel network drivers, refer to the Intel Support website:\n+http://www.intel.com/support\n+\n+\n+Additional Features and Configurations\n+-------------------------------------------\n+\n+\n+Viewing Link Messages\n+---------------------\n+Link messages will not be displayed to the console if the distribution is\n+restricting system messages. In order to see network driver link messages on\n+your console, set dmesg to eight by entering the following:\n+dmesg -n 8\n+\n+NOTE: This setting is not saved across reboots.\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+\n+Setting VLAN Tag Stripping\n+--------------------------\n+\n+If you have applications that require Virtual Functions (VFs) to receive\n+packets with VLAN tags, you can disable VLAN tag stripping for the VF. The\n+Physical Function (PF) processes requests issued from the VF to enable or\n+disable VLAN tag stripping. Note that if the PF has assigned a VLAN to a VF,\n+then requests from that VF to set VLAN tag stripping will be ignored.\n+\n+To enable/disable VLAN tag stripping for a VF, issue the following command\n+from inside the VM in which you are running the VF:\n+ ethtool -K <if_name> rxvlan on/off\n+ or alternatively:\n+ ethtool --offload <if_name> rxvlan on/off\n \n-For more information on how to identify your adapter, go to the\n-Adapter & Driver ID Guide at:\n \n- http://support.intel.com/support/go/network/adapter/idguide.htm\n+Adaptive Virtual Function\n+-------------------------\n+Adaptive Virtual Function (AVF) allows the virtual function driver, or VF, to\n+adapt to changing feature sets of the physical function driver (PF) with which\n+it is associated. This allows system administrators to update a PF without\n+having to update all the VFs associated with it. All AVFs have a single common\n+device ID and branding string.\n+\n+AVFs have a minimum set of features known as \"base mode,\" but may provide\n+additional features depending on what features are available in the PF with\n+which the AVF is associated. The following are base mode features:\n+\n+- 4 Queue Pairs (QP) and associated Configuration Status Registers (CSRs)\n+ for Tx/Rx.\n+- i40e descriptors and ring format.\n+- Descriptor write-back completion.\n+- 1 control queue, with i40e descriptors, CSRs and ring format.\n+- 5 MSI-X interrupt vectors and corresponding i40e CSRs.\n+- 1 Interrupt Throttle Rate (ITR) index.\n+- 1 Virtual Station Interface (VSI) per VF.\n+- 1 Traffic Class (TC), TC0\n+- Receive Side Scaling (RSS) with 64 entry indirection table and key,\n+ configured through the PF.\n+- 1 unicast MAC address reserved per VF.\n+- 16 MAC address filters for each VF.\n+- Stateless offloads - non-tunneled checksums.\n+- AVF device ID.\n+- HW mailbox is used for VF to PF communications (including on Windows).\n+\n+\n+IEEE 802.1ad (QinQ) Support\n+---------------------------\n+\n+The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN\n+IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as\n+\"tags,\" and multiple VLAN IDs are thus referred to as a \"tag stack.\" Tag stacks\n+allow L2 tunneling and the ability to segregate traffic within a particular\n+VLAN ID, among other uses.\n+\n+The following are examples of how to configure 802.1ad (QinQ):\n+ ip link add link eth0 eth0.24 type vlan proto 802.1ad id 24\n+ ip link add link eth0.24 eth0.24.371 type vlan proto 802.1Q id 371\n+Where \"24\" and \"371\" are example VLAN IDs.\n+\n+NOTES:\n+- 802.1ad (QinQ)is supported in 3.19 and later kernels.\n+- Receive checksum offloads, cloud filters, and VLAN acceleration are not\n+supported for 802.1ad (QinQ) packets.\n+\n+\n+Application Device Queues (ADq)\n+-------------------------------\n+\n+Application Device Queues (ADq) allows you to dedicate one or more queues to a\n+specific application. This can reduce latency for the specified application,\n+and allow Tx traffic to be rate limited per application. Follow the steps below\n+to set ADq.\n+\n+NOTE: Run all tc commands from the iproute2 <pathtoiproute2>/tc/ directory.\n+ 1. Create traffic classes (TCs). Maximum of 8 TCs can be created per\n+ interface. The shaper bw_rlimit parameter is optional.\n+ Example:\n+ Sets up two tcs, tc0 and tc1, with 16 queues each and max tx rate set\n+ to 1Gbit for tc0 and 3Gbit for tc1.\n+ # tc qdisc add dev <interface> root mqprio num_tc 2 map 0 0 0 0 1 1 1 1\n+ queues 16@0 16@16 hw 1 mode channel shaper bw_rlimit min_rate 1Gbit 2Gbit\n+ max_rate 1Gbit 3Gbit\n+\n+ map: priority mapping for up to 16 priorities to tcs\n+ (e.g. map 0 0 0 0 1 1 1 1 sets priorities 0-3 to use tc0 and 4-7 to\n+ use tc1)\n+\n+ queues: for each tc, <num queues>@<offset> (e.g. queues 16@0 16@16 assigns\n+ 16 queues to tc0 at offset 0 and 16 queues to tc1 at offset 16. Max total\n+ number of queues for all tcs is 64 or number of cores, whichever is\n+ lower.)\n+\n+ hw 1 mode channel: ‘channel’ with ‘hw’ set to 1 is a new new hardware\n+ offload mode in mqprio that makes full use of the mqprio options, the\n+ TCs, the queue configurations, and the QoS parameters.\n+\n+ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.\n+ Totals must be equal or less than port speed.\n+ For example: min_rate 1Gbit 3Gbit:\n+ Verify bandwidth limit using network monitoring tools such as ifstat\n+ or sar –n DEV [interval] [number of samples]\n+\n+NOTE: Setting up channels via ethtool (ethtool -L) is not supported when the\n+TCs are configured using mqprio.\n+\n+ 2. Enable HW TC offload on interface:\n+ # ethtool -K <interface> hw-tc-offload on\n+ 3. Apply TCs to ingress (RX) flow of interface:\n+ # tc qdisc add dev <interface> ingress\n+NOTES:\n+- You must have kernel version 4.15 or later and the sch_mqprio, act_mirred\n+ and cls_flower modules loaded to set ADq\n+- You must have iproute2 latest version\n+- NVM version 6.01 or later is required.\n+- ADq cannot be enabled when any the following features are enabled: Data\n+ Center Bridging (DCB), Multiple Functions per Port (MFP), or Sideband\n+ Filters.\n+- If another driver (for example, DPDK) has set cloud filters, you cannot\n+ enable ADq.\n+\n+\n+================================================================================\n+\n \n Known Issues/Troubleshooting\n-============================\n+----------------------------\n \n \n-Support\n-=======\n+Traffic Is Not Being Passed Between VM and Client\n+-------------------------------------------------\n+You may not be able to pass traffic between a client system and a\n+Virtual Machine (VM) running on a separate host if the Virtual Function\n+(VF, or Virtual NIC) is not in trusted mode and spoof checking is enabled\n+on the VF. Note that this situation can occur in any combination of client,\n+host, and guest operating system. For information on how to set the VF to\n+trusted mode, refer to the section \"VLAN Tag Packet Steering\" in this\n+readme document. For information on setting spoof checking, refer to the\n+section \"MAC and VLAN anti-spoofing feature\" in this readme document.\n \n-For general information, go to the Intel support website at:\n \n- http://support.intel.com\n+Do not unload port driver if VF with active VM is bound to it\n+-------------------------------------------------------------\n+Do not unload a port's driver if a Virtual Function (VF) with an active Virtual\n+Machine (VM) is bound to it. Doing so will cause the port to appear to hang.\n+Once the VM shuts down, or otherwise releases the VF, the command will complete.\n+\n+\n+Virtual machine does not get link\n+---------------------------------\n+If the virtual machine has more than one virtual port assigned to it, and those\n+virtual ports are bound to different physical ports, you may not get link on\n+all of the virtual ports. The following command may work around the issue:\n+ethtool -r <PF>\n+Where <PF> is the PF interface in the host, for example: p5p1. You may need to\n+run the command more than once to get link on all virtual ports.\n+\n+\n+MAC address of Virtual Function changes unexpectedly\n+----------------------------------------------------\n+If a Virtual Function's MAC address is not assigned in the host, then the VF\n+(virtual function) driver will use a random MAC address. This random MAC\n+address may change each time the VF driver is reloaded. You can assign a static\n+MAC address in the host machine. This static MAC address will survive\n+a VF driver reload.\n+\n+\n+Hardware Issues\n+---------------\n+\n+For known hardware and troubleshooting issues, either refer to the \"Release\n+Notes\" in your User Guide, or for more detailed information, go to\n+http://www.intel.com.\n+\n+In the search box enter your devices controller ID followed by \"spec update\"\n+(i.e., XL710 spec update). The specification update file has complete\n+information on known hardware issues.\n+\n+\n+Software Issues\n+---------------\n+\n+NOTE: After installing the driver, if your Intel Ethernet Network Connection\n+is not working, verify that you have installed the correct driver.\n+\n+\n+Driver Buffer Overflow Fix\n+--------------------------\n+The fix to resolve CVE-2016-8105, referenced in Intel SA-00069\n+<https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00069&language\n+id=en-fr>, is included in this and future versions of the driver.\n+\n+\n+Multiple Interfaces on Same Ethernet Broadcast Network\n+------------------------------------------------------\n+Due to the default ARP behavior on Linux, it is not possible to have one system\n+on two IP networks in the same Ethernet broadcast domain (non-partitioned\n+switch) behave as expected. All Ethernet interfaces will respond to IP traffic\n+for any IP address assigned to the system. This results in unbalanced receive\n+traffic.\n+\n+If you have multiple interfaces in a server, either turn on ARP filtering by\n+entering:\n+echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter\n+\n+This only works if your kernel's version is higher than 2.4.5.\n+\n+\n+NOTE: This setting is not saved across reboots. The configuration change can be\n+made permanent by adding the following line to the file /etc/sysctl.conf:\n+net.ipv4.conf.all.arp_filter = 1\n+\n+Another alternative is to install the interfaces in separate broadcast domains\n+(either in different switches or in a switch partitioned to VLANs).\n+\n+\n+Rx Page Allocation Errors\n+-------------------------\n+'Page allocation failure. order:0' errors may occur under stress.\n+This is caused by the way the Linux kernel reports this stressed condition.\n+\n+\n+\n+================================================================================\n+\n+\n+Support\n+-------\n+For general information, go to the Intel support website at:\n+www.intel.com/support/\n \n or the Intel Wired Networking project hosted by Sourceforge at:\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+\n+\n+================================================================================\n+\n+\n+License\n+-------\n+This program is free software; you can redistribute it and/or modify it under\n+the terms and conditions of the GNU General Public License, version 2, as\n+published by the Free Software Foundation.\n+\n+This program is distributed in the hope it will be useful, but WITHOUT ANY\n+WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A\n+PARTICULAR PURPOSE. See the GNU General Public License for more details.\n+\n+You should have received a copy of the GNU General Public License along with\n+this program; if not, write to the Free Software Foundation, Inc., 51 Franklin\n+St - Fifth Floor, Boston, MA 02110-1301 USA.\n+\n+The full GNU General Public License is included in this distribution in the\n+file called \"COPYING\".\n+\n+Copyright(c) 2014-2017 Intel Corporation.\n+================================================================================\n+\n+\n+Trademarks\n+----------\n+Intel and Itanium are trademarks or registered trademarks of Intel Corporation\n+or its subsidiaries in the United States and/or other countries.\n+\n+* Other names and brands may be claimed as the property of others.\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/igb.txt b/Documentation/networking/igb.txt\nindex f90643ef39c9..c9a5cf93bb0b 100644\n--- a/Documentation/networking/igb.txt\n+++ b/Documentation/networking/igb.txt\n@@ -2,7 +2,7 @@ Linux* Base 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-2017 Intel Corporation.\n \n Contents\n ========\n@@ -12,118 +12,250 @@ Contents\n - Support\n \n Identifying Your Adapter\n-========================\n+------------------------\n+This release includes two gigabit FreeBSD base Drivers for Intel(R) Ethernet.\n+These drivers are em and igb.\n \n-This driver supports all 82575, 82576 and 82580-based Intel (R) gigabit network\n-connections.\n+- The igb driver supports all 82575 and 82576-based gigabit network connections.\n+- The em driver supports all other gigabit network connections.\n+- Gigabit devices base on the Intel(R) Ethernet Controller X722 are supported by\n+ the i40e ixl driver.\n \n-For specific information on how to identify your adapter, go to the Adapter &\n-Driver ID Guide at:\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- http://support.intel.com/support/go/network/adapter/idguide.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 igb [<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 igb InterruptThrottleRate=16000,16000\n+\n+In this case, there are two network ports supported by igb in the system.\n The default value for each parameter is generally the recommended setting,\n unless otherwise noted.\n \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 max_vfs\n -------\n-Valid Range: 0-7\n-Default Value: 0\n+This parameter adds support for SR-IOV. It causes the driver to spawn up to\n+max_vfs worth of virtual functions.\n+Valid Range: 0-7\n+If the value is greater than 0 it will also force the VMDq parameter to be 1 or\n+more.\n+\n+The parameters for the driver are referenced by position. Thus, if you have a\n+dual port adapter, or more than one adapter in your system, and want N virtual\n+functions per port, you must specify a number for each port with each parameter\n+separated by a comma. For example:\n+\n+ modprobe igb max_vfs=4\n+\n+This will spawn 4 VFs on the first port.\n+\n+ modprobe igb max_vfs=2,4\n+\n+This will spawn 2 VFs on the first port and 4 VFs on the second port.\n+\n+NOTE: Caution must be used in loading the driver with these parameters.\n+Depending on your system configuration, number of slots, etc., it is impossible\n+to predict in all cases where the positions would be on the command line.\n+\n+NOTE: Neither the device nor the driver control how VFs are mapped into config\n+space. Bus layout will vary by operating system. On operating systems that\n+support it, you can check sysfs to find the mapping.\n+\n+\n+NOTE: When either SR-IOV mode or VMDq mode is enabled, hardware VLAN filtering\n+and VLAN tag stripping/insertion will remain enabled. Please remove the old\n+VLAN filter before the new VLAN filter is added. For example,\n+ip link set eth0 vf 0 vlan 100\t// set vlan 100 for VF 0\n+ip link set eth0 vf 0 vlan 0\t// Delete vlan 100\n+ip link set eth0 vf 0 vlan 200\t// set a new vlan 200 for VF 0\n+\n+\n+QueuePairs\n+----------\n+Valid Range: 0-1\n+If set to 0, when MSI-X is enabled, the Tx and Rx will attempt to occupy\n+separate vectors.\n+This option can be overridden to 1 if there are not sufficient interrupts\n+available. This can occur if any combination of RSS, VMDQ, and max_vfs results\n+in more than 4 queues being used.\n+\n+\n+Node\n+----\n+Valid Range: 0-n\n+0 - n: where n is the number of the NUMA node that should be used to allocate\n+memory for this adapter port.\n+-1: uses the driver default of allocating memory on whichever processor is\n+running modprobe.\n+The Node parameter allows you to choose which NUMA node you want to have the\n+adapter allocate memory from. All driver structures, in-memory queues, and\n+receive buffers will be allocated on the node specified. This parameter is\n+only useful when interrupt affinity is specified; otherwise, part of the\n+interrupt time could run on a different core than where the memory is\n+allocated causing slower memory access and impacting throughput, CPU, or both.\n+\n+\n+EEE\n+---\n+Valid Range: 0-1\n+0 = Disables EEE\n+1 = Enables EEE\n+A link between two EEE-compliant devices will result in periodic bursts of\n+data followed by periods where the link is in an idle state. This Low Power\n+Idle (LPI) state is supported in both 1 Gbps and 100 Mbps link speeds.\n \n-This parameter adds support for SR-IOV. It causes the driver to spawn up to\n-max_vfs worth of virtual function.\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 ip command to increase the MTU size.\n- For example:\n+DMAC\n+----\n+Valid Range: 0, 1, 250, 500, 1000, 2000, 3000, 4000, 5000, 6000, 7000, 8000,\n+9000, 10000\n+This parameter enables or disables DMA Coalescing feature. Values are in\n+microseconds and set the internal DMA Coalescing internal timer.\n+DMA (Direct Memory Access) allows the network device to move packet data\n+directly to the system's memory, reducing CPU utilization. However, the\n+frequency and random intervals at which packets arrive do not allow the\n+system to enter a lower power state. DMA Coalescing allows the adapter\n+to collect packets before it initiates a DMA event. This may increase\n+network latency but also increases the chances that the system will enter\n+a lower power state.\n+Turning on DMA Coalescing may save energy with kernel 2.6.32 and newer.\n+DMA Coalescing must be enabled across all active ports in order to save\n+platform power.\n \n- ip link set dev eth<x> mtu 9000\n \n- This setting is not saved across reboots.\n+Additional Features and Configurations\n+-------------------------------------------\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+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- - Using Jumbo frames at 10 or 100 Mbps is not supported and may result in\n- poor performance or loss of link.\n+Use the ifconfig command to increase the MTU size. For example, enter the\n+following where <x> is the interface number:\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\n- version of ethtool can be found at:\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- https://www.kernel.org/pub/software/network/ethtool/\n+To confirm an interface's MTU value, use the ifconfig command.\n \n- Enabling Wake on LAN* (WoL)\n- ---------------------------\n- WoL is configured through the ethtool* utility.\n+To confirm the MTU used between two specific devices, use:\n \n- For instructions on enabling WoL with ethtool, refer to the ethtool man page.\n+ route get <destination_IP_address>\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 igb driver must be\n- loaded when shutting down or rebooting the system.\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- Wake On LAN is only supported on port A of multi-port adapters.\n+NOTE: The maximum MTU setting for Jumbo Frames is 9216. This value coincides\n+with the maximum Jumbo Frames size of 9234 bytes.\n \n- Wake On LAN is not supported for the Intel(R) Gigabit VT Quad Port Server\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+\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+\n+Enabling Wake on LAN* (WoL)\n+---------------------------\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 igb driver must be loaded\n+prior to shutting down or suspending the system.\n+\n+NOTES:\n+- Wake on LAN is only supported on port A of multi-port devices.\n+- Wake On LAN is not supported for the Intel(R) Gigabit VT Quad Port Server\n Adapter.\n \n- Multiqueue\n- ----------\n- In this mode, a separate MSI-X vector is allocated for each queue and one\n- for \"other\" interrupts such as link status change and errors. All\n- interrupts are throttled via interrupt moderation. Interrupt moderation\n- must be used to avoid interrupt storms while the driver is processing one\n- interrupt. The moderation value should be at least as large as the expected\n- time for the driver to process an interrupt. Multiqueue is off by default.\n \n- REQUIREMENTS: MSI-X support is required for Multiqueue. If MSI-X is not\n- found, the system will fallback to MSI or to Legacy interrupts.\n+Multiqueue\n+----------\n+In this mode, a separate MSI-X vector is allocated for each queue and one for\n+\"other\" interrupts such as link status change and errors. All interrupts are\n+throttled via interrupt moderation. Interrupt moderation must be used to avoid\n+interrupt storms while the driver is processing one interrupt. The moderation\n+value should be at least as large as the expected time for the driver to\n+process an interrupt. Multiqueue is off by default.\n \n- MAC and VLAN anti-spoofing feature\n- ----------------------------------\n- When a malicious driver attempts to send a spoofed packet, it is dropped by\n- the hardware and not transmitted. An interrupt is sent to the PF driver\n- notifying it of the spoof attempt.\n+REQUIREMENTS: MSI-X support is required for Multiqueue. If MSI-X is not found,\n+the system will fallback to MSI or to Legacy interrupts. This driver supports\n+multiqueue in kernel versions 2.6.24 and newer. This driver supports receive\n+multiqueue on all kernels that support MSI-X.\n \n- When a spoofed packet is detected the PF driver will send the following\n- message to the system log (displayed by the \"dmesg\" command):\n+NOTES:\n+- Do not use MSI-X with the 2.6.19 or 2.6.20 kernels.\n+- On some kernels a reboot is required to switch between single queue mode\n+and multiqueue mode or vice-versa.\n \n- Spoof event(s) detected on VF(n)\n \n- Where n=the VF that attempted to do the spoofing.\n+MAC and VLAN anti-spoofing feature\n+----------------------------------\n \n- Setting MAC Address, VLAN and Rate Limit Using IProute2 Tool\n- ------------------------------------------------------------\n- You can set a MAC address of a Virtual Function (VF), a default VLAN and the\n- rate limit using the IProute2 tool. Download the latest version of the\n- iproute2 tool from Sourceforge if your version does not have all the\n- features you require.\n+When a malicious driver attempts to send a spoofed packet, it is dropped by the\n+hardware and not transmitted.\n \n+An interrupt is sent to the PF driver notifying it of the spoof attempt. When a\n+spoofed packet is detected, the PF driver will send the following message to\n+the system log (displayed by the \"dmesg\" command):\n+Spoof event(s) detected on VF(n), where n = the VF that attempted to do the\n+spoofing\n \n-Support\n-=======\n \n-For general information, go to the Intel support website at:\n \n- www.intel.com/support/\n+Setting MAC Address, VLAN and Rate Limit Using IProute2 Tool\n+------------------------------------------------------------\n+You can set a MAC address of a Virtual Function (VF), a default VLAN and the\n+rate limit using the IProute2 tool. Download the latest version of the\n+IProute2 tool from Sourceforge if your version does not have all the features\n+you require.\n+\n+\n+Support\n+-------\n+For general information, go to the Intel support website at:\n+www.intel.com/support/\n \n or the Intel Wired Networking project hosted by Sourceforge at:\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.freebsdnic@mailbox.intel.com\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/igbvf.txt b/Documentation/networking/igbvf.txt\nindex bd404735fb46..9b284dd15a8c 100644\n--- a/Documentation/networking/igbvf.txt\n+++ b/Documentation/networking/igbvf.txt\n@@ -2,79 +2,67 @@ Linux* Base 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-2015 Intel Corporation.\n \n Contents\n ========\n-\n - Identifying Your Adapter\n - Additional Configurations\n - Support\n \n-This file describes the igbvf Linux* Base Driver for Intel Network Connection.\n+This virtual function driver supports kernel versions default_kernel_version.\n \n-The igbvf driver supports 82576-based virtual function devices that can only\n-be activated on kernels that support SR-IOV. SR-IOV requires the correct\n-platform and OS support.\n+This driver supports default_hw_family-based virtual function devices\n+that can only be activated on kernels that support SR-IOV.\n \n-The igbvf driver requires the igb driver, version 2.0 or later. The igbvf\n-driver supports virtual functions generated by the igb driver with a max_vfs\n-value of 1 or greater. For more information on the max_vfs parameter refer\n-to the README included with the igb driver.\n+SR-IOV requires the correct platform and OS support.\n \n-The guest OS loading the igbvf driver must support MSI-X interrupts.\n+The guest OS loading this driver must support MSI-X interrupts.\n \n-This driver is only supported as a loadable module at this time. Intel is\n-not supplying patches against the kernel source to allow for static linking\n-of the driver. For questions related to hardware requirements, refer to the\n-documentation supplied with your Intel Gigabit adapter. All hardware\n-requirements listed apply to use with Linux.\n+This driver is only supported as a loadable module at this time. Intel is not\n+supplying patches against the kernel source to allow for static linking of the\n+drivers.\n \n-Instructions on updating ethtool can be found in the section \"Additional\n-Configurations\" later in this document.\n+For questions related to hardware requirements, refer to the documentation\n+supplied with your Intel adapter. All hardware requirements listed apply to use\n+with Linux.\n \n-VLANs: There is a limit of a total of 32 shared VLANs to 1 or more VFs.\n+Driver information can be obtained using variable_value_undefined. Instructions\n+on updating ethtool can be found in the section Additional Configurations later\n+in this document.\n \n-Identifying Your Adapter\n-========================\n+VLANs: There is a limit of a total of 32 shared VLANs to 1 or more VFs.\n \n-The igbvf driver supports 82576-based virtual function devices that can only\n-be activated on kernels that support SR-IOV.\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+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-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://downloadcenter.intel.com/scripts-df-external/Support_Intel.aspx\n+Additional Features and Configurations\n+-------------------------------------------\n \n-Additional Configurations\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 ethtool\n- version 3.0 or later is required for this functionality, although we\n- strongly recommend downloading the latest version at:\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- https://www.kernel.org/pub/software/network/ethtool/\n \n Support\n-=======\n-\n+-------\n For general information, go to the Intel support website at:\n-\n- http://support.intel.com\n+www.intel.com/support/\n \n or the Intel Wired Networking project hosted by Sourceforge at:\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 \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/ixgbe.txt b/Documentation/networking/ixgbe.txt\nindex 687835415707..db64a7ad2987 100644\n--- a/Documentation/networking/ixgbe.txt\n+++ b/Documentation/networking/ixgbe.txt\n@@ -2,12 +2,12 @@ Linux* Base Driver for the Intel(R) Ethernet 10 Gigabit PCI Express Family of\n Adapters\n =============================================================================\n \n+February 23, 2017\n Intel 10 Gigabit Linux driver.\n-Copyright(c) 1999 - 2013 Intel Corporation.\n+Copyright(c) 1999-2017 Intel Corporation.\n \n Contents\n ========\n-\n - Identifying Your Adapter\n - Additional Configurations\n - Performance Tuning\n@@ -15,335 +15,489 @@ Contents\n - Support\n \n Identifying Your Adapter\n-========================\n-\n-The driver in this release is compatible with 82598, 82599 and X540-based\n-Intel Network Connections.\n+------------------------\n+The driver is compatible with devices based on the following:\n+ * Intel(R) Ethernet Controller 82598\n+ * Intel(R) Ethernet Controller 82599\n+ * Intel(R) Ethernet Controller X540\n+ * Intel(R) Ethernet Controller x550\n+ * Intel(R) Ethernet Controller X552\n+ * Intel(R) Ethernet Controller X553\n \n-For more information on how to identify your adapter, go to the Adapter &\n-Driver ID Guide at:\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- http://support.intel.com/support/network/sb/CS-012904.htm\n \n SFP+ Devices with Pluggable Optics\n ----------------------------------\n \n 82599-BASED ADAPTERS\n+--------------------\n+\n+NOTES:\n+- If your 82599-based Intel(R) Network Adapter came with Intel optics or is an\n+ Intel(R) Ethernet Server Adapter X520-2, then it only supports Intel optics\n+ and/or the direct attach cables listed below.\n+- When 82599-based SFP+ devices are connected back to back, they should be\n+ set to the same Speed setting via ethtool. Results may vary if you mix\n+ speed settings.\n+\n+Supplier\tType\t\t\t\t\tPart Numbers\n+--------\t----\t\t\t\t\t------------\n+SR Modules\n+Intel\t\tDUAL RATE 1G/10G SFP+ SR (bailed)\tFTLX8571D3BCV-IT\n+Intel\t\tDUAL RATE 1G/10G SFP+ SR (bailed)\tAFBR-703SDZ-IN2\n+Intel\t\tDUAL RATE 1G/10G SFP+ SR (bailed)\tAFBR-703SDDZ-IN1\n+LR Modules\n+Intel\t\tDUAL RATE 1G/10G SFP+ LR (bailed)\tFTLX1471D3BCV-IT\n+Intel\t\tDUAL RATE 1G/10G SFP+ LR (bailed)\tAFCT-701SDZ-IN2\n+Intel\t\tDUAL RATE 1G/10G SFP+ LR (bailed)\tAFCT-701SDDZ-IN1\n+\n+The following is a list of 3rd party SFP+ modules that have received some\n+testing. Not all modules are applicable to all devices.\n+\n+Supplier\tType\t\t\t\t\tPart Numbers\n+--------\t----\t\t\t\t\t------------\n+Finisar\t\tSFP+ SR bailed, 10g single\n+rate\t\tFTLX8571D3BCL\n+Avago\t\tSFP+ SR bailed, 10g single rate\t\tAFBR-700SDZ\n+Finisar\t\tSFP+ LR bailed, 10g single\n+rate\t\tFTLX1471D3BCL\n+Finisar\t\tDUAL RATE 1G/10G SFP+ SR (No\n+Bail)\tFTLX8571D3QCV-IT\n+Avago\t\tDUAL RATE 1G/10G SFP+ SR (No Bail)\tAFBR-703SDZ-IN1\n+Finisar\t\tDUAL RATE 1G/10G SFP+ LR (No\n+Bail)\tFTLX1471D3QCV-IT\n+Avago\t\tDUAL RATE 1G/10G SFP+ LR (No Bail)\tAFCT-701SDZ-IN1\n+\n+Finisar\t\t1000BASE-T\n+SFP\t\t\t\tFCLF8522P2BTL\n+Avago\t\t1000BASE-T\t\t\t\tABCU-5710RZ\n+HP\t\t1000BASE-SX SFP\t\t\t\t453153-001\n \n-NOTES: If your 82599-based Intel(R) Network Adapter came with Intel optics, or\n-is an Intel(R) Ethernet Server Adapter X520-2, then it only supports Intel\n-optics and/or the direct attach cables listed below.\n+82599-based adapters support all passive and active limiting direct attach\n+cables that comply with SFF-8431 v4.1 and SFF-8472 v10.4 specifications.\n \n-When 82599-based SFP+ devices are connected back to back, they should be set to\n-the same Speed setting via ethtool. Results may vary if you mix speed settings.\n-82598-based adapters support all passive direct attach cables that comply\n-with SFF-8431 v4.1 and SFF-8472 v10.4 specifications. Active direct attach\n-cables are not supported.\n \n-Supplier Type Part Numbers\n+Laser turns off for SFP+ when ifconfig ethX down\n+------------------------------------------------\n \n-SR Modules\n-Intel DUAL RATE 1G/10G SFP+ SR (bailed) FTLX8571D3BCV-IT\n-Intel DUAL RATE 1G/10G SFP+ SR (bailed) AFBR-703SDDZ-IN1\n-Intel DUAL RATE 1G/10G SFP+ SR (bailed) AFBR-703SDZ-IN2\n-LR Modules\n-Intel DUAL RATE 1G/10G SFP+ LR (bailed) FTLX1471D3BCV-IT\n-Intel DUAL RATE 1G/10G SFP+ LR (bailed) AFCT-701SDDZ-IN1\n-Intel DUAL RATE 1G/10G SFP+ LR (bailed) AFCT-701SDZ-IN2\n+\"ifconfig ethX down\" turns off the laser for 82599-based SFP+ fiber adapters.\n+\"ifconfig ethX up\" turns on the laser.\n+Alternatively, you can use \"ip link set [down/up] dev ethX\" to turn the\n+laser off and on.\n \n-The following is a list of 3rd party SFP+ modules and direct attach cables that\n-have received some testing. Not all modules are applicable to all devices.\n \n-Supplier Type Part Numbers\n+82599-based QSFP+ Adapters\n+--------------------------\n \n-Finisar SFP+ SR bailed, 10g single rate FTLX8571D3BCL\n-Avago SFP+ SR bailed, 10g single rate AFBR-700SDZ\n-Finisar SFP+ LR bailed, 10g single rate FTLX1471D3BCL\n+NOTES:\n+- If your 82599-based Intel(R) Network Adapter came with Intel optics, it\n+ only supports Intel optics.\n+- 82599-based QSFP+ adapters only support 4x10 Gbps connections.\n+ 1x40 Gbps connections are not supported. QSFP+ link partners must be\n+ configured for 4x10 Gbps.\n+- 82599-based QSFP+ adapters do not support automatic link speed detection.\n+ The link speed must be configured to either 10 Gbps or 1 Gbps to match the\n+ link partners speed capabilities. Incorrect speed configurations will result\n+ in failure to link.\n+- Intel(R) Ethernet Converged Network Adapter X520-Q1 only supports the\n+ optics and direct attach cables listed below.\n \n-Finisar DUAL RATE 1G/10G SFP+ SR (No Bail) FTLX8571D3QCV-IT\n-Avago DUAL RATE 1G/10G SFP+ SR (No Bail) AFBR-703SDZ-IN1\n-Finisar DUAL RATE 1G/10G SFP+ LR (No Bail) FTLX1471D3QCV-IT\n-Avago DUAL RATE 1G/10G SFP+ LR (No Bail) AFCT-701SDZ-IN1\n-Finistar 1000BASE-T SFP FCLF8522P2BTL\n-Avago 1000BASE-T SFP ABCU-5710RZ\n \n-82599-based adapters support all passive and active limiting direct attach\n-cables that comply with SFF-8431 v4.1 and SFF-8472 v10.4 specifications.\n+Supplier\tType\t\t\t\tPart Numbers\n+--------\t----\t\t\t\t------------\n+Intel\tDUAL RATE 1G/10G QSFP+ SRL (bailed)\tE10GQSFPSR\n \n-Laser turns off for SFP+ when device is down\n--------------------------------------------\n-\"ip link set down\" turns off the laser for 82599-based SFP+ fiber adapters.\n-\"ip link set up\" turns on the laser.\n+82599-based QSFP+ adapters support all passive and active limiting QSFP+\n+direct attach cables that comply with SFF-8436 v4.1 specifications.\n \n \n 82598-BASED ADAPTERS\n+--------------------\n \n-NOTES for 82598-Based Adapters:\n-- Intel(R) Network Adapters that support removable optical modules only support\n- their original module type (i.e., the Intel(R) 10 Gigabit SR Dual Port\n- Express Module only supports SR optical modules). If you plug in a different\n- type of module, the driver will not load.\n+NOTES:\n+- Intel(r) Ethernet Network Adapters that support removable optical modules\n+ only support their original module type (for example, the Intel(R) 10 Gigabit\n+ SR Dual Port Express Module only supports SR optical modules). If you plug\n+ in a different type of module, the driver will not load.\n - Hot Swapping/hot plugging optical modules is not supported.\n - Only single speed, 10 gigabit modules are supported.\n - LAN on Motherboard (LOMs) may support DA, SR, or LR modules. Other module\n types are not supported. Please see your system documentation for details.\n \n-The following is a list of 3rd party SFP+ modules and direct attach cables that\n-have received some testing. Not all modules are applicable to all devices.\n-\n-Supplier Type Part Numbers\n-\n-Finisar SFP+ SR bailed, 10g single rate FTLX8571D3BCL\n-Avago SFP+ SR bailed, 10g single rate AFBR-700SDZ\n-Finisar SFP+ LR bailed, 10g single rate FTLX1471D3BCL\n-\n-82598-based adapters support all passive direct attach cables that comply\n-with SFF-8431 v4.1 and SFF-8472 v10.4 specifications. Active direct attach\n-cables are not supported.\n+ The following is a list of SFP+ modules and direct attach cables that have\n+ received some testing. Not all modules are applicable to all devices.\n+\n+Supplier\tType\t\t\t\t\tPart Numbers\n+--------\t----\t\t\t\t\t------------\n+Finisar\t\tSFP+ SR bailed, 10g single\n+rate\t\tFTLX8571D3BCL\n+Avago\t\tSFP+ SR bailed, 10g single rate\t\tAFBR-700SDZ\n+Finisar\t\tSFP+ LR bailed, 10g single\n+rate\t\tFTLX1471D3BCL\n+\n+82598-based adapters support all passive direct attach cables that comply with\n+SFF-8431 v4.1 and SFF-8472 v10.4 specifications. Active direct attach cables\n+are not supported.\n+\n+Third party optic modules and cables referred to above are listed only for the\n+purpose of highlighting third party specifications and potential\n+compatibility, and are not recommendations or endorsements or sponsorship of\n+any third party's product by Intel. Intel is not endorsing or promoting\n+products made by any third party and the third party reference is provided\n+only to share information regarding certain optic modules and cables with the\n+above specifications. There may be other manufacturers or suppliers, producing\n+or supplying optic modules and cables with similar or matching descriptions.\n+Customers must use their own discretion and diligence to purchase optic\n+modules and cables from any third party of their choice. Customers are solely\n+responsible for assessing the suitability of the product and/or devices and\n+for the selection of the vendor for purchasing any product. THE OPTIC MODULES\n+AND CABLES REFERRED TO ABOVE ARE NOT WARRANTED OR SUPPORTED BY INTEL. INTEL\n+ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED\n+WARRANTY, RELATING TO SALE AND/OR USE OF SUCH THIRD PARTY PRODUCTS OR\n+SELECTION OF VENDOR BY CUSTOMERS.\n \n \n Flow Control\n ------------\n Ethernet Flow Control (IEEE 802.3x) can be configured with ethtool to enable\n-receiving and transmitting pause frames for ixgbe. When TX is enabled, PAUSE\n-frames are generated when the receive packet buffer crosses a predefined\n-threshold. When rx is enabled, the transmit unit will halt for the time delay\n-specified when a PAUSE frame is received.\n+receiving and transmitting pause frames for ixgbe. When transmit is enabled,\n+pause frames are generated when the receive packet buffer crosses a predefined\n+threshold. When receive is enabled, the transmit unit will halt for the time\n+delay specified when a pause frame is received.\n+\n+NOTE: You must have a flow control capable link partner.\n+\n+Flow Control is enabled by default.\n+\n+Use ethtool to change the flow control settings.\n \n-Flow Control is enabled by default. If you want to disable a flow control\n-capable link partner, use ethtool:\n+To enable or disable rx or tx Flow Control:\n+ethtool -A eth? rx <on|off> tx <on|off>\n+Note: This command only enables or disables Flow Control if auto-negotiation is\n+disabled. If auto-negotiation is enabled, this command changes the parameters\n+used for auto-negotiation with the link partner.\n \n- ethtool -A eth? autoneg off RX off TX off\n+To enable or disable auto-negotiation:\n+ethtool -s eth? autoneg <on|off>\n+Note: Flow Control auto-negotiation is part of link auto-negotiation. Depending\n+on your device, you may not be able to change the auto-negotiation setting.\n+\n+NOTE: For 82598 backplane cards entering 1 gigabit mode, flow control default\n+behavior is changed to off. Flow control in 1 gigabit mode on these devices can\n+lead to transmit hangs.\n \n-NOTE: For 82598 backplane cards entering 1 gig mode, flow control default\n-behavior is changed to off. Flow control in 1 gig mode on these devices can\n-lead to Tx hangs.\n \n Intel(R) Ethernet Flow Director\n -------------------------------\n-Supports advanced filters that direct receive packets by their flows to\n-different queues. Enables tight control on routing a flow in the platform.\n-Matches flows and CPU cores for flow affinity. Supports multiple parameters\n-for flexible flow classification and load balancing.\n+The Intel Ethernet Flow Director performs the following tasks:\n \n-Flow director is enabled only if the kernel is multiple TX queue capable.\n+- Directs receive packets according to their flows to different queues.\n+- Enables tight control on routing a flow in the platform.\n+- Matches flows and CPU cores for flow affinity.\n+- Supports multiple parameters for flexible flow classification and load\n+ balancing (in SFP mode only).\n \n-An included script (set_irq_affinity.sh) automates setting the IRQ to CPU\n+NOTE: An included script (set_irq_affinity) automates setting the IRQ to CPU\n affinity.\n \n-You can verify that the driver is using Flow Director by looking at the counter\n-in ethtool: fdir_miss and fdir_match.\n+NOTE: Intel Ethernet Flow Director masking works in the opposite manner from\n+subnet masking. In the following command:\n+ #ethtool -N eth11 flow-type ip4 src-ip 172.4.1.2 m 255.0.0.0 dst-ip \\\n+ 172.21.1.1 m 255.128.0.0 action 31\n+The src-ip value that is written to the filter will be 0.4.1.2, not 172.0.0.0\n+as might be expected. Similarly, the dst-ip value written to the filter will be\n+0.21.1.1, not 172.0.0.0.\n+\n+ethtool commands:\n+\n+To enable or disable the Intel Ethernet Flow Director:\n+\n+ # ethtool -K ethX ntuple <on|off>\n+\n+When disabling ntuple filters, all the user programed filters are flushed from\n+the driver cache and hardware. All needed filters must be re-added when ntuple\n+is re-enabled.\n+\n+To add a filter that directs packet to queue 2, use -U or -N switch:\n+\n+ # ethtool -N ethX flow-type tcp4 src-ip 192.168.10.1 dst-ip \\\n+ 192.168.10.2 src-port 2000 dst-port 2001 action 2 [loc 1]\n \n-Other ethtool Commands:\n-To enable Flow Director\n-\tethtool -K ethX ntuple on\n-To add a filter\n-\tUse -U switch. e.g., ethtool -U ethX flow-type tcp4 src-ip 10.0.128.23\n- action 1\n To see the list of filters currently present:\n-\tethtool -u ethX\n+ # ethtool <-u|-n> ethX\n+\n+\n+Perfect Filter\n+--------------\n+\n+Perfect filter is an interface to load the filter table that funnels all\n+traffic through RSS for queue assignment unless an alternative queue is\n+specified using \"action\". In that case, any traffic flow that matches the\n+filter criteria is directed to the specified queue.\n \n-Perfect Filter: Perfect filter is an interface to load the filter table that\n-funnels all flow into queue_0 unless an alternative queue is specified using\n-\"action\". In that case, any flow that matches the filter criteria will be\n-directed to the appropriate queue.\n+Support for Virtual Function (VF) is through the user data field. ethtool must\n+be updated to the version built for the 2.6.40 kernel. Perfect Filter is\n+supported on all kernels 2.6.30 and later. Rules may be deleted from the table\n+itself. This is done using \"ethtool -U ethX delete N\", where N is the rule\n+number to be deleted.\n \n-If the queue is defined as -1, filter will drop matching packets.\n+NOTE: Flow Director Perfect Filters can run in single queue mode when SR-IOV\n+is enabled or when DCB is enabled.\n+\n+If the queue is defined as -1, the filter will drop matching packets.\n \n To account for filter matches and misses, there are two stats in ethtool:\n fdir_match and fdir_miss. In addition, rx_queue_N_packets shows the number of\n packets processed by the Nth queue.\n \n-NOTE: Receive Packet Steering (RPS) and Receive Flow Steering (RFS) are not\n-compatible with Flow Director. IF Flow Director is enabled, these will be\n-disabled.\n-\n-The following three parameters impact Flow Director.\n-\n-FdirMode\n---------\n-Valid Range: 0-2 (0=off, 1=ATR, 2=Perfect filter mode)\n-Default Value: 1\n+NOTES:\n+- Receive Packet Steering (RPS) and Receive Flow Steering (RFS) are not\n+ compatible with Flow Director. If Flow Director is enabled, these will be\n+ disabled\n+- For VLAN Masks only four masks are supported.\n+- Once a rule is defined, you must supply the same fields and masks (if\n+ masks are specified).\n \n- Flow Director filtering modes.\n \n FdirPballoc\n -----------\n-Valid Range: 0-2 (0=64k, 1=128k, 2=256k)\n-Default Value: 0\n+Valid Range: 1-3\n+Specifies the Flow Director allocated packet buffer size.\n+1 = 64k\n+2 = 128k\n+3 = 256k\n \n- Flow Director allocated packet buffer size.\n \n AtrSampleRate\n---------------\n-Valid Range: 1-100\n-Default Value: 20\n+-------------\n+Valid Range: 0-255\n+This parameter is used with the Flow Director and is the software ATR transmit\n+packet sample rate. For example, when AtrSampleRate is set to 20, every 20th\n+packet looks to see if the packet will create a new flow. A value of 0\n+indicates that ATR should be disabled and no samples will be taken.\n \n- Software ATR Tx packet sample rate. For example, when set to 20, every 20th\n- packet, looks to see if the packet will create a new flow.\n \n Node\n ----\n-Valid Range: 0-n\n-Default Value: 1 (off)\n-\n- 0 - n: where n is the number of NUMA nodes (i.e. 0 - 3) currently online in\n- your system\n- 1: turns this option off\n+Valid Range: 0-n\n+0 - n: where n is the number of the NUMA node that should be used to allocate\n+memory for this adapter port.\n+-1: uses the driver default of allocating memory on whichever processor is\n+running modprobe.\n+The Node parameter allows you to choose which NUMA node you want to have the\n+adapter allocate memory from. All driver structures, in-memory queues, and\n+receive buffers will be allocated on the node specified. This parameter is\n+only useful when interrupt affinity is specified; otherwise, part of the\n+interrupt time could run on a different core than where the memory is\n+allocated causing slower memory access and impacting throughput, CPU, or both.\n \n- The Node parameter will allow you to pick which NUMA node you want to have\n- the adapter allocate memory on.\n \n max_vfs\n -------\n-Valid Range: 1-63\n-Default Value: 0\n-\n- If the value is greater than 0 it will also force the VMDq parameter to be 1\n- or more.\n-\n- This parameter adds support for SR-IOV. It causes the driver to spawn up to\n- max_vfs worth of virtual function.\n+This parameter adds support for SR-IOV. It causes the driver to spawn up to\n+max_vfs worth of virtual functions.\n+Valid Range: 1-63\n+If the value is greater than 0 it will also force the VMDq parameter to be 1 or\n+more.\n+\n+NOTE: This parameter is only used on kernel 3.7.x and below. On kernel 3.8.x\n+and above, use sysfs to enable VFs. Also, for Red Hat distributions, this\n+parameter is only used on version 6.6 and older. For version 6.7 and newer, use\n+sysfs. For example:\n+#echo $num_vf_enabled > /sys/class/net/$dev/device/sriov_numvfs\t//enable\n+VFs\n+#echo 0 > /sys/class/net/$dev/device/sriov_numvfs\t//disable VFs\n+\n+The parameters for the driver are referenced by position. Thus, if you have a\n+dual port adapter, or more than one adapter in your system, and want N virtual\n+functions per port, you must specify a number for each port with each parameter\n+separated by a comma. For example:\n+\n+ modprobe ixgbe max_vfs=4\n+\n+This will spawn 4 VFs on the first port.\n+\n+ modprobe ixgbe max_vfs=2,4\n+\n+This will spawn 2 VFs on the first port and 4 VFs on the second port.\n+\n+NOTE: Caution must be used in loading the driver with these parameters.\n+Depending on your system configuration, number of slots, etc., it is impossible\n+to predict in all cases where the positions would be on the command line.\n+\n+NOTE: Neither the device nor the driver control how VFs are mapped into config\n+space. Bus layout will vary by operating system. On operating systems that\n+support it, you can check sysfs to find the mapping.\n+\n+\n+NOTE: When either SR-IOV mode or VMDq mode is enabled, hardware VLAN filtering\n+and VLAN tag stripping/insertion will remain enabled. Please remove the old\n+VLAN filter before the new VLAN filter is added. For example,\n+ip link set eth0 vf 0 vlan 100\t// set vlan 100 for VF 0\n+ip link set eth0 vf 0 vlan 0\t// Delete vlan 100\n+ip link set eth0 vf 0 vlan 200\t// set a new vlan 200 for VF 0\n+\n+With kernel 3.6, the driver supports the simultaneous usage of max_vfs and DCB\n+features, subject to the constraints described below. Prior to kernel 3.6, the\n+driver did not support the simultaneous operation of max_vfs greater than 0 and\n+the DCB features (multiple traffic classes utilizing Priority Flow Control and\n+Extended Transmission Selection).\n+\n+When DCB is enabled, network traffic is transmitted and received through\n+multiple traffic classes (packet buffers in the NIC). The traffic is associated\n+with a specific class based on priority, which has a value of 0 through 7 used\n+in the VLAN tag. When SR-IOV is not enabled, each traffic class is associated\n+with a set of receive/transmit descriptor queue pairs. The number of queue\n+pairs for a given traffic class depends on the hardware configuration. When\n+SR-IOV is enabled, the descriptor queue pairs are grouped into pools. The\n+Physical Function (PF) and each Virtual Function (VF) is allocated a pool of\n+receive/transmit descriptor queue pairs. When multiple traffic classes are\n+configured (for example, DCB is enabled), each pool contains a queue pair from\n+each traffic class. When a single traffic class is configured in the hardware,\n+the pools contain multiple queue pairs from the single traffic class.\n+\n+The number of VFs that can be allocated depends on the number of traffic\n+classes that can be enabled. The configurable number of traffic classes for\n+each enabled VF is as follows:\n+0 - 15 VFs = Up to 8 traffic classes, depending on device support\n+16 - 31 VFs = Up to 4 traffic classes\n+32 - 63 VFs = 1 traffic class\n+\n+When VFs are configured, the PF is allocated one pool as well. The PF supports\n+the DCB features with the constraint that each traffic class will only use a\n+single queue pair. When zero VFs are configured, the PF can support multiple\n+queue pairs per traffic class.\n+\n+\n+Additional Features and Configurations\n+-------------------------------------------\n \n \n-Additional Configurations\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- Jumbo Frames\n- ------------\n- The driver supports Jumbo Frames for all adapters. Jumbo Frames support is\n- enabled by changing the MTU to a value larger than the default of 1500.\n- The maximum value for the MTU is 16110. Use the ip command to\n- increase the MTU size. For example:\n+Use the ifconfig command to increase the MTU size. For example, enter the\n+following where <x> is the interface number:\n \n- ip link set dev ethx mtu 9000\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- The maximum MTU setting for Jumbo Frames is 9710. This value coincides\n- with the maximum Jumbo Frames size of 9728.\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- Generic Receive Offload, aka GRO\n- --------------------------------\n- The driver supports the in-kernel software implementation of GRO. GRO has\n- shown that by coalescing Rx traffic into larger chunks of data, CPU\n- utilization can be significantly reduced when under large Rx load. GRO is an\n- evolution of the previously-used LRO interface. GRO is able to coalesce\n- other protocols besides TCP. It's also safe to use with configurations that\n- are problematic for LRO, namely bridging and iSCSI.\n+NOTE: The maximum MTU setting for Jumbo Frames is 9710. This value coincides\n+with the maximum Jumbo Frames size of 9728 bytes.\n \n- Data Center Bridging, aka DCB\n- -----------------------------\n- DCB is a configuration Quality of Service implementation in hardware.\n- It uses the VLAN priority tag (802.1p) to filter traffic. That means\n- that there are 8 different priorities that traffic can be filtered into.\n- It also enables priority flow control which can limit or eliminate the\n- number of dropped packets during network stress. Bandwidth can be\n- allocated to each of these priorities, which is enforced at the hardware\n- level.\n+NOTE: This driver will attempt to use multiple page sized buffers to receive\n+each jumbo packet. This should help to avoid buffer starvation issues when\n+allocating receive packets.\n \n- To enable DCB support in ixgbe, you must enable the DCB netlink layer to\n- allow the userspace tools (see below) to communicate with the driver.\n- This can be found in the kernel configuration here:\n+NOTE: For 82599-based network connections, if you are enabling jumbo frames in\n+a virtual function (VF), jumbo frames must first be enabled in the physical\n+function (PF). The VF MTU setting cannot be larger than the PF MTU.\n \n- -> Networking support\n- -> Networking options\n- -> Data Center Bridging support\n \n- Once this is selected, DCB support must be selected for ixgbe. This can\n- be found here:\n+Generic Receive Offload, aka GRO\n+--------------------------------\n \n- -> Device Drivers\n- -> Network device support (NETDEVICES [=y])\n- -> Ethernet (10000 Mbit) (NETDEV_10000 [=y])\n- -> Intel(R) 10GbE PCI Express adapters support\n- -> Data Center Bridging (DCB) Support\n+The driver supports the in-kernel software implementation of GRO. GRO has\n+shown that by coalescing Rx traffic into larger chunks of data, CPU\n+utilization can be significantly reduced when under large Rx load. GRO is an\n+evolution of the previously-used LRO interface. GRO is able to coalesce\n+other protocols besides TCP. It's also safe to use with configurations that\n+are problematic for LRO, namely bridging and iSCSI.\n \n- After these options are selected, you must rebuild your kernel and your\n- modules.\n \n- In order to use DCB, userspace tools must be downloaded and installed.\n- The dcbd tools can be found at:\n+Data Center Bridging (DCB)\n+--------------------------\n \n- http://e1000.sf.net\n+NOTE:\n+The kernel assumes that TC0 is available, and will disable Priority Flow\n+Control (PFC) on the device if TC0 is not available. To fix this, ensure TC0 is\n+enabled when setting up DCB on your switch.\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\n- ethtool version is required for this functionality.\n \n- The latest release of ethtool can be found from\n- https://www.kernel.org/pub/software/network/ethtool/\n+DCB is a configuration Quality of Service implementation in hardware. It uses\n+the VLAN priority tag (802.1p) to filter traffic. That means that there are 8\n+different priorities that traffic can be filtered into. It also enables\n+priority flow control (802.1Qbb) which can limit or eliminate the number of\n+dropped packets during network stress. Bandwidth can be allocated to each of\n+these priorities, which is enforced at the hardware level (802.1Qaz).\n \n- FCoE\n- ----\n- This release of the ixgbe driver contains new code to enable users to use\n- Fiber Channel over Ethernet (FCoE) and Data Center Bridging (DCB)\n- functionality that is supported by the 82598-based hardware. This code has\n- no default effect on the regular driver operation, and configuring DCB and\n- FCoE is outside the scope of this driver README. Refer to\n- http://www.open-fcoe.org/ for FCoE project information and contact\n- e1000-eedc@lists.sourceforge.net for DCB information.\n+Adapter firmware implements LLDP and DCBX protocol agents as per 802.1AB and\n+802.1Qaz respectively. The firmware based DCBX agent runs in willing mode only\n+and can accept settings from a DCBX capable peer. Software configuration of\n+DCBX parameters via dcbtool/lldptool are not supported.\n \n- MAC and VLAN anti-spoofing feature\n- ----------------------------------\n- When a malicious driver attempts to send a spoofed packet, it is dropped by\n- the hardware and not transmitted. An interrupt is sent to the PF driver\n- notifying it of the spoof attempt.\n+The ixgbe driver implements the DCB netlink interface layer to allow user-space\n+to communicate with the driver and query DCB configuration for the port.\n \n- When a spoofed packet is detected the PF driver will send the following\n- message to the system log (displayed by the \"dmesg\" command):\n \n- Spoof event(s) detected on VF (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- Where n=the VF that attempted to do the spoofing.\n \n+FCoE\n+----\n \n-Performance Tuning\n-==================\n+This release of the ixgbe driver contains new code to enable users to use\n+Fiber Channel over Ethernet (FCoE) and Data Center Bridging (DCB)\n+functionality that is supported by the 82598-based hardware. This code has\n+no default effect on the regular driver operation, and configuring DCB and\n+FCoE is outside the scope of this driver README. Refer to\n+http://www.open-fcoe.org/ for FCoE project information and contact\n+ixgbe-eedc@lists.sourceforge.net for DCB information.\n \n-An excellent article on performance tuning can be found at:\n \n-http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf\n+MAC and VLAN anti-spoofing feature\n+----------------------------------\n \n+When a malicious driver attempts to send a spoofed packet, it is dropped by the\n+hardware and not transmitted.\n \n-Known Issues\n-============\n+An interrupt is sent to the PF driver notifying it of the spoof attempt. When a\n+spoofed packet is detected, the PF driver will send the following message to\n+the system log (displayed by the \"dmesg\" command):\n+ixgbe ethX: ixgbe_spoof_check: n spoofed packets detected\n+where \"x\" is the PF interface number; and \"n\" is number of spoofed packets.\n+NOTE: This feature can be disabled for a specific Virtual Function (VF):\n+ip link set <pf dev> vf <vf id> spoofchk {off|on}\n \n- Enabling SR-IOV in a 32-bit or 64-bit Microsoft* Windows* Server 2008/R2\n- Guest OS using Intel (R) 82576-based GbE or Intel (R) 82599-based 10GbE\n- controller under KVM\n- ------------------------------------------------------------------------\n- KVM Hypervisor/VMM supports direct assignment of a PCIe device to a VM. This\n- includes traditional PCIe devices, as well as SR-IOV-capable devices using\n- Intel 82576-based and 82599-based controllers.\n \n- While direct assignment of a PCIe device or an SR-IOV Virtual Function (VF)\n- to a Linux-based VM running 2.6.32 or later kernel works fine, there is a\n- known issue with Microsoft Windows Server 2008 VM that results in a \"yellow\n- bang\" error. This problem is within the KVM VMM itself, not the Intel driver,\n- or the SR-IOV logic of the VMM, but rather that KVM emulates an older CPU\n- model for the guests, and this older CPU model does not support MSI-X\n- interrupts, which is a requirement for Intel SR-IOV.\n+Known Issues/Troubleshooting\n+----------------------------\n \n- If you wish to use the Intel 82576 or 82599-based controllers in SR-IOV mode\n- with KVM and a Microsoft Windows Server 2008 guest try the following\n- workaround. The workaround is to tell KVM to emulate a different model of CPU\n- when using qemu to create the KVM guest:\n \n- \"-cpu qemu64,model=13\"\n+Enabling SR-IOV in a 64-bit Microsoft* Windows Server* 2012/R2 guest OS under\n+Linux KVM\n+--------------------------------------------------------------------------------\n+KVM Hypervisor/VMM supports direct assignment of a PCIe device to a VM. This\n+includes traditional PCIe devices, as well as SR-IOV-capable devices based on\n+the Intel Ethernet Controller XL710.\n \n \n Support\n-=======\n-\n+-------\n For general information, go to the Intel support website at:\n-\n- http://support.intel.com\n+www.intel.com/support/\n \n or the Intel Wired Networking project hosted by Sourceforge at:\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 \n- http://e1000.sourceforge.net\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/ixgbevf.txt b/Documentation/networking/ixgbevf.txt\nindex 53d8d2a5a6a3..1e88318d43c2 100644\n--- a/Documentation/networking/ixgbevf.txt\n+++ b/Documentation/networking/ixgbevf.txt\n@@ -2,7 +2,7 @@ Linux* Base 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-2016 Intel Corporation.\n \n Contents\n ========\n@@ -11,42 +11,61 @@ Contents\n - Known Issues/Troubleshooting\n - Support\n \n-This file describes the ixgbevf Linux* Base Driver for Intel Network\n-Connection.\n+This virtual function driver supports kernel versions 2.6.x and newer.\n \n-The ixgbevf driver supports 82599-based virtual function devices that can only\n-be activated on kernels with CONFIG_PCI_IOV enabled.\n+This driver supports 82599, X540, X550, and X552-based virtual function devices\n+that can only be activated on kernels that support SR-IOV.\n \n-The ixgbevf driver supports virtual functions generated by the ixgbe driver\n-with a max_vfs value of 1 or greater.\n+SR-IOV requires the correct platform and OS support.\n \n-The guest OS loading the ixgbevf driver must support MSI-X interrupts.\n+The guest OS loading this driver must support MSI-X interrupts.\n+\n+This driver is only supported as a loadable module at this time. Intel is not\n+supplying patches against the kernel source to allow for static linking of the\n+drivers.\n+\n+For questions related to hardware requirements, refer to the documentation\n+supplied with your Intel adapter. All hardware requirements listed apply to use\n+with Linux.\n+\n+Driver information can be obtained using variable_value_undefined. Instructions\n+on updating ethtool can be found in the section Additional Configurations later\n+in this document.\n+\n+VLANs: There is a limit of a total of 64 shared VLANs to 1 or more VFs.\n+\n+A version of the driver may already be included by your\n+distribution and/or the kernel.org kernel.\n \n-VLANs: There is a limit of a total of 32 shared VLANs to 1 or more VFs.\n \n Identifying Your Adapter\n-========================\n+------------------------\n+The driver is compatible with devices based on the following:\n+ * Intel(R) Ethernet Controller 82598\n+ * Intel(R) Ethernet Controller 82599\n+ * Intel(R) Ethernet Controller X540\n+ * Intel(R) Ethernet Controller x550\n+ * Intel(R) Ethernet Controller X552\n+ * Intel(R) Ethernet Controller X553\n \n-For more information on how to identify your adapter, go to the Adapter &\n-Driver ID Guide at:\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- http://support.intel.com/support/go/network/adapter/idguide.htm\n \n Known Issues/Troubleshooting\n-============================\n+----------------------------\n \n \n Support\n-=======\n-\n+-------\n For general information, go to the Intel support website at:\n-\n- http://support.intel.com\n+www.intel.com/support/\n \n or the Intel Wired Networking project hosted by Sourceforge at:\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 \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", "prefixes": [ "net-next" ] }