Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/982051/?format=api
{ "id": 982051, "url": "http://patchwork.ozlabs.org/api/patches/982051/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/patch/20181010191613.2770-9-jeffrey.t.kirsher@intel.com/", "project": { "id": 46, "url": "http://patchwork.ozlabs.org/api/projects/46/?format=api", "name": "Intel Wired Ethernet development", "link_name": "intel-wired-lan", "list_id": "intel-wired-lan.osuosl.org", "list_email": "intel-wired-lan@osuosl.org", "web_url": "", "scm_url": "", "webscm_url": "", "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<20181010191613.2770-9-jeffrey.t.kirsher@intel.com>", "list_archive_url": null, "date": "2018-10-10T19:16:09", "name": "[v2,08/12] Documentation: i40e: Prepare documentation for RST conversion", "commit_ref": null, "pull_url": null, "state": "changes-requested", "archived": false, "hash": "af738d7b73a0a44810b93e408c2d28e27e8c1f47", "submitter": { "id": 473, "url": "http://patchwork.ozlabs.org/api/people/473/?format=api", "name": "Kirsher, Jeffrey T", "email": "jeffrey.t.kirsher@intel.com" }, "delegate": { "id": 68, "url": "http://patchwork.ozlabs.org/api/users/68/?format=api", "username": "jtkirshe", "first_name": "Jeff", "last_name": "Kirsher", "email": "jeffrey.t.kirsher@intel.com" }, "mbox": "http://patchwork.ozlabs.org/project/intel-wired-lan/patch/20181010191613.2770-9-jeffrey.t.kirsher@intel.com/mbox/", "series": [ { "id": 70094, "url": "http://patchwork.ozlabs.org/api/series/70094/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/list/?series=70094", "date": "2018-10-10T19:16:01", "name": "Intel Wired LAN Documentation Updates", "version": 2, "mbox": "http://patchwork.ozlabs.org/series/70094/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/982051/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/982051/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<intel-wired-lan-bounces@osuosl.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "intel-wired-lan@lists.osuosl.org" ], "Delivered-To": [ "patchwork-incoming@bilbo.ozlabs.org", "intel-wired-lan@lists.osuosl.org" ], "Authentication-Results": [ "ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.136; helo=silver.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=<UNKNOWN>)", "ozlabs.org;\n\tdmarc=fail (p=none dis=none) header.from=intel.com" ], "Received": [ "from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 42VkNm5f8Lz9s55\n\tfor <incoming@patchwork.ozlabs.org>;\n\tThu, 11 Oct 2018 06:16:40 +1100 (AEDT)", "from localhost (localhost [127.0.0.1])\n\tby silver.osuosl.org (Postfix) with ESMTP id 2E7F12E376;\n\tWed, 10 Oct 2018 19:16:39 +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 TiXbLAzHUHhq; Wed, 10 Oct 2018 19:16:30 +0000 (UTC)", "from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby silver.osuosl.org (Postfix) with ESMTP id 7B3812E2F8;\n\tWed, 10 Oct 2018 19:16:30 +0000 (UTC)", "from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\tby ash.osuosl.org (Postfix) with ESMTP id 148771BF429\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tWed, 10 Oct 2018 19:16:22 +0000 (UTC)", "from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 117B985359\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tWed, 10 Oct 2018 19:16:22 +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 joq4H014M_aM for <intel-wired-lan@lists.osuosl.org>;\n\tWed, 10 Oct 2018 19:16:18 +0000 (UTC)", "from mga06.intel.com (mga06.intel.com [134.134.136.31])\n\tby fraxinus.osuosl.org (Postfix) with ESMTPS id A4B3F86B1F\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tWed, 10 Oct 2018 19:16:18 +0000 (UTC)", "from orsmga003.jf.intel.com ([10.7.209.27])\n\tby orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t10 Oct 2018 12:16:17 -0700", "from jtkirshe-desk1.jf.intel.com ([134.134.177.96])\n\tby orsmga003.jf.intel.com with ESMTP; 10 Oct 2018 12:16:16 -0700" ], "X-Virus-Scanned": [ "amavisd-new at osuosl.org", "amavisd-new at osuosl.org" ], "X-Greylist": "domain auto-whitelisted by SQLgrey-1.7.6", "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.54,365,1534834800\"; d=\"scan'208\";a=\"90918135\"", "From": "Jeff Kirsher <jeffrey.t.kirsher@intel.com>", "To": "intel-wired-lan@lists.osuosl.org", "Date": "Wed, 10 Oct 2018 12:16:09 -0700", "Message-Id": "<20181010191613.2770-9-jeffrey.t.kirsher@intel.com>", "X-Mailer": "git-send-email 2.17.1", "In-Reply-To": "<20181010191613.2770-1-jeffrey.t.kirsher@intel.com>", "References": "<20181010191613.2770-1-jeffrey.t.kirsher@intel.com>", "MIME-Version": "1.0", "Subject": "[Intel-wired-lan] [PATCH v2 08/12] Documentation: i40e: Prepare\n\tdocumentation for RST conversion", "X-BeenThere": "intel-wired-lan@osuosl.org", "X-Mailman-Version": "2.1.29", "Precedence": "list", "List-Id": "Intel Wired Ethernet Linux Kernel Driver Development\n\t<intel-wired-lan.osuosl.org>", "List-Unsubscribe": "<https://lists.osuosl.org/mailman/options/intel-wired-lan>, \n\t<mailto:intel-wired-lan-request@osuosl.org?subject=unsubscribe>", "List-Archive": "<http://lists.osuosl.org/pipermail/intel-wired-lan/>", "List-Post": "<mailto:intel-wired-lan@osuosl.org>", "List-Help": "<mailto:intel-wired-lan-request@osuosl.org?subject=help>", "List-Subscribe": "<https://lists.osuosl.org/mailman/listinfo/intel-wired-lan>, \n\t<mailto:intel-wired-lan-request@osuosl.org?subject=subscribe>", "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": "Before making the conversion to the rst (reStructured Text) format, there\nare changes needed to the documentation so that there are no build errors.\n\nAlso fixed old/broken URLs to the correct or updated URL.\n\nSigned-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>\n---\n Documentation/networking/i40e.txt | 837 +++++++++++++++++++++++++-----\n 1 file changed, 714 insertions(+), 123 deletions(-)", "diff": "diff --git a/Documentation/networking/i40e.txt b/Documentation/networking/i40e.txt\nindex c2d6e1824b29..f0c3c8c9d324 100644\n--- a/Documentation/networking/i40e.txt\n+++ b/Documentation/networking/i40e.txt\n@@ -1,190 +1,781 @@\n-Linux Base Driver for the Intel(R) Ethernet Controller XL710 Family\n-===================================================================\n+.. SPDX-License-Identifier: GPL-2.0+\n \n-Intel i40e Linux driver.\n-Copyright(c) 2013 Intel Corporation.\n+Linux* Base Driver for the Intel(R) Ethernet Controller 700 Series\n+==================================================================\n+\n+Intel 40 Gigabit Linux driver.\n+Copyright(c) 1999-2018 Intel Corporation.\n \n Contents\n ========\n \n+- Overview\n - Identifying Your Adapter\n+- Intel(R) Ethernet Flow Director\n - Additional Configurations\n-- Performance Tuning\n - Known Issues\n - Support\n \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+\n Identifying Your Adapter\n ========================\n+The driver is compatible with devices based on the following:\n+\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.\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+https://www.intel.com/support\n+\n+SFP+ and QSFP+ Devices\n+----------------------\n+For information about supported media, refer to this document:\n+https://www.intel.com/content/dam/www/public/us/en/documents/release-notes/xl710-ethernet-controller-feature-matrix.pdf\n+\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. In all cases Intel recommends using Intel\n+Ethernet Optics; other modules may function but are not validated by Intel.\n+Contact Intel for supported media types.\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 systems that do not have adequate airflow to cool the adapter and\n+optical modules, you must use high temperature optical modules.\n+\n+Virtual Functions (VFs)\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+For example, the following instructions will configure PF eth0 and the first VF\n+on VLAN 10::\n+\n+ $ ip link set dev eth0 vf 0 vlan 10\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+\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+\n+::\n+\n+ For promiscuous all:\n+ #ip link set eth2 promisc on\n+ Where eth2 is a VF interface in the VM\n+\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+\n+ #ethtool -set-priv-flags p261p1 vf-true-promisc-support on\n+\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+\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+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: The Linux i40e driver 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 i40e driver allows you to filter traffic based on a\n+user-defined flexible two-byte pattern and offset by using the ethtool user-def\n+and mask fields. Only L3 and L4 flow types are supported for user-defined\n+flexible filters. For a given flow type, you must clear all Intel Ethernet Flow\n+Director filters before changing the input set (for that flow type).\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 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+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 pattern and\n+\"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+\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. For example::\n+\n+ ethtool –K [adapter] ntuple [off|on]\n+\n+If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a\n+TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is\n+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+\n+ ethtool -U <device> flow-type <type> src-ip <ip> dst-ip <ip> src-port <port> \\\n+ dst-port <port> action <queue>\n+\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 traffic)\n+\n+Use the following command to display all of the active filters::\n+\n+ ethtool -u <device>\n+\n+Use the following command to delete a filter::\n+\n+ ethtool -U <device> delete <N>\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+\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 80 action 7\n \n-The driver in this release is compatible with the Intel Ethernet\n-Controller XL710 Family.\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 \n-For more information on how to identify your adapter, go to the Adapter &\n-Driver ID Guide at:\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 \n- http://support.intel.com/support/network/sb/CS-012904.htm\n+Issuing the next two commands, however, is not acceptable, since the first\n+specifies src-ip and the second specifies dst-ip::\n \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 \n-Enabling the driver\n-===================\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-The driver is enabled via the standard kernel configuration system,\n-using the make command:\n+Matching on a sub-portion of a field is not supported by the i40e driver, thus\n+partial mask fields are not supported.\n \n- make config/oldconfig/menuconfig/etc.\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-The driver is located in the menu structure at:\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-\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+For example,\n \n-Additional Configurations\n-=========================\n+::\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+ ... user-def 0x4FFFF ...\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+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- The latest release of ethtool can be found from\n- https://www.kernel.org/pub/software/network/ethtool\n+::\n \n+ flow-type tcp4 ... user-def 0x8BEAF ...\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+would match TCP/IPv4 packets which have the value 0xBEAF 8 bytes into the\n+TCP/IPv4 payload.\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+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- 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+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- ... action 0x800000002 ...\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- Would indicate to direct traffic for Virtual Function 7 (8 minus 1) on queue\n- 2 of that VF.\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- 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+ ... action 0x800000002 ...\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+specifies to direct traffic to Virtual Function 7 (8 minus 1) into queue 2 of\n+that VF.\n \n- As an example,\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- ... user-def 0x4FFFF ....\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- 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+Use ethtool to view and set link-down-on-close, as follows::\n \n- flow-type tcp4 ... user-def 0x8BEAF ....\n+ ethtool --show-priv-flags ethX\n+ ethtool --set-priv-flags ethX link-down-on-close [on|off]\n \n- would match TCP/IPv4 packets which have the value 0xBEAF 8bytes into the\n- TCP/IPv4 payload.\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 \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+ dmesg -n 8\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: This setting is not saved across reboots.\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+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- 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 the ifconfig command to increase the MTU size. For example, enter the\n+following where <x> is the interface number::\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+ ifconfig eth<x> mtu 9000 up\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+Alternatively, you can use the ip command as follows::\n \n- Data Center Bridging (DCB)\n- --------------------------\n- DCB configuration is not currently supported.\n+ ip link set mtu 9000 dev eth<x>\n+ ip link set up dev eth<x>\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+This setting is not saved across reboots. The setting change can be made\n+permanent by adding 'MTU=9000' to the file::\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+ /etc/sysconfig/network-scripts/ifcfg-eth<x> // for RHEL\n+ /etc/sysconfig/network/<config_file> // for SLES\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+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- Spoof event(s) detected on VF (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- Where n=the VF that attempted to do the spoofing.\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+https://www.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-Performance Tuning\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-An excellent article on performance tuning can be found at:\n+-N --config-nfc\n+ Configures the receive network flow classification.\n \n-http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf\n+rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6 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-Known Issues\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+Speed and Duplex Configuration\n+------------------------------\n+In addressing speed and duplex configuration issues, you need to distinguish\n+between copper-based adapters and fiber-based adapters.\n+\n+In the default mode, an Intel(R) Ethernet Network Adapter using copper\n+connections will attempt to auto-negotiate with its link partner to determine\n+the best setting. If the adapter cannot establish link with the link partner\n+using auto-negotiation, you may need to manually configure the adapter and link\n+partner to identical settings to establish link and pass packets. This should\n+only be needed when attempting to link with an older switch that does not\n+support auto-negotiation or one that has been forced to a specific speed or\n+duplex mode. Your link partner must match the setting you choose. 1 Gbps speeds\n+and higher cannot be forced. Use the autonegotiation advertising setting to\n+manually set devices for 1 Gbps and higher.\n+\n+NOTE: You cannot set the speed for devices based on the Intel(R) Ethernet\n+Network Adapter XXV710 based devices.\n+\n+Speed, duplex, and autonegotiation advertising are configured through the\n+ethtool* utility.\n+\n+Caution: Only experienced network administrators should force speed and duplex\n+or change autonegotiation advertising manually. The settings at the switch must\n+always match the adapter settings. Adapter performance may suffer or your\n+adapter may not operate if you configure the adapter differently from your\n+switch.\n+\n+An Intel(R) Ethernet Network Adapter using fiber-based connections, however,\n+will not attempt to auto-negotiate with its link partner since those adapters\n+operate only in full duplex and only at their native speed.\n+\n+NAPI\n+----\n+NAPI (Rx polling mode) is supported in the i40e driver.\n+For more information on NAPI, see\n+https://wiki.linuxfoundation.org/networking/napi\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 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+NOTE: You must have a flow control capable link partner.\n+\n+Flow Control is on by default.\n+\n+Use ethtool to change the flow control settings.\n+\n+To enable or disable Rx or Tx Flow Control::\n+\n+ ethtool -A eth? rx <on|off> tx <on|off>\n+\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+\n+ ethtool -s eth? autoneg <on|off>\n+\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+RSS Hash Flow\n+-------------\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+::\n+\n+ # ethtool -N <dev> rx-flow-hash <type> <option>\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+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+NOTE: This feature can be disabled for a specific Virtual Function (VF)::\n+\n+ ip link set <pf dev> vf <vf id> spoofchk {off|on}\n+\n+IEEE 1588 Precision Time Protocol (PTP) Hardware Clock (PHC)\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+IEEE 802.1ad (QinQ) Support\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+\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+\n+Where \"24\" and \"371\" are example VLAN IDs.\n+\n+NOTES:\n+ Receive checksum offloads, cloud filters, and VLAN acceleration are not\n+ supported for 802.1ad (QinQ) packets.\n+\n+VXLAN and GENEVE Overlay HW Offloading\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+Multiple Functions per Port\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+Data Center Bridging (DCB)\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+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+Interrupt Rate Limiting\n+-----------------------\n+:Valid Range: 0-235 (0=no limit)\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+\n+ # ethtool -C ethX rx-usecs-high N\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+\n+ # ethtool -C ethX adaptive-rx off adaptive-tx off rx-usecs-high 20 rx-usecs \\\n+ 5 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+Performance Optimization\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+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+\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 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 are\n+ 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+::\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+::\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+::\n+\n+ # ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 0 \\\n+ tx-usecs 0\n+\n+Application Device Queues (ADq)\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+1. Create traffic classes (TCs). Maximum of 8 TCs can be created per interface.\n+The shaper bw_rlimit parameter is optional.\n+\n+Example: 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+\n+::\n+\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 (e.g. map 0 0 0 0 1 1 1 1\n+sets priorities 0-3 to use tc0 and 4-7 to 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 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+\n+For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network\n+monitoring tools such as ifstat or sar –n DEV [interval] [number of samples]\n+\n+2. Enable HW TC offload on interface::\n+\n+ # ethtool -K <interface> hw-tc-offload on\n+\n+3. Apply TCs to ingress (RX) flow of interface::\n+\n+ # tc qdisc add dev <interface> ingress\n+\n+NOTES:\n+ - Run all tc commands from the iproute2 <pathtoiproute2>/tc/ directory.\n+ - ADq is not compatible with cloud filters.\n+ - Setting up channels via ethtool (ethtool -L) is not supported when the\n+ TCs are configured using mqprio.\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+ - Tunnel filters are not supported in ADq. If encapsulated packets do\n+ arrive in non-tunnel mode, filtering will be done on the inner headers.\n+ For example, for VXLAN traffic in non-tunnel mode, PCTYPE is identified\n+ as a VXLAN encapsulated packet, outer headers are ignored. Therefore,\n+ inner headers are matched.\n+ - If a TC filter on a PF matches traffic over a VF (on the PF), that\n+ traffic will be routed to the appropriate queue of the PF, and will\n+ not be passed on the VF. Such traffic will end up getting dropped higher\n+ up in the TCP/IP stack as it does not match PF address data.\n+ - If traffic matches multiple TC filters that point to different TCs,\n+ that traffic will be duplicated and sent to all matching TC queues.\n+ The hardware switch mirrors the packet to a VSI list when multiple\n+ filters are matched.\n+\n+\n+Known Issues/Troubleshooting\n+============================\n+\n+NOTE: 1 Gb devices based on the Intel(R) Ethernet Network Connection X722 do\n+not support the following features:\n+\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+Unexpected Issues when the device driver and DPDK share a device\n+----------------------------------------------------------------\n+Unexpected issues may result when an i40e device is in multi driver mode and\n+the kernel driver and DPDK driver are sharing the device. This is because\n+access to the global NIC resources is not synchronized between multiple\n+drivers. Any change to the global NIC configuration (writing to a global\n+register, setting global configuration by AQ, or changing switch modes) will\n+affect all ports and drivers on the device. Loading DPDK with the\n+\"multi-driver\" module parameter may mitigate some of the issues.\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 Support\n =======\n-\n For general information, go to the Intel support website at:\n \n- http://support.intel.com\n+https://www.intel.com/support/\n \n or the Intel Wired Networking project hosted by Sourceforge at:\n \n- http://e1000.sourceforge.net\n+https://sourceforge.net/projects/e1000\n \n-If an issue is identified with the released source code on the supported\n-kernel with a supported adapter, email the specific information related\n-to the issue to e1000-devel@lists.sourceforge.net and copy\n-netdev@vger.kernel.org.\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", "08/12" ] }