[PATCH] doc: remove known issues

[Nandini Persad <nandinipersad361@gmail.com>]

I have uploaded all these known issues into Bugzilla,
so they are not needed here anymore.

Signed-off-by: <nandinipersad361@gmail.com>
---
 doc/guides/rel_notes/known_issues.rst | 875 --------------------------
 1 file changed, 875 deletions(-)
 delete mode 100644 doc/guides/rel_notes/known_issues.rst

diff --git a/doc/guides/rel_notes/known_issues.rst b/doc/guides/rel_notes/known_issues.rst
deleted file mode 100644
index 73c72ba484..0000000000
--- a/doc/guides/rel_notes/known_issues.rst
+++ /dev/null
@@ -1,875 +0,0 @@
-..  SPDX-License-Identifier: BSD-3-Clause
-    Copyright(c) 2010-2014 Intel Corporation.
-
-Known Issues and Limitations in Legacy Releases
-===============================================
-
-This section describes known issues with the DPDK software that aren't covered in the version specific release
-notes sections.
-
-
-Unit Test for Link Bonding may fail at test_tlb_tx_burst()
-----------------------------------------------------------
-
-**Description**:
-   Unit tests will fail in ``test_tlb_tx_burst()`` function with error for uneven distribution of packets.
-
-**Implication**:
-   Unit test link_bonding_autotest will fail.
-
-**Resolution/Workaround**:
-   There is no workaround available.
-
-**Affected Environment/Platform**:
-   Fedora 20.
-
-**Driver/Module**:
-   Link Bonding.
-
-
-Pause Frame Forwarding does not work properly on igb
-----------------------------------------------------
-
-**Description**:
-   For igb devices rte_eth_flow_ctrl_set does not work as expected.
-   Pause frames are always forwarded on igb, regardless of the ``RFCE``, ``MPMCF`` and ``DPF`` registers.
-
-**Implication**:
-   Pause frames will never be rejected by the host on 1G NICs and they will always be forwarded.
-
-**Resolution/Workaround**:
-   There is no workaround available.
-
-**Affected Environment/Platform**:
-   All.
-
-**Driver/Module**:
-   Poll Mode Driver (PMD).
-
-
-In packets provided by the PMD, some flags are missing
-------------------------------------------------------
-
-**Description**:
-   In packets provided by the PMD, some flags are missing.
-   The application does not have access to information provided by the hardware
-   (packet is broadcast, packet is multicast, packet is IPv4 and so on).
-
-**Implication**:
-   The ``ol_flags`` field in the ``rte_mbuf`` structure is not correct and should not be used.
-
-**Resolution/Workaround**:
-   The application has to parse the Ethernet header itself to get the information, which is slower.
-
-**Affected Environment/Platform**:
-   All.
-
-**Driver/Module**:
-   Poll Mode Driver (PMD).
-
-The rte_malloc library is not fully implemented
------------------------------------------------
-
-**Description**:
-   The ``rte_malloc`` library is not fully implemented.
-
-**Implication**:
-   All debugging features of rte_malloc library described in architecture documentation are not yet implemented.
-
-**Resolution/Workaround**:
-   No workaround available.
-
-**Affected Environment/Platform**:
-   All.
-
-**Driver/Module**:
-   ``rte_malloc``.
-
-
-HPET reading is slow
---------------------
-
-**Description**:
-   Reading the HPET chip is slow.
-
-**Implication**:
-   An application that calls ``rte_get_hpet_cycles()`` or ``rte_timer_manage()`` runs slower.
-
-**Resolution/Workaround**:
-   The application should not call these functions too often in the main loop.
-   An alternative is to use the TSC register through ``rte_rdtsc()`` which is faster,
-   but specific to an lcore and is a cycle reference, not a time reference.
-
-**Affected Environment/Platform**:
-   All.
-
-**Driver/Module**:
-   Environment Abstraction Layer (EAL).
-
-
-HPET timers do not work on the Osage customer reference platform
-----------------------------------------------------------------
-
-**Description**:
-   HPET timers do not work on the Osage customer reference platform which includes an Intel® Xeon® processor 5500
-   series processor) using the released BIOS from Intel.
-
-**Implication**:
-   On Osage boards, the implementation of the ``rte_delay_us()`` function must be changed to not use the HPET timer.
-
-**Resolution/Workaround**:
-   This can be addressed by building the system with ``RTE_LIBEAL_USE_HPET`` unset
-   or by using the ``--no-hpet`` EAL option.
-
-**Affected Environment/Platform**:
-   The Osage customer reference platform.
-   Other vendor platforms with Intel®  Xeon® processor 5500 series processors should
-   work correctly, provided the BIOS supports HPET.
-
-**Driver/Module**:
-   ``lib/eal/include/rte_cycles.h``
-
-
-Not all variants of supported NIC types have been used in testing
------------------------------------------------------------------
-
-**Description**:
-   The supported network interface cards can come in a number of variants with different device ID's.
-   Not all of these variants have been tested with the DPDK.
-
-   The NIC device identifiers used during testing:
-
-   * Intel® Ethernet Controller XL710 for 40GbE QSFP+ [8086:1584]
-   * Intel® Ethernet Controller XL710 for 40GbE QSFP+ [8086:1583]
-   * Intel® Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
-   * Intel® 82576 Gigabit Ethernet Controller [8086:10c9]
-   * Intel® 82576 Quad Copper Gigabit Ethernet Controller [8086:10e8]
-   * Intel® 82580 Dual Copper Gigabit Ethernet Controller [8086:150e]
-   * Intel® I350 Quad Copper Gigabit Ethernet Controller [8086:1521]
-   * Intel® 82599 Dual Fibre 10 Gigabit Ethernet Controller [8086:10fb]
-   * Intel® Ethernet Server Adapter X520-T2 [8086: 151c]
-   * Intel® Ethernet Controller X540-T2 [8086:1528]
-   * Intel® 82574L Gigabit Network Connection [8086:10d3]
-   * Emulated Intel® 82540EM Gigabit Ethernet Controller [8086:100e]
-   * Emulated Intel® 82545EM Gigabit Ethernet Controller [8086:100f]
-   * Intel® Ethernet Server Adapter X520-4 [8086:154a]
-   * Intel® Ethernet Controller I210 [8086:1533]
-
-**Implication**:
-   Risk of issues with untested variants.
-
-**Resolution/Workaround**:
-   Use tested NIC variants. For those supported Ethernet controllers, additional device
-   IDs may be added to the software if required.
-
-**Affected Environment/Platform**:
-   All.
-
-**Driver/Module**:
-   Poll-mode drivers
-
-
-Multi-process sample app requires exact memory mapping
-------------------------------------------------------
-
-**Description**:
-   The multi-process example application assumes that
-   it is possible to map the hugepage memory to the same virtual addresses in client and server applications.
-   Occasionally, very rarely with 64-bit, this does not occur and a client application will fail on startup.
-   The Linux "address-space layout randomization" security feature can sometimes cause this to occur.
-
-**Implication**:
-   A multi-process client application fails to initialize.
-
-**Resolution/Workaround**:
-   See the "Multi-process Limitations" section in the DPDK Programmer's Guide for more information.
-
-**Affected Environment/Platform**:
-   All.
-
-**Driver/Module**:
-   Multi-process example application
-
-
-Packets are not sent by the 1 GbE/10 GbE SR-IOV driver when the source MAC is not the MAC assigned to the VF NIC
-----------------------------------------------------------------------------------------------------------------
-
-**Description**:
-   The 1 GbE/10 GbE SR-IOV driver can only send packets when the Ethernet header's source MAC address is the same as
-   that of the VF NIC.
-   The reason for this is that the Linux ``ixgbe`` driver module in the host OS has its anti-spoofing feature enabled.
-
-**Implication**:
-   Packets sent using the 1 GbE/10 GbE SR-IOV driver must have the source MAC address correctly set to that of the VF NIC.
-   Packets with other source address values are dropped by the NIC if the application attempts to transmit them.
-
-**Resolution/Workaround**:
-   Configure the Ethernet source address in each packet to match that of the VF NIC.
-
-**Affected Environment/Platform**:
-   All.
-
-**Driver/Module**:
-   1 GbE/10 GbE VF Poll Mode Driver (PMD).
-
-
-SR-IOV drivers do not fully implement the rte_ethdev API
---------------------------------------------------------
-
-**Description**:
-   The SR-IOV drivers only supports the following rte_ethdev API functions:
-
-   * rte_eth_dev_configure()
-   * rte_eth_tx_queue_setup()
-   * rte_eth_rx_queue_setup()
-   * rte_eth_dev_info_get()
-   * rte_eth_dev_start()
-   * rte_eth_tx_burst()
-   * rte_eth_rx_burst()
-   * rte_eth_dev_stop()
-   * rte_eth_stats_get()
-   * rte_eth_stats_reset()
-   * rte_eth_link_get()
-   * rte_eth_link_get_no_wait()
-
-**Implication**:
-   Calling an unsupported function will result in an application error.
-
-**Resolution/Workaround**:
-   Do not use other rte_ethdev API functions in applications that use the SR-IOV drivers.
-
-**Affected Environment/Platform**:
-   All.
-
-**Driver/Module**:
-   VF Poll Mode Driver (PMD).
-
-
-PMD does not work with --no-huge EAL command line parameter
------------------------------------------------------------
-
-**Description**:
-   Currently, the DPDK does not store any information about memory allocated by ``malloc()``
-   (for example, NUMA node, physical address),
-   hence PMDs do not work when the ``--no-huge`` command line parameter is supplied to EAL.
-   This happens when using non-IOMMU based UIO drivers (i.e. ``igb_uio`` or ``uio_pci_generic``)
-   or when IOVA mode is explicitly set to use physical addresses
-   (via the ``--iova-mode=pa`` EAL parameter).
-
-**Implication**:
-   Sending and receiving data with PMD will not work.
-   Unit tests checking ``--no-huge`` operation will fail if there is a device bound to the PMD
-   (``eal_flags_n_opt_autotest``, ``eal_flags_no_huge_autotest``,
-   ``eal_flags_vdev_opt_autotest``, ``eal_flags_misc_autotest``).
-
-**Resolution/Workaround**:
-   Use huge page memory or use VFIO to map devices.
-
-**Affected Environment/Platform**:
-   Systems running the DPDK on Linux
-
-**Driver/Module**:
-   Poll Mode Driver (PMD).
-
-
-Some hardware off-load functions are not supported by the VF Driver
--------------------------------------------------------------------
-
-**Description**:
-   Currently, configuration of the following items is not supported by the VF driver:
-
-   * IP/UDP/TCP checksum offload
-   * Jumbo Frame Receipt
-   * HW Strip CRC
-
-**Implication**:
-   Any configuration for these items in the VF register will be ignored.
-   The behavior is dependent on the current PF setting.
-
-**Resolution/Workaround**:
-   For the PF (Physical Function) status on which the VF driver depends, there is an option item under PMD in the
-   config file.
-   For others, the VF will keep the same behavior as PF setting.
-
-**Affected Environment/Platform**:
-   All.
-
-**Driver/Module**:
-   VF (SR-IOV) Poll Mode Driver (PMD).
-
-
-Kernel crash on IGB port unbinding
-----------------------------------
-
-**Description**:
-   Kernel crash may occur when unbinding 1G ports from the igb_uio driver, on 2.6.3x kernels such as shipped
-   with Fedora 14.
-
-**Implication**:
-   Kernel crash occurs.
-
-**Resolution/Workaround**:
-   Use newer kernels or do not unbind ports.
-
-**Affected Environment/Platform**:
-   2.6.3x kernels such as  shipped with Fedora 14
-
-**Driver/Module**:
-   IGB Poll Mode Driver (PMD).
-
-
-Twinpond and Ironpond NICs do not report link status correctly
---------------------------------------------------------------
-
-**Description**:
-   Twin Pond/Iron Pond NICs do not bring the physical link down when shutting down the port.
-
-**Implication**:
-   The link is reported as up even after issuing ``shutdown`` command unless the cable is physically disconnected.
-
-**Resolution/Workaround**:
-   None.
-
-**Affected Environment/Platform**:
-   Twin Pond and Iron Pond NICs
-
-**Driver/Module**:
-   Poll Mode Driver (PMD).
-
-
-Discrepancies between statistics reported by different NICs
------------------------------------------------------------
-
-**Description**:
-   Gigabit Ethernet devices from Intel include CRC bytes when calculating packet reception statistics regardless
-   of hardware CRC stripping state, while 10-Gigabit Ethernet devices from Intel do so only when hardware CRC
-   stripping is disabled.
-
-**Implication**:
-   There may be a  discrepancy in how different NICs display packet reception statistics.
-
-**Resolution/Workaround**:
-   None
-
-**Affected Environment/Platform**:
-   All.
-
-**Driver/Module**:
-   Poll Mode Driver (PMD).
-
-
-Error reported opening files on DPDK initialization
----------------------------------------------------
-
-**Description**:
-   On DPDK application startup, errors may be reported when opening files as part of the initialization process.
-   This occurs if a large number, for example, 500 or more, or if hugepages are used, due to the per-process
-   limit on the number of open files.
-
-**Implication**:
-   The DPDK application may fail to run.
-
-**Resolution/Workaround**:
-   If using 2 MB hugepages, consider switching to a fewer number of 1 GB pages.
-   Alternatively, use the ``ulimit`` command to increase the number of files which can be opened by a process.
-
-**Affected Environment/Platform**:
-   All.
-
-**Driver/Module**:
-   Environment Abstraction Layer (EAL).
-
-
-Intel® QuickAssist Technology sample application does not work on a 32-bit OS on Shumway
-----------------------------------------------------------------------------------------
-
-**Description**:
-   The Intel® Communications Chipset 89xx Series device does not fully support NUMA on a 32-bit OS.
-   Consequently, the sample application cannot work properly on Shumway, since it requires NUMA on both nodes.
-
-**Implication**:
-   The sample application cannot work in 32-bit mode with emulated NUMA, on multi-socket boards.
-
-**Resolution/Workaround**:
-   There is no workaround available.
-
-**Affected Environment/Platform**:
-   Shumway
-
-**Driver/Module**:
-   All.
-
-
-Differences in how different Intel NICs handle maximum packet length for jumbo frame
-------------------------------------------------------------------------------------
-
-**Description**:
-   10 Gigabit Ethernet devices from Intel do not take VLAN tags into account when calculating packet size
-   while Gigabit Ethernet devices do so for jumbo frames.
-
-**Implication**:
-   When receiving packets with VLAN tags, the actual maximum size of useful payload that Intel Gigabit Ethernet
-   devices are able to receive is 4 bytes (or 8 bytes in the case of packets with extended VLAN tags) less than
-   that of Intel 10 Gigabit Ethernet devices.
-
-**Resolution/Workaround**:
-   Increase the configured maximum packet size when using Intel Gigabit Ethernet devices.
-
-**Affected Environment/Platform**:
-   All.
-
-**Driver/Module**:
-   Poll Mode Driver (PMD).
-
-
-Ethertype filter could receive other packets (non-assigned) in Niantic
-----------------------------------------------------------------------
-
-**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
--------------------------------------------------------
-
-**Description**:
-   Promiscuous mode is not supported by the DPDK i40e VF driver when using the
-   i40e Linux kernel driver as host driver.
-
-**Implication**:
-   The i40e VF does not receive packets when the destination MAC address is unknown.
-
-**Resolution/Workaround**:
-   Use a explicit destination MAC address that matches the VF.
-
-**Affected Environment/Platform**:
-   All.
-
-**Driver/Module**:
-   Poll Mode Driver (PMD).
-
-
-uio_pci_generic module bind failed in X710/XL710/XXV710
--------------------------------------------------------
-
-**Description**:
-   The ``uio_pci_generic`` module is not supported by XL710, since the errata of XL710
-   states that the Interrupt Status bit is not implemented. The errata is the item #71
-   from the `xl710 controller spec
-   <http://www.intel.com/content/www/us/en/embedded/products/networking/xl710-10-40-controller-spec-update.html>`_.
-   The hw limitation is the same as other X710/XXV710 NICs.
-
-**Implication**:
-   When use ``--bind=uio_pci_generic``, the ``uio_pci_generic`` module probes device and check the Interrupt
-   Status bit. Since it is not supported by X710/XL710/XXV710, it return a *failed* value. The statement
-   that these products don’t support INTx masking, is indicated in the related `linux kernel commit
-   <https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/pci/quirks.c?id=8bcf4525c5d43306c5fd07e132bc8650e3491aec>`_.
-
-**Resolution/Workaround**:
-   Do not bind the ``uio_pci_generic`` module in X710/XL710/XXV710 NICs.
-
-**Affected Environment/Platform**:
-   All.
-
-**Driver/Module**:
-   Poll Mode Driver (PMD).
-
-
-virtio tx_burst() function cannot do TSO on shared packets
-----------------------------------------------------------
-
-**Description**:
-   The standard TX function of virtio driver does not manage shared
-   packets properly when doing TSO. These packets should be read-only
-   but the driver modifies them.
-
-   When doing TSO, the virtio standard expects that the L4 checksum is
-   set to the pseudo header checksum in the packet data, which is
-   different than the DPDK API. The driver patches the L4 checksum to
-   conform to the virtio standard, but this solution is invalid when
-   dealing with shared packets (clones), because the packet data should
-   not be modified.
-
-**Implication**:
-   In this situation, the shared data will be modified by the driver,
-   potentially causing race conditions with the other users of the mbuf
-   data.
-
-**Resolution/Workaround**:
-   The workaround in the application is to ensure that the network
-   headers in the packet data are not shared.
-
-**Affected Environment/Platform**:
-   Virtual machines running a virtio driver.
-
-**Driver/Module**:
-   Poll Mode Driver (PMD).
-
-
-igb_uio legacy mode can not be used in X710/XL710/XXV710
---------------------------------------------------------
-
-**Description**:
-   X710/XL710/XXV710 NICs lack support for indicating INTx is asserted via the interrupt
-   bit in the PCI status register. Linux deleted them from INTx support table. The related
-   `commit <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/pci/quirks.c?id=8bcf4525c5d43306c5fd07e132bc8650e3491aec>`_.
-
-**Implication**:
-   When insmod ``igb_uio`` with ``intr_mode=legacy`` and test link status interrupt. Since
-   INTx interrupt is not supported by X710/XL710/XXV710, it will cause Input/Output error
-   when reading file descriptor.
-
-**Resolution/Workaround**:
-   Do not bind ``igb_uio`` with legacy mode in X710/XL710/XXV710 NICs, or do not use kernel
-   version >4.7 when you bind ``igb_uio`` with legacy mode.
-
-**Affected Environment/Platform**:
-   ALL.
-
-**Driver/Module**:
-   Poll Mode Driver (PMD).
-
-
-igb_uio can not be used when running l3fwd-power
-------------------------------------------------
-
-**Description**:
-   Link Status Change(LSC) interrupt and packet receiving interrupt are all enabled in l3fwd-power
-   APP. Because of UIO only support one interrupt, so these two kinds of interrupt need to share
-   one, and the receiving interrupt have the higher priority, so can't get the right link status.
-
-**Implication**:
-   When insmod ``igb_uio`` and running l3fwd-power APP, link status getting doesn't work properly.
-
-**Resolution/Workaround**:
-   Use vfio-pci when LSC and packet receiving interrupt enabled.
-
-**Affected Environment/Platform**:
-   ALL.
-
-**Driver/Module**:
-   ``igb_uio`` module.
-
-
-Linux kernel 4.10.0 iommu attribute read error
-----------------------------------------------
-
-**Description**:
-   When VT-d is enabled (``iommu=pt intel_iommu=on``), reading IOMMU attributes from
-   /sys/devices/virtual/iommu/dmarXXX/intel-iommu/cap on Linux kernel 4.10.0 error.
-   This bug is fixed in `Linux commit a7fdb6e648fb
-   <https://patchwork.kernel.org/patch/9595727/>`_,
-   This bug is introduced in `Linux commit 39ab9555c241
-   <https://patchwork.kernel.org/patch/9554403/>`_,
-
-**Implication**:
-   When binding devices to VFIO and attempting to run testpmd application,
-   testpmd (and other DPDK applications) will not initialize.
-
-**Resolution/Workaround**:
-   Use other linux kernel version. It only happens in linux kernel 4.10.0.
-
-**Affected Environment/Platform**:
-   ALL OS of linux kernel 4.10.0.
-
-**Driver/Module**:
-   ``vfio-pci`` module.
-
-Netvsc driver and application restart
--------------------------------------
-
-**Description**:
-   The Linux kernel uio_hv_generic driver does not completely shutdown and clean up
-   resources properly if application using Netvsc PMD exits.
-
-**Implication**:
-   When application using Netvsc PMD is restarted it can not complete initialization
-   handshake sequence with the host.
-
-**Resolution/Workaround**:
-   Either reboot the guest or remove and reinsert the uio_hv_generic module.
-
-**Affected Environment/Platform**:
-   Linux Hyper-V.
-
-**Driver/Module**:
-   ``uio_hv_generic`` module.
-
-
-PHY link up fails when rebinding i40e NICs to kernel driver
------------------------------------------------------------
-
-**Description**:
-   Some kernel drivers are not able to handle the link status correctly
-   after DPDK application sets the PHY to link down.
-
-**Implication**:
-   The link status can't be set to "up" after the NIC is rebound to the
-   kernel driver. Before a DPDK application quits it will invoke the
-   function ``i40e_dev_stop()`` which will sets the PHY to link down. Some
-   kernel drivers may not be able to handle the link status correctly after
-   it retakes control of the device. This is a known PHY link configuration
-   issue in the i40e kernel driver. The fix has been addressed in the 2.7.4 rc
-   version. So if the i40e kernel driver is < 2.7.4 and doesn't have the
-   fix backported it will encounter this issue.
-
-**Resolution/Workaround**:
-   First try to remove and reinsert the i40e kernel driver. If that fails
-   reboot the system.
-
-**Affected Environment/Platform**:
-   All.
-
-**Driver/Module**:
-   Poll Mode Driver (PMD).
-
-
-Restricted vdev ethdev operations supported in secondary process
-----------------------------------------------------------------
-**Description**
-   In current virtual device sharing model, Ethernet device data structure will be
-   shared between primary and secondary process. Only those Ethernet device operations
-   which based on it are workable in secondary process.
-
-**Implication**
-   Some Ethernet device operations like device start/stop will be failed on virtual
-   device in secondary process.
-
-**Affected Environment/Platform**:
-   ALL.
-
-**Driver/Module**:
-   Virtual Device Poll Mode Driver (PMD).
-
-
-Kernel crash when hot-unplug igb_uio device while DPDK application is running
------------------------------------------------------------------------------
-
-**Description**:
-   When device has been bound to igb_uio driver and application is running,
-   hot-unplugging the device may cause kernel crash.
-
-**Reason**:
-   When device is hot-unplugged, igb_uio driver will be removed which will destroy UIO resources.
-   Later trying to access any UIO resource will cause kernel crash.
-
-**Resolution/Workaround**:
-   If using DPDK for PCI HW hot-unplug, prefer to bind device with VFIO instead of IGB_UIO.
-
-**Affected Environment/Platform**:
-    ALL.
-
-**Driver/Module**:
-   ``igb_uio`` module.
-
-
-AVX-512 support disabled
-------------------------
-
-**Description**:
-   ``AVX-512`` support has been disabled on some conditions.
-
-   On DPDK v18.11 ``AVX-512`` is disabled for all ``GCC`` builds which reported to cause a performance
-   drop.
-
-   On DPDK v19.02 ``AVX-512`` disable scope is reduced to ``GCC`` and ``binutils version 2.30`` based
-   on information accrued from the GCC community defect.
-
-**Reason**:
-   Generated ``AVX-512`` code cause crash:
-   https://bugs.dpdk.org/show_bug.cgi?id=97
-   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88096
-
-**Resolution/Workaround**:
-   * Update ``binutils`` to newer version than ``2.30``.
-
-   OR
-
-   * Use different compiler, like ``clang`` for this case.
-
-**Affected Environment/Platform**:
-    ``GCC`` and ``binutils version 2.30``.
-
-**Driver/Module**:
-    ALL.
-
-
-Unsuitable IOVA mode may be picked as the default
--------------------------------------------------
-
-**Description**
-   Not all kernel drivers and not all devices support all IOVA modes. EAL will
-   attempt to pick a reasonable default based on a number of factors, but there
-   may be cases where the default may be unsuitable (for example, hotplugging
-   devices using `igb_uio` driver while having picked IOVA as VA mode on EAL
-   initialization).
-
-**Implication**
-   Some devices (hotplugged or otherwise) may not work due to incompatible IOVA
-   mode being automatically picked by EAL.
-
-**Resolution/Workaround**:
-   It is possible to force EAL to pick a particular IOVA mode by using the
-   `--iova-mode` command-line parameter. If conflicting requirements are present
-   (such as one device requiring IOVA as PA and one requiring IOVA as VA mode),
-   there is no workaround.
-
-**Affected Environment/Platform**:
-   Linux.
-
-**Driver/Module**:
-   ALL.
-
-Vhost multi-queue reconnection failed with QEMU version 4.2.0 to 5.1.0
-----------------------------------------------------------------------
-
-**Description**
-   It's a QEMU regression bug (bad commit: c6beefd674ff). QEMU only saves
-   acked features for one vhost-net when vhost quits. When vhost reconnects
-   to virtio-net/virtio-pmd in multi-queue situations, the features been
-   set multiple times are not consistent. QEMU-5.2.0 fixes this issue in commit
-   f66337bdbfda ("vhost-user: save features of multiqueues if chardev is closed").
-
-**Implication**
-   Vhost cannot reconnect back to virtio-net/virtio-pmd normally.
-
-**Resolution/Workaround**:
-   It is possible to filter the incorrect acked features at vhost-user side.
-
-**Affected Environment/Platform**:
-   ALL.
-
-**Driver/Module**:
-   Virtual Device Poll Mode Driver (PMD).
-- 
2.34.1