-+--------------------------------+--------------------------------------------------------------------------------------+
-| Title | Ethertype filter could receive other packets (non-assigned) in Niantic |
-| | |
-+================================+======================================================================================+
-| Reference # | IXA00169017 |
-| | |
-+--------------------------------+--------------------------------------------------------------------------------------+
-| Description | On Intel® Ethernet Controller 82599EB: |
-| | |
-| | When Ethertype filter (priority enable) was set, unmatched packets also could be |
-| | received on the assigned queue, such as ARP packets without 802.1q tags or with the |
-| | user priority not equal to set value. |
-| | |
-| | Launch the testpmd by disabling RSS and with multiply queues, then add the ethertype |
-| | filter like: “add_ethertype_filter 0 ethertype 0x0806 priority enable 3 queue 2 |
-| | index 1”, and then start forwarding. |
-| | |
-| | When sending ARP packets without 802.1q tag and with user priority as non-3 by |
-| | tester, all the ARP packets can be received on the assigned queue. |
-| | |
-+--------------------------------+--------------------------------------------------------------------------------------+
-| Implication | The user priority comparing in Ethertype filter cannot work probably. |
-| | It is the NIC's issue due to the response from PAE: “In fact, ETQF.UP is not |
-| | functional, and the information will be added in errata of 82599 and X540.” |
-| | |
-+--------------------------------+--------------------------------------------------------------------------------------+
-| Resolution/ Workaround | None |
-| | |
-+--------------------------------+--------------------------------------------------------------------------------------+
-| Affected Environment/ Platform | All |
-| | |
-+--------------------------------+--------------------------------------------------------------------------------------+
-| Driver/Module | Poll Mode Driver (PMD) |
-| | |
-+--------------------------------+--------------------------------------------------------------------------------------+
-
-Cannot set link speed on Intel® 40G ethernet controller
+**Description**:
+ On Intel® Ethernet Controller 82599EB When Ethertype filter (priority enable) was set, unmatched packets also
+ could be received on the assigned queue, such as ARP packets without 802.1q tags or with the user priority not
+ equal to set value.
+ Launch the testpmd by disabling RSS and with multiply queues, then add the ethertype filter like the following
+ and then start forwarding::
+
+ add_ethertype_filter 0 ethertype 0x0806 priority enable 3 queue 2 index 1
+
+ When sending ARP packets without 802.1q tag and with user priority as non-3 by tester, all the ARP packets can
+ be received on the assigned queue.
+
+**Implication**:
+ The user priority comparing in Ethertype filter cannot work probably.
+ It is a NIC's issue due to the following: "In fact, ETQF.UP is not functional, and the information will
+ be added in errata of 82599 and X540."
+
+**Resolution/Workaround**:
+ None
+
+**Affected Environment/Platform**:
+ All.
+
+**Driver/Module**:
+ Poll Mode Driver (PMD).
+
+
+Cannot set link speed on Intel® 40G Ethernet controller
+-------------------------------------------------------
+
+**Description**:
+ On Intel® 40G Ethernet Controller you cannot set the link to specific speed.
+
+**Implication**:
+ The link speed cannot be changed forcibly, though it can be configured by application.
+
+**Resolution/Workaround**:
+ None
+
+**Affected Environment/Platform**:
+ All.
+
+**Driver/Module**:
+ Poll Mode Driver (PMD).
+
+
+Devices bound to igb_uio with VT-d enabled do not work on Linux kernel 3.15-3.17
+--------------------------------------------------------------------------------
+
+**Description**:
+ When VT-d is enabled (``iommu=pt intel_iommu=on``), devices are 1:1 mapped.
+ In the Linux kernel unbinding devices from drivers removes that mapping which result in IOMMU errors.
+ Introduced in Linux `kernel 3.15 commit
+ <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/iommu/intel-iommu.c?id=816997d03bca9fabcee65f3481eb0297103eceb7>`_,
+ solved in Linux `kernel 3.18 commit
+ <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/iommu/intel-iommu.c?id=1196c2fb0407683c2df92d3d09f9144d42830894>`_.
+
+**Implication**:
+ Devices will not be allowed to access memory, resulting in following kernel errors::
+
+ dmar: DRHD: handling fault status reg 2
+ dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr a0c58000
+ DMAR:[fault reason 02] Present bit in context entry is clear
+
+**Resolution/Workaround**:
+ Use earlier or later kernel versions, or avoid driver binding on boot by blacklisting the driver modules.
+ I.e., in the case of ``ixgbe``, we can pass the kernel command line option: ``modprobe.blacklist=ixgbe``.
+ This way we do not need to unbind the device to bind it to igb_uio.
+
+**Affected Environment/Platform**:
+ Linux systems with kernel versions 3.15 to 3.17.
+
+**Driver/Module**:
+ ``igb_uio`` module.
+
+
+VM power manager may not work on systems with more than 64 cores
+----------------------------------------------------------------
+
+**Description**:
+ When using VM power manager on a system with more than 64 cores, VM(s) should not use cores 64 or higher.
+
+**Implication**:
+ VM power manager should not be used with VM(s) that are using cores 64 or above.
+
+**Resolution/Workaround**:
+ Do not use cores 64 or above.
+
+**Affected Environment/Platform**:
+ Platforms with more than 64 cores.
+
+**Driver/Module**:
+ VM power manager application.
+
+
+DPDK may not build on some Intel CPUs using clang < 3.7.0
+---------------------------------------------------------
+
+**Description**:
+ When compiling DPDK with an earlier version than 3.7.0 of clang, CPU flags are not detected on some Intel platforms
+ such as Intel Broadwell/Skylake (and possibly future CPUs), and therefore compilation fails due to missing intrinsics.
+
+**Implication**:
+ DPDK will not build when using a clang version < 3.7.0.
+
+**Resolution/Workaround**:
+ Use clang 3.7.0 or higher, or gcc.
+
+**Affected Environment/Platform**:
+ Platforms with Intel Broadwell/Skylake using an old clang version.
+
+**Driver/Module**:
+ Environment Abstraction Layer (EAL).
+
+
+The last EAL argument is replaced by the program name in argv[]
+---------------------------------------------------------------
+
+**Description**:
+ The last EAL argument is replaced by program name in ``argv[]`` after ``eal_parse_args`` is called.
+ This is the intended behavior but it causes the pointer to the last EAL argument to be lost.
+
+**Implication**:
+ If the last EAL argument in ``argv[]`` is generated by a malloc function, changing it will cause memory
+ issues when freeing the argument.
+
+**Resolution/Workaround**:
+ An application should not consider the value in ``argv[]`` as unchanged.
+
+**Affected Environment/Platform**:
+ ALL.
+
+**Driver/Module**:
+ Environment Abstraction Layer (EAL).
+
+
+I40e VF may not receive packets in the promiscuous mode