Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/897729/?format=api
{ "id": 897729, "url": "http://patchwork.ozlabs.org/api/patches/897729/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/patch/20180412162904.9337-2-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": "<20180412162904.9337-2-jeffrey.t.kirsher@intel.com>", "list_archive_url": null, "date": "2018-04-12T16:29:04", "name": "[v2] Documentation: i40evf: Update kernel documentation", "commit_ref": null, "pull_url": null, "state": "changes-requested", "archived": false, "hash": "2caaf7cc39972f529f9dcc330598dedbd5408abc", "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/20180412162904.9337-2-jeffrey.t.kirsher@intel.com/mbox/", "series": [ { "id": 38665, "url": "http://patchwork.ozlabs.org/api/series/38665/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/list/?series=38665", "date": "2018-04-12T16:29:04", "name": "[v2] Documentation: i40evf: Update kernel documentation", "version": 2, "mbox": "http://patchwork.ozlabs.org/series/38665/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/897729/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/897729/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=none (p=none dis=none) header.from=intel.com" ], "Received": [ "from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 40MRD64jsnz9s16\n\tfor <incoming@patchwork.ozlabs.org>;\n\tFri, 13 Apr 2018 02:28:22 +1000 (AEST)", "from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id E96CD86B00;\n\tThu, 12 Apr 2018 16:28:20 +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 KpjgoUvbOY_6; Thu, 12 Apr 2018 16:28:18 +0000 (UTC)", "from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 38D8A86A10;\n\tThu, 12 Apr 2018 16:28:18 +0000 (UTC)", "from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])\n\tby ash.osuosl.org (Postfix) with ESMTP id A269D1CE873\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tThu, 12 Apr 2018 16:28:17 +0000 (UTC)", "from localhost (localhost [127.0.0.1])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id 9DD8488891\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tThu, 12 Apr 2018 16:28:17 +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 oNHZR0ewNlEV for <intel-wired-lan@lists.osuosl.org>;\n\tThu, 12 Apr 2018 16:28:15 +0000 (UTC)", "from mga12.intel.com (mga12.intel.com [192.55.52.136])\n\tby hemlock.osuosl.org (Postfix) with ESMTPS id 71B5688293\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tThu, 12 Apr 2018 16:28:15 +0000 (UTC)", "from fmsmga005.fm.intel.com ([10.253.24.32])\n\tby fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t12 Apr 2018 09:28:14 -0700", "from jtkirshe-nuc.jf.intel.com ([134.134.177.59])\n\tby fmsmga005.fm.intel.com with ESMTP; 12 Apr 2018 09:28:14 -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,442,1517904000\"; d=\"scan'208\";a=\"219909189\"", "From": "Jeff Kirsher <jeffrey.t.kirsher@intel.com>", "To": "intel-wired-lan@lists.osuosl.org", "Date": "Thu, 12 Apr 2018 09:29:04 -0700", "Message-Id": "<20180412162904.9337-2-jeffrey.t.kirsher@intel.com>", "X-Mailer": "git-send-email 2.14.3", "In-Reply-To": "<20180412162904.9337-1-jeffrey.t.kirsher@intel.com>", "References": "<20180412162904.9337-1-jeffrey.t.kirsher@intel.com>", "MIME-Version": "1.0", "Subject": "[Intel-wired-lan] [PATCH v2] Documentation: i40evf: 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>", "Content-Type": "text/plain; charset=\"utf-8\"", "Content-Transfer-Encoding": "base64", "Errors-To": "intel-wired-lan-bounces@osuosl.org", "Sender": "\"Intel-wired-lan\" <intel-wired-lan-bounces@osuosl.org>" }, "content": "Updated the i40evf.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/i40evf.txt | 324 ++++++++++++++++++++++++++++++++----\n 1 file changed, 292 insertions(+), 32 deletions(-)", "diff": "diff --git a/Documentation/networking/i40evf.txt b/Documentation/networking/i40evf.txt\nindex e9b3035b95d0..a333ed688c00 100644\n--- a/Documentation/networking/i40evf.txt\n+++ b/Documentation/networking/i40evf.txt\n@@ -1,54 +1,314 @@\n-Linux* Base Driver for Intel(R) Network Connection\n-==================================================\n+Linux* Driver for Intel(R) Ethernet Virtual Function 700 Series\n+======================================================\n \n-Intel Ethernet Adaptive Virtual Function Linux driver.\n-Copyright(c) 2013-2017 Intel Corporation.\n+February 26, 2018\n+\n+======================================================\n \n Contents\n ========\n-\n-- Identifying Your Adapter\n-- Known Issues/Troubleshooting\n+- Overview\n+- Additional Configurations\n+- Known Issues\n - Support\n+- License\n+\n+This driver supports XL710- and X710-based virtual function devices\n+with CONFIG_PCI_IOV enabled.\n+\n+SR-IOV requires the correct platform and OS support.\n \n-This file describes the i40evf Linux* Base Driver.\n+The guest OS loading this driver must support MSI-X interrupts.\n \n-The i40evf driver supports the below mentioned virtual function\n-devices and can only be activated on kernels running the i40e or\n-newer Physical Function (PF) driver compiled with CONFIG_PCI_IOV.\n-The i40evf driver requires CONFIG_PCI_MSI to be enabled.\n+For questions related to hardware requirements, refer to the documentation\n+supplied with your Intel adapter. All hardware requirements listed apply to use\n+with Linux.\n+\n+Driver information can be obtained using ethtool, lspci, and ifconfig.\n+Instructions on updating ethtool can be found in the section Additional\n+Configurations later in this document.\n+\n+The i40evf driver supports virtual functions generated by the i40e driver,\n+with one or more VFs enabled through sysfs.\n \n-The guest OS loading the i40evf driver must support MSI-X interrupts.\n \n-Supported Hardware\n-==================\n-Intel XL710 X710 Virtual Function\n-Intel Ethernet Adaptive Virtual Function\n-Intel X722 Virtual Function\n \n Identifying Your Adapter\n-========================\n+------------------------\n+The driver in this kernel is compatible with devices based on the following:\n+ * Intel(R) Ethernet Controller X710\n+ * Intel(R) Ethernet Controller XL710\n+ * Intel(R) Ethernet Network Connection X722\n+ * Intel(R) Ethernet Controller XXV710\n+\n+For the best performance, make sure the latest NVM/FW is installed on your\n+device.\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+dmesg -n 8\n+\n+NOTE: This setting is not saved across reboots.\n+\n+\n+ethtool\n+-------\n+The driver utilizes the ethtool interface for driver configuration and\n+diagnostics, as well as displaying statistical information. The latest ethtool\n+version is required for this functionality. Download it at:\n+http://ftp.kernel.org/pub/software/network/ethtool/\n+\n+\n+Setting VLAN Tag Stripping\n+--------------------------\n+\n+If you have applications that require Virtual Functions (VFs) to receive\n+packets with VLAN tags, you can disable VLAN tag stripping for the VF. The\n+Physical Function (PF) processes requests issued from the VF to enable or\n+disable VLAN tag stripping. Note that if the PF has assigned a VLAN to a VF,\n+then requests from that VF to set VLAN tag stripping will be ignored.\n+\n+To enable/disable VLAN tag stripping for a VF, issue the following command\n+from inside the VM in which you are running the VF:\n+ ethtool -K <if_name> rxvlan on/off\n+ or alternatively:\n+ ethtool --offload <if_name> rxvlan on/off\n+\n+\n+Adaptive Virtual Function\n+-------------------------\n+Adaptive Virtual Function (AVF) allows the virtual function driver, or VF, to\n+adapt to changing feature sets of the physical function driver (PF) with which\n+it is associated. This allows system administrators to update a PF without\n+having to update all the VFs associated with it. All AVFs have a single common\n+device ID and branding string.\n+\n+AVFs have a minimum set of features known as \"base mode,\" but may provide\n+additional features depending on what features are available in the PF with\n+which the AVF is associated. The following are base mode features:\n+\n+- 4 Queue Pairs (QP) and associated Configuration Status Registers (CSRs)\n+ for Tx/Rx.\n+- i40e descriptors and ring format.\n+- Descriptor write-back completion.\n+- 1 control queue, with i40e descriptors, CSRs and ring format.\n+- 5 MSI-X interrupt vectors and corresponding i40e CSRs.\n+- 1 Interrupt Throttle Rate (ITR) index.\n+- 1 Virtual Station Interface (VSI) per VF.\n+- 1 Traffic Class (TC), TC0\n+- Receive Side Scaling (RSS) with 64 entry indirection table and key,\n+ configured through the PF.\n+- 1 unicast MAC address reserved per VF.\n+- 16 MAC address filters for each VF.\n+- Stateless offloads - non-tunneled checksums.\n+- AVF device ID.\n+- HW mailbox is used for VF to PF communications (including on Windows).\n+\n+\n+IEEE 802.1ad (QinQ) Support\n+---------------------------\n+\n+The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN\n+IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as\n+\"tags,\" and multiple VLAN IDs are thus referred to as a \"tag stack.\" Tag stacks\n+allow L2 tunneling and the ability to segregate traffic within a particular\n+VLAN ID, among other uses.\n+\n+The following are examples of how to configure 802.1ad (QinQ):\n+ ip link add link eth0 eth0.24 type vlan proto 802.1ad id 24\n+ ip link add link eth0.24 eth0.24.371 type vlan proto 802.1Q id 371\n+Where \"24\" and \"371\" are example VLAN IDs.\n+\n+NOTES:\n+- 802.1ad (QinQ)is supported in 3.19 and later kernels.\n+- Receive checksum offloads, cloud filters, and VLAN acceleration are not\n+supported for 802.1ad (QinQ) packets.\n+\n+\n+Application Device Queues (ADq)\n+-------------------------------\n+\n+Application Device Queues (ADq) allows you to dedicate one or more queues to a\n+specific application. This can reduce latency for the specified application,\n+and allow Tx traffic to be rate limited per application. Follow the steps below\n+to set ADq.\n+\n+NOTE: Run all tc commands from the iproute2 <pathtoiproute2>/tc/ directory.\n+ 1. Create traffic classes (TCs). Maximum of 8 TCs can be created per\n+ interface. The shaper bw_rlimit parameter is optional.\n+ Example:\n+ Sets up two tcs, tc0 and tc1, with 16 queues each and max tx rate set\n+ to 1Gbit for tc0 and 3Gbit for tc1.\n+ # tc qdisc add dev <interface> root mqprio num_tc 2 map 0 0 0 0 1 1 1 1\n+ queues 16@0 16@16 hw 1 mode channel shaper bw_rlimit min_rate 1Gbit 2Gbit\n+ max_rate 1Gbit 3Gbit\n+\n+ map: priority mapping for up to 16 priorities to tcs\n+ (e.g. map 0 0 0 0 1 1 1 1 sets priorities 0-3 to use tc0 and 4-7 to\n+ use tc1)\n \n-For more information on how to identify your adapter, go to the\n-Adapter & Driver ID Guide at:\n+ queues: for each tc, <num queues>@<offset> (e.g. queues 16@0 16@16 assigns\n+ 16 queues to tc0 at offset 0 and 16 queues to tc1 at offset 16. Max total\n+ number of queues for all tcs is 64 or number of cores, whichever is\n+ lower.)\n+\n+ hw 1 mode channel: ‘channel’ with ‘hw’ set to 1 is a new new hardware\n+ offload mode in mqprio that makes full use of the mqprio options, the\n+ TCs, the queue configurations, and the QoS parameters.\n+\n+ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.\n+ Totals must be equal or less than port speed.\n+ For example: min_rate 1Gbit 3Gbit:\n+ Verify bandwidth limit using network monitoring tools such as ifstat\n+ or sar –n DEV [interval] [number of samples]\n+\n+NOTE: Setting up channels via ethtool (ethtool -L) is not supported when the\n+TCs are configured using mqprio.\n+\n+ 2. Enable HW TC offload on interface:\n+ # ethtool -K <interface> hw-tc-offload on\n+ 3. Apply TCs to ingress (RX) flow of interface:\n+ # tc qdisc add dev <interface> ingress\n+NOTES:\n+- You must have kernel version 4.15 or later and the sch_mqprio, act_mirred\n+ and cls_flower modules loaded to set ADq\n+- You must have iproute2 latest version\n+- NVM version 6.01 or later is required.\n+- ADq cannot be enabled when any the following features are enabled: Data\n+ Center Bridging (DCB), Multiple Functions per Port (MFP), or Sideband\n+ Filters.\n+- If another driver (for example, DPDK) has set cloud filters, you cannot\n+ enable ADq.\n+- 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- http://support.intel.com/support/go/network/adapter/idguide.htm\n \n Known Issues/Troubleshooting\n-============================\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-Support\n-=======\n \n-For general information, go to the Intel support website at:\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- http://support.intel.com\n \n-or the Intel Wired Networking project hosted by Sourceforge at:\n+Virtual machine does not get link\n+---------------------------------\n+If the virtual machine has more than one virtual port assigned to it, and those\n+virtual ports are bound to different physical ports, you may not get link on\n+all of the virtual ports. The following command may work around the issue:\n+ethtool -r <PF>\n+Where <PF> is the PF interface in the host, for example: p5p1. You may need to\n+run the command more than once to get link on all virtual ports.\n+\n+\n+MAC address of Virtual Function changes unexpectedly\n+----------------------------------------------------\n+If a Virtual Function's MAC address is not assigned in the host, then the VF\n+(virtual function) driver will use a random MAC address. This random MAC\n+address may change each time the VF driver is reloaded. You can assign a static\n+MAC address in the host machine. This static MAC address will survive\n+a VF driver reload.\n+\n+\n+Hardware Issues\n+---------------\n+\n+For known hardware and troubleshooting issues, either refer to the \"Release\n+Notes\" in your User Guide, or for more detailed information, go to\n+http://www.intel.com.\n+\n+In the search box enter your devices controller ID followed by \"spec update\"\n+(i.e., XL710 spec update). The specification update file has complete\n+information on known hardware issues.\n+\n+\n+Software Issues\n+---------------\n+\n+NOTE: After installing the driver, if your Intel Ethernet Network Connection\n+is not working, verify that you have installed the correct driver.\n \n- http://sourceforge.net/projects/e1000\n \n-If an issue is identified with the released source code on the supported\n-kernel with a supported adapter, email the specific information related\n-to the issue to e1000-devel@lists.sf.net\n+Driver Buffer Overflow Fix\n+--------------------------\n+The fix to resolve CVE-2016-8105, referenced in Intel SA-00069\n+<https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00069&language\n+id=en-fr>, is included in this and future versions of the driver.\n+\n+\n+Multiple Interfaces on Same Ethernet Broadcast Network\n+------------------------------------------------------\n+Due to the default ARP behavior on Linux, it is not possible to have one system\n+on two IP networks in the same Ethernet broadcast domain (non-partitioned\n+switch) behave as expected. All Ethernet interfaces will respond to IP traffic\n+for any IP address assigned to the system. This results in unbalanced receive\n+traffic.\n+\n+If you have multiple interfaces in a server, either turn on ARP filtering by\n+entering:\n+echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter\n+\n+This only works if your kernel's version is higher than 2.4.5.\n+\n+\n+NOTE: This setting is not saved across reboots. The configuration change can be\n+made permanent by adding the following line to the file /etc/sysctl.conf:\n+net.ipv4.conf.all.arp_filter = 1\n+\n+Another alternative is to install the interfaces in separate broadcast domains\n+(either in different switches or in a switch partitioned to VLANs).\n+\n+\n+Rx Page Allocation Errors\n+-------------------------\n+'Page allocation failure. order:0' errors may occur under stress.\n+This is caused by the way the Linux kernel reports this stressed condition.\n+\n+\n+\n+Support\n+-------\n+For general information, go to the Intel support website at:\n+http://www.intel.com/support/\n+\n+or the Intel Wired Networking project hosted by Sourceforge at:\n+http://sourceforge.net/projects/e1000\n+If an issue is identified with the released source code on a supported kernel\n+with a supported adapter, email the specific information related to the issue\n+to e1000-devel@lists.sf.net.\n", "prefixes": [ "v2" ] }