Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/982050/?format=api
{ "id": 982050, "url": "http://patchwork.ozlabs.org/api/patches/982050/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/patch/20181010191613.2770-10-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-10-jeffrey.t.kirsher@intel.com>", "list_archive_url": null, "date": "2018-10-10T19:16:10", "name": "[v2,09/12] Documentation: iavf: Prepare documentation for RST conversion", "commit_ref": null, "pull_url": null, "state": "accepted", "archived": false, "hash": "bff4596bf2a9d641ae1e29e5242bedd5111f4261", "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-10-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/982050/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/982050/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<intel-wired-lan-bounces@osuosl.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "intel-wired-lan@lists.osuosl.org" ], "Delivered-To": [ "patchwork-incoming@bilbo.ozlabs.org", "intel-wired-lan@lists.osuosl.org" ], "Authentication-Results": [ "ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.137; helo=fraxinus.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=<UNKNOWN>)", "ozlabs.org;\n\tdmarc=fail (p=none dis=none) header.from=intel.com" ], "Received": [ "from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 42VkNd5l9Dz9s55\n\tfor <incoming@patchwork.ozlabs.org>;\n\tThu, 11 Oct 2018 06:16:33 +1100 (AEDT)", "from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 6492186B20;\n\tWed, 10 Oct 2018 19:16:32 +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 2qGr1iGK0Uo7; Wed, 10 Oct 2018 19:16:30 +0000 (UTC)", "from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id AD6AB86B0E;\n\tWed, 10 Oct 2018 19:16:30 +0000 (UTC)", "from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])\n\tby ash.osuosl.org (Postfix) with ESMTP id EC8201BF429\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 hemlock.osuosl.org (Postfix) with ESMTP id E9E42878B8\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tWed, 10 Oct 2018 19:16:22 +0000 (UTC)", "from hemlock.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id WxApGYAP4xDz 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 hemlock.osuosl.org (Postfix) with ESMTPS id B339087544\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=\"90918138\"", "From": "Jeff Kirsher <jeffrey.t.kirsher@intel.com>", "To": "intel-wired-lan@lists.osuosl.org", "Date": "Wed, 10 Oct 2018 12:16:10 -0700", "Message-Id": "<20181010191613.2770-10-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 09/12] Documentation: iavf: 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/iavf.txt | 271 +++++++++++++++++++++++++++---\n 1 file changed, 248 insertions(+), 23 deletions(-)", "diff": "diff --git a/Documentation/networking/iavf.txt b/Documentation/networking/iavf.txt\nindex cc902a2369d6..821b675b227a 100644\n--- a/Documentation/networking/iavf.txt\n+++ b/Documentation/networking/iavf.txt\n@@ -1,5 +1,7 @@\n-Linux* Base Driver for Intel(R) Network Connection\n-==================================================\n+.. SPDX-License-Identifier: GPL-2.0+\n+\n+Linux* Base Driver for Intel(R) Ethernet Adaptive Virtual Function\n+==================================================================\n \n Intel Ethernet Adaptive Virtual Function Linux driver.\n Copyright(c) 2013-2018 Intel Corporation.\n@@ -8,49 +10,272 @@ Contents\n ========\n \n - Identifying Your Adapter\n+- Additional Configurations\n - Known Issues/Troubleshooting\n - Support\n \n-This file describes the iavf Linux* Base Driver. This driver\n-was formerly called i40evf.\n+This file describes the iavf Linux* Base Driver. This driver was formerly\n+called i40evf.\n \n-The iavf 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 iavf driver requires CONFIG_PCI_MSI to be enabled.\n+The iavf driver supports the below mentioned virtual function devices and\n+can only be activated on kernels running the i40e or newer Physical Function\n+(PF) driver compiled with CONFIG_PCI_IOV. The iavf driver requires\n+CONFIG_PCI_MSI to be enabled.\n \n The guest OS loading the iavf driver must support MSI-X interrupts.\n \n-Supported Hardware\n-==================\n-Intel XL710 X710 Virtual Function\n-Intel X722 Virtual Function\n-Intel Ethernet Adaptive Virtual Function\n-\n Identifying Your Adapter\n ========================\n+The driver in this kernel is compatible with devices based on the following:\n+ * Intel(R) XL710 X710 Virtual Function\n+ * Intel(R) X722 Virtual Function\n+ * Intel(R) XXV710 Virtual Function\n+ * Intel(R) Ethernet Adaptive Virtual Function\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+http://www.intel.com/support\n+\n+\n+Additional Features and Configurations\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+\n+ dmesg -n 8\n+\n+NOTE: This setting is not saved across reboots.\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+https://www.kernel.org/pub/software/network/ethtool/\n+\n+Setting VLAN Tag Stripping\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+\n+ ethtool -K <if_name> rxvlan on/off\n+\n+or alternatively::\n+\n+ ethtool --offload <if_name> rxvlan on/off\n+\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+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+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-For more information on how to identify your adapter, go to the\n-Adapter & Driver ID Guide at:\n+::\n \n- https://www.intel.com/content/www/us/en/support/articles/000005584/network-and-i-o/ethernet-products.html\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 TCs\n+ 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 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 arrive\n+ in non-tunnel mode, filtering will be done on the inner headers. For example,\n+ for VXLAN traffic in non-tunnel mode, PCTYPE is identified as a VXLAN\n+ encapsulated packet, outer headers are ignored. Therefore, inner headers are\n+ matched.\n+ - If a TC filter on a PF matches traffic over a VF (on the PF), that traffic\n+ will be routed to the appropriate queue of the PF, and will not be passed on\n+ the VF. Such traffic will end up getting dropped higher up in the TCP/IP\n+ stack as it does not match PF address data.\n+ - If traffic matches multiple TC filters that point to different TCs, that\n+ traffic will be duplicated and sent to all matching TC queues. The hardware\n+ switch mirrors the packet to a VSI list when multiple filters are matched.\n \n \n Known Issues/Troubleshooting\n ============================\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+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+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+\n+ ethtool -r <PF>\n+\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+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+Driver Buffer Overflow Fix\n+--------------------------\n+The fix to resolve CVE-2016-8105, referenced in Intel SA-00069\n+https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00069.html\n+is included in this and future versions of the driver.\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+\n+ echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter\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+\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+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 Support\n =======\n-\n For general information, go to the Intel support website at:\n \n- http://support.intel.com\n+https://support.intel.com\n \n or the Intel Wired Networking project hosted by Sourceforge at:\n \n- http://sourceforge.net/projects/e1000\n+https://sourceforge.net/projects/e1000\n \n-If an issue is identified with the released source code on the supported\n-kernel with a supported adapter, email the specific information related\n-to the issue to e1000-devel@lists.sf.net\n+If an issue is identified with the released source code on the 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", "09/12" ] }