Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/897809/?format=api
{ "id": 897809, "url": "http://patchwork.ozlabs.org/api/patches/897809/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/patch/20180412221920.11109-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": "<20180412221920.11109-1-jeffrey.t.kirsher@intel.com>", "list_archive_url": null, "date": "2018-04-12T22:19:20", "name": "[v2] Documentation: ixgbe: Update kernel documentation", "commit_ref": null, "pull_url": null, "state": "changes-requested", "archived": false, "hash": "01c09fe53fab1b08875d056e64193156e8d88462", "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/20180412221920.11109-1-jeffrey.t.kirsher@intel.com/mbox/", "series": [ { "id": 38719, "url": "http://patchwork.ozlabs.org/api/series/38719/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/list/?series=38719", "date": "2018-04-12T22:19:20", "name": "[v2] Documentation: ixgbe: Update kernel documentation", "version": 2, "mbox": "http://patchwork.ozlabs.org/series/38719/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/897809/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/897809/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<intel-wired-lan-bounces@osuosl.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "intel-wired-lan@lists.osuosl.org" ], "Delivered-To": [ "patchwork-incoming@bilbo.ozlabs.org", "intel-wired-lan@lists.osuosl.org" ], "Authentication-Results": [ "ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.138; helo=whitealder.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=<UNKNOWN>)", "ozlabs.org;\n\tdmarc=none (p=none dis=none) header.from=intel.com" ], "Received": [ "from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 40Mb0G1ZLwz9s19\n\tfor <incoming@patchwork.ozlabs.org>;\n\tFri, 13 Apr 2018 08:18:38 +1000 (AEST)", "from localhost (localhost [127.0.0.1])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 82BDB88709;\n\tThu, 12 Apr 2018 22:18: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 FqmGCiQVJCro; Thu, 12 Apr 2018 22:18:30 +0000 (UTC)", "from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby whitealder.osuosl.org (Postfix) with ESMTP id 227C8886FB;\n\tThu, 12 Apr 2018 22:18:30 +0000 (UTC)", "from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\tby ash.osuosl.org (Postfix) with ESMTP id 373771C0B9E\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tThu, 12 Apr 2018 22:18:28 +0000 (UTC)", "from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 2ECD0878BA\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tThu, 12 Apr 2018 22:18:28 +0000 (UTC)", "from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id rMdWTdXZGgzV for <intel-wired-lan@lists.osuosl.org>;\n\tThu, 12 Apr 2018 22:18:25 +0000 (UTC)", "from mga05.intel.com (mga05.intel.com [192.55.52.43])\n\tby fraxinus.osuosl.org (Postfix) with ESMTPS id C17F3876B6\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tThu, 12 Apr 2018 22:18:25 +0000 (UTC)", "from fmsmga001.fm.intel.com ([10.253.24.23])\n\tby fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t12 Apr 2018 15:18:25 -0700", "from jtkirshe-nuc.jf.intel.com ([134.134.177.59])\n\tby fmsmga001.fm.intel.com with ESMTP; 12 Apr 2018 15:18:25 -0700" ], "X-Virus-Scanned": [ "amavisd-new at osuosl.org", "amavisd-new at osuosl.org" ], "X-Greylist": "domain auto-whitelisted by SQLgrey-1.7.6", "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.48,443,1517904000\"; d=\"scan'208\";a=\"46498254\"", "From": "Jeff Kirsher <jeffrey.t.kirsher@intel.com>", "To": "intel-wired-lan@lists.osuosl.org", "Date": "Thu, 12 Apr 2018 15:19:20 -0700", "Message-Id": "<20180412221920.11109-1-jeffrey.t.kirsher@intel.com>", "X-Mailer": "git-send-email 2.14.3", "Subject": "[Intel-wired-lan] [PATCH v2] Documentation: ixgbe: Update kernel\n\tdocumentation", "X-BeenThere": "intel-wired-lan@osuosl.org", "X-Mailman-Version": "2.1.24", "Precedence": "list", "List-Id": "Intel Wired Ethernet Linux Kernel Driver Development\n\t<intel-wired-lan.osuosl.org>", "List-Unsubscribe": "<https://lists.osuosl.org/mailman/options/intel-wired-lan>, \n\t<mailto:intel-wired-lan-request@osuosl.org?subject=unsubscribe>", "List-Archive": "<http://lists.osuosl.org/pipermail/intel-wired-lan/>", "List-Post": "<mailto:intel-wired-lan@osuosl.org>", "List-Help": "<mailto:intel-wired-lan-request@osuosl.org?subject=help>", "List-Subscribe": "<https://lists.osuosl.org/mailman/listinfo/intel-wired-lan>, \n\t<mailto:intel-wired-lan-request@osuosl.org?subject=subscribe>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "7bit", "Errors-To": "intel-wired-lan-bounces@osuosl.org", "Sender": "\"Intel-wired-lan\" <intel-wired-lan-bounces@osuosl.org>" }, "content": "Updated the ixgbe.txt kernel documentation with the latest information.\n\nSigned-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>\n---\nv2: fixed up documentation based on community feedback and internal\n review\n\n---\n Documentation/networking/ixgbe.txt | 684 ++++++++++++++++++++++++-------------\n 1 file changed, 443 insertions(+), 241 deletions(-)", "diff": "diff --git a/Documentation/networking/ixgbe.txt b/Documentation/networking/ixgbe.txt\nindex 687835415707..c8908c311610 100644\n--- a/Documentation/networking/ixgbe.txt\n+++ b/Documentation/networking/ixgbe.txt\n@@ -2,12 +2,11 @@ Linux* Base Driver for the Intel(R) Ethernet 10 Gigabit PCI Express Family of\n Adapters\n =============================================================================\n \n-Intel 10 Gigabit Linux driver.\n-Copyright(c) 1999 - 2013 Intel Corporation.\n+March 15, 2018\n+Copyright(c) 1999-2018 Intel Corporation.\n \n Contents\n ========\n-\n - Identifying Your Adapter\n - Additional Configurations\n - Performance Tuning\n@@ -15,335 +14,538 @@ 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 X520\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. If you want to disable a flow control\n-capable link partner, use ethtool:\n+Flow Control is enabled by default.\n \n- ethtool -A eth? autoneg off RX off TX off\n+Use ethtool to change the flow control settings.\n+\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+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-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 commands:\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+To enable or disable the Intel Ethernet Flow Director:\n \n-If the queue is defined as -1, filter will drop matching packets.\n+ # ethtool -K ethX ntuple <on|off>\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+When disabling ntuple filters, all the user programmed 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-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+To add a filter that directs packet to queue 2, use -U or -N switch:\n \n-The following three parameters impact Flow Director.\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-FdirMode\n---------\n-Valid Range: 0-2 (0=off, 1=ATR, 2=Perfect filter mode)\n-Default Value: 1\n+To see the list of filters currently present:\n+ # ethtool <-u|-n> ethX\n+\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 ixgbe driver, 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- 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+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- 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-\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-\n-\n-Additional Configurations\n-=========================\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-\n- ip link set dev ethx mtu 9000\n-\n- The maximum MTU setting for Jumbo Frames is 9710. This value coincides\n- with the maximum Jumbo Frames size of 9728.\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+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+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- 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+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- 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+Use the ifconfig command to increase the MTU size. For example, enter the\n+following where <x> is the interface number:\n \n- -> Networking support\n- -> Networking options\n- -> Data Center Bridging support\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- Once this is selected, DCB support must be selected for ixgbe. This can\n- be found here:\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- -> 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+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- After these options are selected, you must rebuild your kernel and your\n- modules.\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- In order to use DCB, userspace tools must be downloaded and installed.\n- The dcbd tools can be found at:\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- http://e1000.sf.net\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+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 \n- The latest release of ethtool can be found from\n- https://www.kernel.org/pub/software/network/ethtool/\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+Data Center Bridging (DCB)\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- 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 \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+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- Spoof event(s) detected on VF (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- Where n=the VF that attempted to do the spoofing.\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 \n-Performance Tuning\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-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+FCoE\n+----\n+The ixgbe driver supports Fiber Channel over Ethernet (FCoE) and Data Center\n+Bridging (DCB). This code has no default effect on the regular driver\n+operation. Configuring DCB and FCoE is outside the scope of this README. Refer\n+to http://www.open-fcoe.org/ for FCoE project information and contact\n+ixgbe-eedc@lists.sourceforge.net for DCB information.\n \n \n-Known Issues\n-============\n+MAC and VLAN anti-spoofing feature\n+----------------------------------\n+When a malicious driver attempts to send a spoofed packet, it is dropped by the\n+hardware and not transmitted.\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+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- 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 \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+Known Issues/Troubleshooting\n+----------------------------\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+http://www.intel.com/support/\n \n or the Intel Wired Networking project hosted by Sourceforge at:\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\n+http://sourceforge.net/projects/e1000\n+If an issue is identified with the released source code on a supported kernel\n+with a supported adapter, email the specific information related to the issue\n+to e1000-devel@lists.sf.net.\n", "prefixes": [ "v2" ] }