xref: /dpdk/doc/guides/rel_notes/known_issues.rst (revision ae20b97726caa7a9d208e607ec23271009e66b70)
15630257fSFerruh Yigit..  SPDX-License-Identifier: BSD-3-Clause
25630257fSFerruh Yigit    Copyright(c) 2010-2014 Intel Corporation.
36e718ae0SBernard Iremonger
47b9307e9SJohn McNamaraKnown Issues and Limitations in Legacy Releases
57b9307e9SJohn McNamara===============================================
67b9307e9SJohn McNamara
77b9307e9SJohn McNamaraThis section describes known issues with the DPDK software that aren't covered in the version specific release
87b9307e9SJohn McNamaranotes sections.
97b9307e9SJohn McNamara
106e718ae0SBernard Iremonger
110568c997SSiobhan ButlerUnit Test for Link Bonding may fail at test_tlb_tx_burst()
120568c997SSiobhan Butler----------------------------------------------------------
137b9307e9SJohn McNamara
147b9307e9SJohn McNamara**Description**:
157b9307e9SJohn McNamara   Unit tests will fail in ``test_tlb_tx_burst()`` function with error for uneven distribution of packets.
167b9307e9SJohn McNamara
177b9307e9SJohn McNamara**Implication**:
187b9307e9SJohn McNamara   Unit test link_bonding_autotest will fail.
197b9307e9SJohn McNamara
207b9307e9SJohn McNamara**Resolution/Workaround**:
217b9307e9SJohn McNamara   There is no workaround available.
227b9307e9SJohn McNamara
237b9307e9SJohn McNamara**Affected Environment/Platform**:
247b9307e9SJohn McNamara   Fedora 20.
257b9307e9SJohn McNamara
267b9307e9SJohn McNamara**Driver/Module**:
277b9307e9SJohn McNamara   Link Bonding.
280568c997SSiobhan Butler
290568c997SSiobhan Butler
306e718ae0SBernard IremongerPause Frame Forwarding does not work properly on igb
316e718ae0SBernard Iremonger----------------------------------------------------
326e718ae0SBernard Iremonger
337b9307e9SJohn McNamara**Description**:
347b9307e9SJohn McNamara   For igb devices rte_eth_flow_ctrl_set does not work as expected.
357b9307e9SJohn McNamara   Pause frames are always forwarded on igb, regardless of the ``RFCE``, ``MPMCF`` and ``DPF`` registers.
367b9307e9SJohn McNamara
377b9307e9SJohn McNamara**Implication**:
387b9307e9SJohn McNamara   Pause frames will never be rejected by the host on 1G NICs and they will always be forwarded.
397b9307e9SJohn McNamara
407b9307e9SJohn McNamara**Resolution/Workaround**:
417b9307e9SJohn McNamara   There is no workaround available.
427b9307e9SJohn McNamara
437b9307e9SJohn McNamara**Affected Environment/Platform**:
447b9307e9SJohn McNamara   All.
457b9307e9SJohn McNamara
467b9307e9SJohn McNamara**Driver/Module**:
477b9307e9SJohn McNamara   Poll Mode Driver (PMD).
487b9307e9SJohn McNamara
496e718ae0SBernard Iremonger
506e718ae0SBernard IremongerIn packets provided by the PMD, some flags are missing
516e718ae0SBernard Iremonger------------------------------------------------------
526e718ae0SBernard Iremonger
537b9307e9SJohn McNamara**Description**:
547b9307e9SJohn McNamara   In packets provided by the PMD, some flags are missing.
557b9307e9SJohn McNamara   The application does not have access to information provided by the hardware
567b9307e9SJohn McNamara   (packet is broadcast, packet is multicast, packet is IPv4 and so on).
577b9307e9SJohn McNamara
587b9307e9SJohn McNamara**Implication**:
597b9307e9SJohn McNamara   The ``ol_flags`` field in the ``rte_mbuf`` structure is not correct and should not be used.
607b9307e9SJohn McNamara
617b9307e9SJohn McNamara**Resolution/Workaround**:
627b9307e9SJohn McNamara   The application has to parse the Ethernet header itself to get the information, which is slower.
637b9307e9SJohn McNamara
647b9307e9SJohn McNamara**Affected Environment/Platform**:
657b9307e9SJohn McNamara   All.
667b9307e9SJohn McNamara
677b9307e9SJohn McNamara**Driver/Module**:
687b9307e9SJohn McNamara   Poll Mode Driver (PMD).
696e718ae0SBernard Iremonger
706e718ae0SBernard IremongerThe rte_malloc library is not fully implemented
716e718ae0SBernard Iremonger-----------------------------------------------
726e718ae0SBernard Iremonger
737b9307e9SJohn McNamara**Description**:
747b9307e9SJohn McNamara   The ``rte_malloc`` library is not fully implemented.
757b9307e9SJohn McNamara
767b9307e9SJohn McNamara**Implication**:
777b9307e9SJohn McNamara   All debugging features of rte_malloc library described in architecture documentation are not yet implemented.
787b9307e9SJohn McNamara
797b9307e9SJohn McNamara**Resolution/Workaround**:
807b9307e9SJohn McNamara   No workaround available.
817b9307e9SJohn McNamara
827b9307e9SJohn McNamara**Affected Environment/Platform**:
837b9307e9SJohn McNamara   All.
847b9307e9SJohn McNamara
857b9307e9SJohn McNamara**Driver/Module**:
867b9307e9SJohn McNamara   ``rte_malloc``.
877b9307e9SJohn McNamara
886e718ae0SBernard Iremonger
896e718ae0SBernard IremongerHPET reading is slow
906e718ae0SBernard Iremonger--------------------
916e718ae0SBernard Iremonger
927b9307e9SJohn McNamara**Description**:
937b9307e9SJohn McNamara   Reading the HPET chip is slow.
947b9307e9SJohn McNamara
957b9307e9SJohn McNamara**Implication**:
967b9307e9SJohn McNamara   An application that calls ``rte_get_hpet_cycles()`` or ``rte_timer_manage()`` runs slower.
977b9307e9SJohn McNamara
987b9307e9SJohn McNamara**Resolution/Workaround**:
997b9307e9SJohn McNamara   The application should not call these functions too often in the main loop.
1007b9307e9SJohn McNamara   An alternative is to use the TSC register through ``rte_rdtsc()`` which is faster,
1017b9307e9SJohn McNamara   but specific to an lcore and is a cycle reference, not a time reference.
1027b9307e9SJohn McNamara
1037b9307e9SJohn McNamara**Affected Environment/Platform**:
1047b9307e9SJohn McNamara   All.
1057b9307e9SJohn McNamara
1067b9307e9SJohn McNamara**Driver/Module**:
1077b9307e9SJohn McNamara   Environment Abstraction Layer (EAL).
1087b9307e9SJohn McNamara
1096e718ae0SBernard Iremonger
1106e718ae0SBernard IremongerHPET timers do not work on the Osage customer reference platform
1116e718ae0SBernard Iremonger----------------------------------------------------------------
1126e718ae0SBernard Iremonger
1137b9307e9SJohn McNamara**Description**:
1147b9307e9SJohn McNamara   HPET timers do not work on the Osage customer reference platform which includes an Intel® Xeon® processor 5500
1157b9307e9SJohn McNamara   series processor) using the released BIOS from Intel.
1167b9307e9SJohn McNamara
1177b9307e9SJohn McNamara**Implication**:
1187b9307e9SJohn McNamara   On Osage boards, the implementation of the ``rte_delay_us()`` function must be changed to not use the HPET timer.
1197b9307e9SJohn McNamara
1207b9307e9SJohn McNamara**Resolution/Workaround**:
121513ee0abSThomas Monjalon   This can be addressed by building the system with ``RTE_LIBEAL_USE_HPET`` unset
122513ee0abSThomas Monjalon   or by using the ``--no-hpet`` EAL option.
1237b9307e9SJohn McNamara
1247b9307e9SJohn McNamara**Affected Environment/Platform**:
1257b9307e9SJohn McNamara   The Osage customer reference platform.
1267b9307e9SJohn McNamara   Other vendor platforms with Intel®  Xeon® processor 5500 series processors should
1277b9307e9SJohn McNamara   work correctly, provided the BIOS supports HPET.
1287b9307e9SJohn McNamara
1297b9307e9SJohn McNamara**Driver/Module**:
13099a2dd95SBruce Richardson   ``lib/eal/include/rte_cycles.h``
1317b9307e9SJohn McNamara
1326e718ae0SBernard Iremonger
1336e718ae0SBernard IremongerNot all variants of supported NIC types have been used in testing
1346e718ae0SBernard Iremonger-----------------------------------------------------------------
1356e718ae0SBernard Iremonger
1367b9307e9SJohn McNamara**Description**:
1377b9307e9SJohn McNamara   The supported network interface cards can come in a number of variants with different device ID's.
1384b152471SThomas Monjalon   Not all of these variants have been tested with the DPDK.
1397b9307e9SJohn McNamara
1407b9307e9SJohn McNamara   The NIC device identifiers used during testing:
1417b9307e9SJohn McNamara
1427b9307e9SJohn McNamara   * Intel® Ethernet Controller XL710 for 40GbE QSFP+ [8086:1584]
1437b9307e9SJohn McNamara   * Intel® Ethernet Controller XL710 for 40GbE QSFP+ [8086:1583]
1447b9307e9SJohn McNamara   * Intel® Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
1457b9307e9SJohn McNamara   * Intel® 82576 Gigabit Ethernet Controller [8086:10c9]
1467b9307e9SJohn McNamara   * Intel® 82576 Quad Copper Gigabit Ethernet Controller [8086:10e8]
1477b9307e9SJohn McNamara   * Intel® 82580 Dual Copper Gigabit Ethernet Controller [8086:150e]
1487b9307e9SJohn McNamara   * Intel® I350 Quad Copper Gigabit Ethernet Controller [8086:1521]
1497b9307e9SJohn McNamara   * Intel® 82599 Dual Fibre 10 Gigabit Ethernet Controller [8086:10fb]
1507b9307e9SJohn McNamara   * Intel® Ethernet Server Adapter X520-T2 [8086: 151c]
1517b9307e9SJohn McNamara   * Intel® Ethernet Controller X540-T2 [8086:1528]
1527b9307e9SJohn McNamara   * Intel® 82574L Gigabit Network Connection [8086:10d3]
1537b9307e9SJohn McNamara   * Emulated Intel® 82540EM Gigabit Ethernet Controller [8086:100e]
1547b9307e9SJohn McNamara   * Emulated Intel® 82545EM Gigabit Ethernet Controller [8086:100f]
1557b9307e9SJohn McNamara   * Intel® Ethernet Server Adapter X520-4 [8086:154a]
1567b9307e9SJohn McNamara   * Intel® Ethernet Controller I210 [8086:1533]
1577b9307e9SJohn McNamara
1587b9307e9SJohn McNamara**Implication**:
1597b9307e9SJohn McNamara   Risk of issues with untested variants.
1607b9307e9SJohn McNamara
1617b9307e9SJohn McNamara**Resolution/Workaround**:
1627b9307e9SJohn McNamara   Use tested NIC variants. For those supported Ethernet controllers, additional device
1637b9307e9SJohn McNamara   IDs may be added to the software if required.
1647b9307e9SJohn McNamara
1657b9307e9SJohn McNamara**Affected Environment/Platform**:
1667b9307e9SJohn McNamara   All.
1677b9307e9SJohn McNamara
1687b9307e9SJohn McNamara**Driver/Module**:
1697b9307e9SJohn McNamara   Poll-mode drivers
1707b9307e9SJohn McNamara
1716e718ae0SBernard Iremonger
1726e718ae0SBernard IremongerMulti-process sample app requires exact memory mapping
1736e718ae0SBernard Iremonger------------------------------------------------------
1746e718ae0SBernard Iremonger
1757b9307e9SJohn McNamara**Description**:
1767b9307e9SJohn McNamara   The multi-process example application assumes that
1777b9307e9SJohn McNamara   it is possible to map the hugepage memory to the same virtual addresses in client and server applications.
1787b9307e9SJohn McNamara   Occasionally, very rarely with 64-bit, this does not occur and a client application will fail on startup.
1797b9307e9SJohn McNamara   The Linux "address-space layout randomization" security feature can sometimes cause this to occur.
1806e718ae0SBernard Iremonger
1817b9307e9SJohn McNamara**Implication**:
1827b9307e9SJohn McNamara   A multi-process client application fails to initialize.
1836e718ae0SBernard Iremonger
1847b9307e9SJohn McNamara**Resolution/Workaround**:
1854b152471SThomas Monjalon   See the "Multi-process Limitations" section in the DPDK Programmer's Guide for more information.
1867b9307e9SJohn McNamara
1877b9307e9SJohn McNamara**Affected Environment/Platform**:
1887b9307e9SJohn McNamara   All.
1897b9307e9SJohn McNamara
1907b9307e9SJohn McNamara**Driver/Module**:
1917b9307e9SJohn McNamara   Multi-process example application
1927b9307e9SJohn McNamara
1937b9307e9SJohn McNamara
1947b9307e9SJohn McNamaraPackets 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
1957b9307e9SJohn McNamara----------------------------------------------------------------------------------------------------------------
1967b9307e9SJohn McNamara
1977b9307e9SJohn McNamara**Description**:
1987b9307e9SJohn McNamara   The 1 GbE/10 GbE SR-IOV driver can only send packets when the Ethernet header's source MAC address is the same as
1997b9307e9SJohn McNamara   that of the VF NIC.
2007b9307e9SJohn McNamara   The reason for this is that the Linux ``ixgbe`` driver module in the host OS has its anti-spoofing feature enabled.
2017b9307e9SJohn McNamara
2027b9307e9SJohn McNamara**Implication**:
2037b9307e9SJohn McNamara   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.
2047b9307e9SJohn McNamara   Packets with other source address values are dropped by the NIC if the application attempts to transmit them.
2057b9307e9SJohn McNamara
2067b9307e9SJohn McNamara**Resolution/Workaround**:
2077b9307e9SJohn McNamara   Configure the Ethernet source address in each packet to match that of the VF NIC.
2087b9307e9SJohn McNamara
2097b9307e9SJohn McNamara**Affected Environment/Platform**:
2107b9307e9SJohn McNamara   All.
2117b9307e9SJohn McNamara
2127b9307e9SJohn McNamara**Driver/Module**:
2137b9307e9SJohn McNamara   1 GbE/10 GbE VF Poll Mode Driver (PMD).
2147b9307e9SJohn McNamara
2156e718ae0SBernard Iremonger
2166e718ae0SBernard IremongerSR-IOV drivers do not fully implement the rte_ethdev API
2176e718ae0SBernard Iremonger--------------------------------------------------------
2186e718ae0SBernard Iremonger
2197b9307e9SJohn McNamara**Description**:
2207b9307e9SJohn McNamara   The SR-IOV drivers only supports the following rte_ethdev API functions:
2217b9307e9SJohn McNamara
2227b9307e9SJohn McNamara   * rte_eth_dev_configure()
2237b9307e9SJohn McNamara   * rte_eth_tx_queue_setup()
2247b9307e9SJohn McNamara   * rte_eth_rx_queue_setup()
2257b9307e9SJohn McNamara   * rte_eth_dev_info_get()
2267b9307e9SJohn McNamara   * rte_eth_dev_start()
2277b9307e9SJohn McNamara   * rte_eth_tx_burst()
2287b9307e9SJohn McNamara   * rte_eth_rx_burst()
2297b9307e9SJohn McNamara   * rte_eth_dev_stop()
2307b9307e9SJohn McNamara   * rte_eth_stats_get()
2317b9307e9SJohn McNamara   * rte_eth_stats_reset()
2327b9307e9SJohn McNamara   * rte_eth_link_get()
2337b9307e9SJohn McNamara   * rte_eth_link_get_no_wait()
2347b9307e9SJohn McNamara
2357b9307e9SJohn McNamara**Implication**:
2367b9307e9SJohn McNamara   Calling an unsupported function will result in an application error.
2377b9307e9SJohn McNamara
2387b9307e9SJohn McNamara**Resolution/Workaround**:
2397b9307e9SJohn McNamara   Do not use other rte_ethdev API functions in applications that use the SR-IOV drivers.
2407b9307e9SJohn McNamara
2417b9307e9SJohn McNamara**Affected Environment/Platform**:
2427b9307e9SJohn McNamara   All.
2437b9307e9SJohn McNamara
2447b9307e9SJohn McNamara**Driver/Module**:
2457b9307e9SJohn McNamara   VF Poll Mode Driver (PMD).
2467b9307e9SJohn McNamara
2476e718ae0SBernard Iremonger
2486e718ae0SBernard IremongerPMD does not work with --no-huge EAL command line parameter
2496e718ae0SBernard Iremonger-----------------------------------------------------------
2506e718ae0SBernard Iremonger
2517b9307e9SJohn McNamara**Description**:
252*bf659d18SStanislaw Kardach   Currently, the DPDK does not store any information about memory allocated by ``malloc()``
253*bf659d18SStanislaw Kardach   (for example, NUMA node, physical address),
254*bf659d18SStanislaw Kardach   hence PMDs do not work when the ``--no-huge`` command line parameter is supplied to EAL.
255*bf659d18SStanislaw Kardach   This happens when using non-IOMMU based UIO drivers (i.e. ``igb_uio`` or ``uio_pci_generic``)
256*bf659d18SStanislaw Kardach   or when IOVA mode is explicitly set to use physical addresses
257*bf659d18SStanislaw Kardach   (via the ``--iova-mode=pa`` EAL parameter).
2587b9307e9SJohn McNamara
2597b9307e9SJohn McNamara**Implication**:
2607b9307e9SJohn McNamara   Sending and receiving data with PMD will not work.
261*bf659d18SStanislaw Kardach   Unit tests checking ``--no-huge`` operation will fail if there is a device bound to the PMD
262*bf659d18SStanislaw Kardach   (``eal_flags_n_opt_autotest``, ``eal_flags_no_huge_autotest``,
263*bf659d18SStanislaw Kardach   ``eal_flags_vdev_opt_autotest``, ``eal_flags_misc_autotest``).
2647b9307e9SJohn McNamara
2657b9307e9SJohn McNamara**Resolution/Workaround**:
2667b9307e9SJohn McNamara   Use huge page memory or use VFIO to map devices.
2677b9307e9SJohn McNamara
2687b9307e9SJohn McNamara**Affected Environment/Platform**:
2697b9307e9SJohn McNamara   Systems running the DPDK on Linux
2707b9307e9SJohn McNamara
2717b9307e9SJohn McNamara**Driver/Module**:
2727b9307e9SJohn McNamara   Poll Mode Driver (PMD).
2737b9307e9SJohn McNamara
2746e718ae0SBernard Iremonger
2756e718ae0SBernard IremongerSome hardware off-load functions are not supported by the VF Driver
2766e718ae0SBernard Iremonger-------------------------------------------------------------------
2776e718ae0SBernard Iremonger
2787b9307e9SJohn McNamara**Description**:
2797b9307e9SJohn McNamara   Currently, configuration of the following items is not supported by the VF driver:
2807b9307e9SJohn McNamara
2817b9307e9SJohn McNamara   * IP/UDP/TCP checksum offload
2827b9307e9SJohn McNamara   * Jumbo Frame Receipt
2837b9307e9SJohn McNamara   * HW Strip CRC
2847b9307e9SJohn McNamara
2857b9307e9SJohn McNamara**Implication**:
2867b9307e9SJohn McNamara   Any configuration for these items in the VF register will be ignored.
2877b9307e9SJohn McNamara   The behavior is dependent on the current PF setting.
2887b9307e9SJohn McNamara
2897b9307e9SJohn McNamara**Resolution/Workaround**:
2907b9307e9SJohn McNamara   For the PF (Physical Function) status on which the VF driver depends, there is an option item under PMD in the
2917b9307e9SJohn McNamara   config file.
2927b9307e9SJohn McNamara   For others, the VF will keep the same behavior as PF setting.
2937b9307e9SJohn McNamara
2947b9307e9SJohn McNamara**Affected Environment/Platform**:
2957b9307e9SJohn McNamara   All.
2967b9307e9SJohn McNamara
2977b9307e9SJohn McNamara**Driver/Module**:
2987b9307e9SJohn McNamara   VF (SR-IOV) Poll Mode Driver (PMD).
2997b9307e9SJohn McNamara
3006e718ae0SBernard Iremonger
3016e718ae0SBernard IremongerKernel crash on IGB port unbinding
3026e718ae0SBernard Iremonger----------------------------------
3036e718ae0SBernard Iremonger
3047b9307e9SJohn McNamara**Description**:
3057b9307e9SJohn McNamara   Kernel crash may occur when unbinding 1G ports from the igb_uio driver, on 2.6.3x kernels such as shipped
3067b9307e9SJohn McNamara   with Fedora 14.
3077b9307e9SJohn McNamara
3087b9307e9SJohn McNamara**Implication**:
3097b9307e9SJohn McNamara   Kernel crash occurs.
3107b9307e9SJohn McNamara
3117b9307e9SJohn McNamara**Resolution/Workaround**:
3127b9307e9SJohn McNamara   Use newer kernels or do not unbind ports.
3137b9307e9SJohn McNamara
3147b9307e9SJohn McNamara**Affected Environment/Platform**:
3157b9307e9SJohn McNamara   2.6.3x kernels such as  shipped with Fedora 14
3167b9307e9SJohn McNamara
3177b9307e9SJohn McNamara**Driver/Module**:
3187b9307e9SJohn McNamara   IGB Poll Mode Driver (PMD).
3197b9307e9SJohn McNamara
3206e718ae0SBernard Iremonger
3216e718ae0SBernard IremongerTwinpond and Ironpond NICs do not report link status correctly
3226e718ae0SBernard Iremonger--------------------------------------------------------------
3236e718ae0SBernard Iremonger
3247b9307e9SJohn McNamara**Description**:
3257b9307e9SJohn McNamara   Twin Pond/Iron Pond NICs do not bring the physical link down when shutting down the port.
3267b9307e9SJohn McNamara
3277b9307e9SJohn McNamara**Implication**:
3287b9307e9SJohn McNamara   The link is reported as up even after issuing ``shutdown`` command unless the cable is physically disconnected.
3297b9307e9SJohn McNamara
3307b9307e9SJohn McNamara**Resolution/Workaround**:
3317b9307e9SJohn McNamara   None.
3327b9307e9SJohn McNamara
3337b9307e9SJohn McNamara**Affected Environment/Platform**:
3347b9307e9SJohn McNamara   Twin Pond and Iron Pond NICs
3357b9307e9SJohn McNamara
3367b9307e9SJohn McNamara**Driver/Module**:
3377b9307e9SJohn McNamara   Poll Mode Driver (PMD).
3387b9307e9SJohn McNamara
3396e718ae0SBernard Iremonger
3406e718ae0SBernard IremongerDiscrepancies between statistics reported by different NICs
3416e718ae0SBernard Iremonger-----------------------------------------------------------
3426e718ae0SBernard Iremonger
3437b9307e9SJohn McNamara**Description**:
3447b9307e9SJohn McNamara   Gigabit Ethernet devices from Intel include CRC bytes when calculating packet reception statistics regardless
3457b9307e9SJohn McNamara   of hardware CRC stripping state, while 10-Gigabit Ethernet devices from Intel do so only when hardware CRC
3467b9307e9SJohn McNamara   stripping is disabled.
3477b9307e9SJohn McNamara
3487b9307e9SJohn McNamara**Implication**:
3497b9307e9SJohn McNamara   There may be a  discrepancy in how different NICs display packet reception statistics.
3507b9307e9SJohn McNamara
3517b9307e9SJohn McNamara**Resolution/Workaround**:
3527b9307e9SJohn McNamara   None
3537b9307e9SJohn McNamara
3547b9307e9SJohn McNamara**Affected Environment/Platform**:
3557b9307e9SJohn McNamara   All.
3567b9307e9SJohn McNamara
3577b9307e9SJohn McNamara**Driver/Module**:
3587b9307e9SJohn McNamara   Poll Mode Driver (PMD).
3597b9307e9SJohn McNamara
3606e718ae0SBernard Iremonger
361ac8ada00SSiobhan ButlerError reported opening files on DPDK initialization
362ac8ada00SSiobhan Butler---------------------------------------------------
3636e718ae0SBernard Iremonger
3647b9307e9SJohn McNamara**Description**:
3657b9307e9SJohn McNamara   On DPDK application startup, errors may be reported when opening files as part of the initialization process.
3667b9307e9SJohn McNamara   This occurs if a large number, for example, 500 or more, or if hugepages are used, due to the per-process
3677b9307e9SJohn McNamara   limit on the number of open files.
3686e718ae0SBernard Iremonger
3697b9307e9SJohn McNamara**Implication**:
3707b9307e9SJohn McNamara   The DPDK application may fail to run.
3717b9307e9SJohn McNamara
3727b9307e9SJohn McNamara**Resolution/Workaround**:
3737b9307e9SJohn McNamara   If using 2 MB hugepages, consider switching to a fewer number of 1 GB pages.
3747b9307e9SJohn McNamara   Alternatively, use the ``ulimit`` command to increase the number of files which can be opened by a process.
3757b9307e9SJohn McNamara
3767b9307e9SJohn McNamara**Affected Environment/Platform**:
3777b9307e9SJohn McNamara   All.
3787b9307e9SJohn McNamara
3797b9307e9SJohn McNamara**Driver/Module**:
3807b9307e9SJohn McNamara   Environment Abstraction Layer (EAL).
3817b9307e9SJohn McNamara
3826e718ae0SBernard Iremonger
3836e718ae0SBernard IremongerIntel® QuickAssist Technology sample application does not work on a 32-bit OS on Shumway
3846e718ae0SBernard Iremonger----------------------------------------------------------------------------------------
3856e718ae0SBernard Iremonger
3867b9307e9SJohn McNamara**Description**:
3877b9307e9SJohn McNamara   The Intel® Communications Chipset 89xx Series device does not fully support NUMA on a 32-bit OS.
3887b9307e9SJohn McNamara   Consequently, the sample application cannot work properly on Shumway, since it requires NUMA on both nodes.
3897b9307e9SJohn McNamara
3907b9307e9SJohn McNamara**Implication**:
3917b9307e9SJohn McNamara   The sample application cannot work in 32-bit mode with emulated NUMA, on multi-socket boards.
3927b9307e9SJohn McNamara
3937b9307e9SJohn McNamara**Resolution/Workaround**:
3947b9307e9SJohn McNamara   There is no workaround available.
3957b9307e9SJohn McNamara
3967b9307e9SJohn McNamara**Affected Environment/Platform**:
3977b9307e9SJohn McNamara   Shumway
3987b9307e9SJohn McNamara
3997b9307e9SJohn McNamara**Driver/Module**:
4007b9307e9SJohn McNamara   All.
4017b9307e9SJohn McNamara
4026e718ae0SBernard Iremonger
4036e718ae0SBernard IremongerDifferences in how different Intel NICs handle maximum packet length for jumbo frame
4046e718ae0SBernard Iremonger------------------------------------------------------------------------------------
4056e718ae0SBernard Iremonger
4067b9307e9SJohn McNamara**Description**:
4077b9307e9SJohn McNamara   10 Gigabit Ethernet devices from Intel do not take VLAN tags into account when calculating packet size
4087b9307e9SJohn McNamara   while Gigabit Ethernet devices do so for jumbo frames.
4096e718ae0SBernard Iremonger
4107b9307e9SJohn McNamara**Implication**:
4117b9307e9SJohn McNamara   When receiving packets with VLAN tags, the actual maximum size of useful payload that Intel Gigabit Ethernet
4127b9307e9SJohn McNamara   devices are able to receive is 4 bytes (or 8 bytes in the case of packets with extended VLAN tags) less than
4137b9307e9SJohn McNamara   that of Intel 10 Gigabit Ethernet devices.
4146e718ae0SBernard Iremonger
4157b9307e9SJohn McNamara**Resolution/Workaround**:
4167b9307e9SJohn McNamara   Increase the configured maximum packet size when using Intel Gigabit Ethernet devices.
4177b9307e9SJohn McNamara
4187b9307e9SJohn McNamara**Affected Environment/Platform**:
4197b9307e9SJohn McNamara   All.
4207b9307e9SJohn McNamara
4217b9307e9SJohn McNamara**Driver/Module**:
4227b9307e9SJohn McNamara   Poll Mode Driver (PMD).
4237b9307e9SJohn McNamara
4247b9307e9SJohn McNamara
4256e718ae0SBernard IremongerGCC might generate Intel® AVX instructions for processors without Intel® AVX support
426fea1d908SJohn McNamara------------------------------------------------------------------------------------
4276e718ae0SBernard Iremonger
4287b9307e9SJohn McNamara**Description**:
4294b152471SThomas Monjalon   When compiling DPDK (and any DPDK app), gcc may generate Intel® AVX instructions, even when the
4307b9307e9SJohn McNamara   processor does not support Intel® AVX.
4317b9307e9SJohn McNamara
4327b9307e9SJohn McNamara**Implication**:
4337b9307e9SJohn McNamara   Any DPDK app might crash while starting up.
4347b9307e9SJohn McNamara
4357b9307e9SJohn McNamara**Resolution/Workaround**:
4367b9307e9SJohn McNamara   Either compile using icc or set ``EXTRA_CFLAGS='-O3'`` prior to compilation.
4377b9307e9SJohn McNamara
4387b9307e9SJohn McNamara**Affected Environment/Platform**:
4397b9307e9SJohn McNamara   Platforms which processor does not support Intel® AVX.
4407b9307e9SJohn McNamara
4417b9307e9SJohn McNamara**Driver/Module**:
4427b9307e9SJohn McNamara   Environment Abstraction Layer (EAL).
4436e718ae0SBernard Iremonger
4446e718ae0SBernard IremongerEthertype filter could receive other packets (non-assigned) in Niantic
4456e718ae0SBernard Iremonger----------------------------------------------------------------------
4466e718ae0SBernard Iremonger
4477b9307e9SJohn McNamara**Description**:
4487b9307e9SJohn McNamara   On Intel®  Ethernet Controller 82599EB When Ethertype filter (priority enable) was set, unmatched packets also
4497b9307e9SJohn McNamara   could be received on the assigned queue, such as ARP packets without 802.1q tags or with the user priority not
4507b9307e9SJohn McNamara   equal to set value.
4517b9307e9SJohn McNamara   Launch the testpmd by disabling RSS and with multiply queues, then add the ethertype filter like the following
4527b9307e9SJohn McNamara   and then start forwarding::
4537b9307e9SJohn McNamara
4547b9307e9SJohn McNamara      add_ethertype_filter 0 ethertype 0x0806 priority enable 3 queue 2 index 1
4557b9307e9SJohn McNamara
4567b9307e9SJohn McNamara   When sending ARP packets without 802.1q tag and with user priority as non-3 by tester, all the ARP packets can
4577b9307e9SJohn McNamara   be received on the assigned queue.
4587b9307e9SJohn McNamara
4597b9307e9SJohn McNamara**Implication**:
4607b9307e9SJohn McNamara   The user priority comparing in Ethertype filter cannot work probably.
4617b9307e9SJohn McNamara   It is a NIC's issue due to the following: "In fact, ETQF.UP is not functional, and the information will
4627b9307e9SJohn McNamara   be added in errata of 82599 and X540."
4637b9307e9SJohn McNamara
4647b9307e9SJohn McNamara**Resolution/Workaround**:
4657b9307e9SJohn McNamara   None
4667b9307e9SJohn McNamara
4677b9307e9SJohn McNamara**Affected Environment/Platform**:
4687b9307e9SJohn McNamara   All.
4697b9307e9SJohn McNamara
4707b9307e9SJohn McNamara**Driver/Module**:
4717b9307e9SJohn McNamara   Poll Mode Driver (PMD).
4727b9307e9SJohn McNamara
4736e718ae0SBernard Iremonger
474fea1d908SJohn McNamaraCannot set link speed on Intel® 40G Ethernet controller
4756e718ae0SBernard Iremonger-------------------------------------------------------
4766e718ae0SBernard Iremonger
4777b9307e9SJohn McNamara**Description**:
4787b9307e9SJohn McNamara   On Intel® 40G Ethernet Controller you cannot set the link to specific speed.
4797b9307e9SJohn McNamara
4807b9307e9SJohn McNamara**Implication**:
4817b9307e9SJohn McNamara   The link speed cannot be changed forcibly, though it can be configured by application.
4827b9307e9SJohn McNamara
4837b9307e9SJohn McNamara**Resolution/Workaround**:
4847b9307e9SJohn McNamara   None
4857b9307e9SJohn McNamara
4867b9307e9SJohn McNamara**Affected Environment/Platform**:
4877b9307e9SJohn McNamara   All.
4887b9307e9SJohn McNamara
4897b9307e9SJohn McNamara**Driver/Module**:
4907b9307e9SJohn McNamara   Poll Mode Driver (PMD).
4917b9307e9SJohn McNamara
4926e718ae0SBernard Iremonger
4937b9307e9SJohn McNamaraDevices bound to igb_uio with VT-d enabled do not work on Linux kernel 3.15-3.17
4947b9307e9SJohn McNamara--------------------------------------------------------------------------------
4957b9307e9SJohn McNamara
4967b9307e9SJohn McNamara**Description**:
4977b9307e9SJohn McNamara   When VT-d is enabled (``iommu=pt intel_iommu=on``), devices are 1:1 mapped.
4987b9307e9SJohn McNamara   In the Linux kernel unbinding devices from drivers removes that mapping which result in IOMMU errors.
4997b9307e9SJohn McNamara   Introduced in Linux `kernel 3.15 commit
5007b9307e9SJohn McNamara   <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/iommu/intel-iommu.c?id=816997d03bca9fabcee65f3481eb0297103eceb7>`_,
5017b9307e9SJohn McNamara   solved in Linux `kernel 3.18 commit
5027b9307e9SJohn McNamara   <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/iommu/intel-iommu.c?id=1196c2fb0407683c2df92d3d09f9144d42830894>`_.
5037b9307e9SJohn McNamara
5047b9307e9SJohn McNamara**Implication**:
5057b9307e9SJohn McNamara   Devices will not be allowed to access memory, resulting in following kernel errors::
5067b9307e9SJohn McNamara
5077b9307e9SJohn McNamara      dmar: DRHD: handling fault status reg 2
5087b9307e9SJohn McNamara      dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr a0c58000
5097b9307e9SJohn McNamara      DMAR:[fault reason 02] Present bit in context entry is clear
5107b9307e9SJohn McNamara
5117b9307e9SJohn McNamara**Resolution/Workaround**:
5127b9307e9SJohn McNamara   Use earlier or later kernel versions, or avoid driver binding on boot by blacklisting the driver modules.
5137b9307e9SJohn McNamara   I.e., in the case of ``ixgbe``, we can pass the kernel command line option: ``modprobe.blacklist=ixgbe``.
5147b9307e9SJohn McNamara   This way we do not need to unbind the device to bind it to igb_uio.
5157b9307e9SJohn McNamara
5167b9307e9SJohn McNamara**Affected Environment/Platform**:
5177b9307e9SJohn McNamara   Linux systems with kernel versions 3.15 to 3.17.
5187b9307e9SJohn McNamara
5197b9307e9SJohn McNamara**Driver/Module**:
5207b9307e9SJohn McNamara   ``igb_uio`` module.
5217b9307e9SJohn McNamara
522e9f64db9SPablo de Lara
523e9f64db9SPablo de LaraVM power manager may not work on systems with more than 64 cores
524e9f64db9SPablo de Lara----------------------------------------------------------------
525e9f64db9SPablo de Lara
5267b9307e9SJohn McNamara**Description**:
5277b9307e9SJohn McNamara   When using VM power manager on a system with more than 64 cores, VM(s) should not use cores 64 or higher.
5287b9307e9SJohn McNamara
5297b9307e9SJohn McNamara**Implication**:
5307b9307e9SJohn McNamara   VM power manager should not be used with VM(s) that are using cores 64 or above.
5317b9307e9SJohn McNamara
5327b9307e9SJohn McNamara**Resolution/Workaround**:
5337b9307e9SJohn McNamara   Do not use cores 64 or above.
5347b9307e9SJohn McNamara
5357b9307e9SJohn McNamara**Affected Environment/Platform**:
5367b9307e9SJohn McNamara   Platforms with more than 64 cores.
5377b9307e9SJohn McNamara
5387b9307e9SJohn McNamara**Driver/Module**:
5397b9307e9SJohn McNamara   VM power manager application.
5406e5794d0SPablo de Lara
5416e5794d0SPablo de Lara
5426e5794d0SPablo de LaraDPDK may not build on some Intel CPUs using clang < 3.7.0
5436e5794d0SPablo de Lara---------------------------------------------------------
5446e5794d0SPablo de Lara
5456e5794d0SPablo de Lara**Description**:
5466e5794d0SPablo de Lara   When compiling DPDK with an earlier version than 3.7.0 of clang, CPU flags are not detected on some Intel platforms
5476e5794d0SPablo de Lara   such as Intel Broadwell/Skylake (and possibly future CPUs), and therefore compilation fails due to missing intrinsics.
5486e5794d0SPablo de Lara
5496e5794d0SPablo de Lara**Implication**:
5506e5794d0SPablo de Lara   DPDK will not build when using a clang version < 3.7.0.
5516e5794d0SPablo de Lara
5526e5794d0SPablo de Lara**Resolution/Workaround**:
5536e5794d0SPablo de Lara   Use clang 3.7.0 or higher, or gcc.
5546e5794d0SPablo de Lara
5556e5794d0SPablo de Lara**Affected Environment/Platform**:
5566e5794d0SPablo de Lara   Platforms with Intel Broadwell/Skylake using an old clang version.
5576e5794d0SPablo de Lara
5586e5794d0SPablo de Lara**Driver/Module**:
5596e5794d0SPablo de Lara   Environment Abstraction Layer (EAL).
56015a66c01SJingjing Wu
56115a66c01SJingjing Wu
56215a66c01SJingjing WuThe last EAL argument is replaced by the program name in argv[]
56315a66c01SJingjing Wu---------------------------------------------------------------
56415a66c01SJingjing Wu
56515a66c01SJingjing Wu**Description**:
56615a66c01SJingjing Wu   The last EAL argument is replaced by program name in ``argv[]`` after ``eal_parse_args`` is called.
56715a66c01SJingjing Wu   This is the intended behavior but it causes the pointer to the last EAL argument to be lost.
56815a66c01SJingjing Wu
56915a66c01SJingjing Wu**Implication**:
57015a66c01SJingjing Wu  If the last EAL argument in ``argv[]`` is generated by a malloc function, changing it will cause memory
57115a66c01SJingjing Wu  issues when freeing the argument.
57215a66c01SJingjing Wu
57315a66c01SJingjing Wu**Resolution/Workaround**:
57415a66c01SJingjing Wu   An application should not consider the value in ``argv[]`` as unchanged.
57515a66c01SJingjing Wu
57615a66c01SJingjing Wu**Affected Environment/Platform**:
57715a66c01SJingjing Wu   ALL.
57815a66c01SJingjing Wu
57915a66c01SJingjing Wu**Driver/Module**:
58015a66c01SJingjing Wu   Environment Abstraction Layer (EAL).
581a4045ab3SJeff Guo
582a4045ab3SJeff Guo
583a4045ab3SJeff GuoI40e VF may not receive packets in the promiscuous mode
584a4045ab3SJeff Guo-------------------------------------------------------
585a4045ab3SJeff Guo
586a4045ab3SJeff Guo**Description**:
587a4045ab3SJeff Guo   Promiscuous mode is not supported by the DPDK i40e VF driver when using the
588a4045ab3SJeff Guo   i40e Linux kernel driver as host driver.
589a4045ab3SJeff Guo
590a4045ab3SJeff Guo**Implication**:
591a4045ab3SJeff Guo   The i40e VF does not receive packets when the destination MAC address is unknown.
592a4045ab3SJeff Guo
593a4045ab3SJeff Guo**Resolution/Workaround**:
594a4045ab3SJeff Guo   Use a explicit destination MAC address that matches the VF.
595a4045ab3SJeff Guo
596a4045ab3SJeff Guo**Affected Environment/Platform**:
597a4045ab3SJeff Guo   All.
598a4045ab3SJeff Guo
599a4045ab3SJeff Guo**Driver/Module**:
600a4045ab3SJeff Guo   Poll Mode Driver (PMD).
60139922c47SJeff Guo
60239922c47SJeff Guo
603b7fe612aSThomas Monjalonuio_pci_generic module bind failed in X710/XL710/XXV710
60439922c47SJeff Guo-------------------------------------------------------
60539922c47SJeff Guo
60639922c47SJeff Guo**Description**:
60739922c47SJeff Guo   The ``uio_pci_generic`` module is not supported by XL710, since the errata of XL710
60839922c47SJeff Guo   states that the Interrupt Status bit is not implemented. The errata is the item #71
60939922c47SJeff Guo   from the `xl710 controller spec
61039922c47SJeff Guo   <http://www.intel.com/content/www/us/en/embedded/products/networking/xl710-10-40-controller-spec-update.html>`_.
61139922c47SJeff Guo   The hw limitation is the same as other X710/XXV710 NICs.
61239922c47SJeff Guo
61339922c47SJeff Guo**Implication**:
61439922c47SJeff Guo   When use ``--bind=uio_pci_generic``, the ``uio_pci_generic`` module probes device and check the Interrupt
61539922c47SJeff Guo   Status bit. Since it is not supported by X710/XL710/XXV710, it return a *failed* value. The statement
61639922c47SJeff Guo   that these products don’t support INTx masking, is indicated in the related `linux kernel commit
61739922c47SJeff Guo   <https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/pci/quirks.c?id=8bcf4525c5d43306c5fd07e132bc8650e3491aec>`_.
61839922c47SJeff Guo
61939922c47SJeff Guo**Resolution/Workaround**:
62039922c47SJeff Guo   Do not bind the ``uio_pci_generic`` module in X710/XL710/XXV710 NICs.
62139922c47SJeff Guo
62239922c47SJeff Guo**Affected Environment/Platform**:
62339922c47SJeff Guo   All.
62439922c47SJeff Guo
62539922c47SJeff Guo**Driver/Module**:
62639922c47SJeff Guo   Poll Mode Driver (PMD).
627604a6949SOlivier Matz
628604a6949SOlivier Matz
629604a6949SOlivier Matzvirtio tx_burst() function cannot do TSO on shared packets
630604a6949SOlivier Matz----------------------------------------------------------
631604a6949SOlivier Matz
632604a6949SOlivier Matz**Description**:
633604a6949SOlivier Matz   The standard TX function of virtio driver does not manage shared
634604a6949SOlivier Matz   packets properly when doing TSO. These packets should be read-only
635604a6949SOlivier Matz   but the driver modifies them.
636604a6949SOlivier Matz
637604a6949SOlivier Matz   When doing TSO, the virtio standard expects that the L4 checksum is
638604a6949SOlivier Matz   set to the pseudo header checksum in the packet data, which is
639604a6949SOlivier Matz   different than the DPDK API. The driver patches the L4 checksum to
640604a6949SOlivier Matz   conform to the virtio standard, but this solution is invalid when
641604a6949SOlivier Matz   dealing with shared packets (clones), because the packet data should
642604a6949SOlivier Matz   not be modified.
643604a6949SOlivier Matz
644604a6949SOlivier Matz**Implication**:
645604a6949SOlivier Matz   In this situation, the shared data will be modified by the driver,
646604a6949SOlivier Matz   potentially causing race conditions with the other users of the mbuf
647604a6949SOlivier Matz   data.
648604a6949SOlivier Matz
649604a6949SOlivier Matz**Resolution/Workaround**:
650604a6949SOlivier Matz   The workaround in the application is to ensure that the network
651604a6949SOlivier Matz   headers in the packet data are not shared.
652604a6949SOlivier Matz
653604a6949SOlivier Matz**Affected Environment/Platform**:
654604a6949SOlivier Matz   Virtual machines running a virtio driver.
655604a6949SOlivier Matz
656604a6949SOlivier Matz**Driver/Module**:
657604a6949SOlivier Matz   Poll Mode Driver (PMD).
65886fa6c57SQiming Yang
65986fa6c57SQiming Yang
660b7fe612aSThomas Monjalonigb_uio legacy mode can not be used in X710/XL710/XXV710
66186fa6c57SQiming Yang--------------------------------------------------------
66286fa6c57SQiming Yang
66386fa6c57SQiming Yang**Description**:
66486fa6c57SQiming Yang   X710/XL710/XXV710 NICs lack support for indicating INTx is asserted via the interrupt
665d629b7b5SJohn McNamara   bit in the PCI status register. Linux deleted them from INTx support table. The related
66686fa6c57SQiming Yang   `commit <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/pci/quirks.c?id=8bcf4525c5d43306c5fd07e132bc8650e3491aec>`_.
66786fa6c57SQiming Yang
66886fa6c57SQiming Yang**Implication**:
66986fa6c57SQiming Yang   When insmod ``igb_uio`` with ``intr_mode=legacy`` and test link status interrupt. Since
67086fa6c57SQiming Yang   INTx interrupt is not supported by X710/XL710/XXV710, it will cause Input/Output error
67186fa6c57SQiming Yang   when reading file descriptor.
67286fa6c57SQiming Yang
67386fa6c57SQiming Yang**Resolution/Workaround**:
67486fa6c57SQiming Yang   Do not bind ``igb_uio`` with legacy mode in X710/XL710/XXV710 NICs, or do not use kernel
67586fa6c57SQiming Yang   version >4.7 when you bind ``igb_uio`` with legacy mode.
67686fa6c57SQiming Yang
67786fa6c57SQiming Yang**Affected Environment/Platform**:
67886fa6c57SQiming Yang   ALL.
67986fa6c57SQiming Yang
68086fa6c57SQiming Yang**Driver/Module**:
68186fa6c57SQiming Yang   Poll Mode Driver (PMD).
682412c8c07SQiming Yang
683412c8c07SQiming Yang
684412c8c07SQiming Yangigb_uio can not be used when running l3fwd-power
685412c8c07SQiming Yang------------------------------------------------
686412c8c07SQiming Yang
687412c8c07SQiming Yang**Description**:
688412c8c07SQiming Yang   Link Status Change(LSC) interrupt and packet receiving interrupt are all enabled in l3fwd-power
689412c8c07SQiming Yang   APP. Because of UIO only support one interrupt, so these two kinds of interrupt need to share
690412c8c07SQiming Yang   one, and the receiving interrupt have the higher priority, so can't get the right link status.
691412c8c07SQiming Yang
692412c8c07SQiming Yang**Implication**:
693412c8c07SQiming Yang   When insmod ``igb_uio`` and running l3fwd-power APP, link status getting doesn't work properly.
694412c8c07SQiming Yang
695412c8c07SQiming Yang**Resolution/Workaround**:
696412c8c07SQiming Yang   Use vfio-pci when LSC and packet receiving interrupt enabled.
697412c8c07SQiming Yang
698412c8c07SQiming Yang**Affected Environment/Platform**:
699412c8c07SQiming Yang   ALL.
700412c8c07SQiming Yang
701412c8c07SQiming Yang**Driver/Module**:
702412c8c07SQiming Yang   ``igb_uio`` module.
703b667029eSRosen Xu
704b667029eSRosen Xu
705b667029eSRosen XuLinux kernel 4.10.0 iommu attribute read error
706b667029eSRosen Xu----------------------------------------------
707b667029eSRosen Xu
708b667029eSRosen Xu**Description**:
709b667029eSRosen Xu   When VT-d is enabled (``iommu=pt intel_iommu=on``), reading IOMMU attributes from
710b667029eSRosen Xu   /sys/devices/virtual/iommu/dmarXXX/intel-iommu/cap on Linux kernel 4.10.0 error.
711d629b7b5SJohn McNamara   This bug is fixed in `Linux commit a7fdb6e648fb
712b667029eSRosen Xu   <https://patchwork.kernel.org/patch/9595727/>`_,
713d629b7b5SJohn McNamara   This bug is introduced in `Linux commit 39ab9555c241
714b667029eSRosen Xu   <https://patchwork.kernel.org/patch/9554403/>`_,
715b667029eSRosen Xu
716b667029eSRosen Xu**Implication**:
717b667029eSRosen Xu   When binding devices to VFIO and attempting to run testpmd application,
718b667029eSRosen Xu   testpmd (and other DPDK applications) will not initialize.
719b667029eSRosen Xu
720b667029eSRosen Xu**Resolution/Workaround**:
721b667029eSRosen Xu   Use other linux kernel version. It only happens in linux kernel 4.10.0.
722b667029eSRosen Xu
723b667029eSRosen Xu**Affected Environment/Platform**:
724b667029eSRosen Xu   ALL OS of linux kernel 4.10.0.
725b667029eSRosen Xu
726b667029eSRosen Xu**Driver/Module**:
727b667029eSRosen Xu   ``vfio-pci`` module.
728beff6d8eSStephen Hemminger
729beff6d8eSStephen HemmingerNetvsc driver and application restart
730beff6d8eSStephen Hemminger-------------------------------------
731beff6d8eSStephen Hemminger
732beff6d8eSStephen Hemminger**Description**:
733beff6d8eSStephen Hemminger   The Linux kernel uio_hv_generic driver does not completely shutdown and clean up
734beff6d8eSStephen Hemminger   resources properly if application using Netvsc PMD exits.
735beff6d8eSStephen Hemminger
736beff6d8eSStephen Hemminger**Implication**:
737beff6d8eSStephen Hemminger   When application using Netvsc PMD is restarted it can not complete initialization
738beff6d8eSStephen Hemminger   handshake sequence with the host.
739beff6d8eSStephen Hemminger
740beff6d8eSStephen Hemminger**Resolution/Workaround**:
741b7fe612aSThomas Monjalon   Either reboot the guest or remove and reinsert the uio_hv_generic module.
742beff6d8eSStephen Hemminger
743beff6d8eSStephen Hemminger**Affected Environment/Platform**:
744beff6d8eSStephen Hemminger   Linux Hyper-V.
745beff6d8eSStephen Hemminger
746beff6d8eSStephen Hemminger**Driver/Module**:
747beff6d8eSStephen Hemminger   ``uio_hv_generic`` module.
748c4206973SJeff Guo
749c4206973SJeff Guo
750c4206973SJeff GuoPHY link up fails when rebinding i40e NICs to kernel driver
751c4206973SJeff Guo-----------------------------------------------------------
752c4206973SJeff Guo
753c4206973SJeff Guo**Description**:
754c4206973SJeff Guo   Some kernel drivers are not able to handle the link status correctly
755c4206973SJeff Guo   after DPDK application sets the PHY to link down.
756c4206973SJeff Guo
757c4206973SJeff Guo**Implication**:
758c4206973SJeff Guo   The link status can't be set to "up" after the NIC is rebound to the
759c4206973SJeff Guo   kernel driver. Before a DPDK application quits it will invoke the
760c4206973SJeff Guo   function ``i40e_dev_stop()`` which will sets the PHY to link down. Some
761c4206973SJeff Guo   kernel drivers may not be able to handle the link status correctly after
762c4206973SJeff Guo   it retakes control of the device. This is a known PHY link configuration
763c4206973SJeff Guo   issue in the i40e kernel driver. The fix has been addressed in the 2.7.4 rc
764c4206973SJeff Guo   version. So if the i40e kernel driver is < 2.7.4 and doesn't have the
765c4206973SJeff Guo   fix backported it will encounter this issue.
766c4206973SJeff Guo
767c4206973SJeff Guo**Resolution/Workaround**:
768c4206973SJeff Guo   First try to remove and reinsert the i40e kernel driver. If that fails
769c4206973SJeff Guo   reboot the system.
770c4206973SJeff Guo
771c4206973SJeff Guo**Affected Environment/Platform**:
772c4206973SJeff Guo   All.
773c4206973SJeff Guo
774c4206973SJeff Guo**Driver/Module**:
775c4206973SJeff Guo   Poll Mode Driver (PMD).
776174d15deSMarvin Liu
777174d15deSMarvin Liu
778174d15deSMarvin LiuRestricted vdev ethdev operations supported in secondary process
779174d15deSMarvin Liu----------------------------------------------------------------
780174d15deSMarvin Liu**Description**
781174d15deSMarvin Liu   In current virtual device sharing model, Ethernet device data structure will be
782174d15deSMarvin Liu   shared between primary and secondary process. Only those Ethernet device operations
783174d15deSMarvin Liu   which based on it are workable in secondary process.
784174d15deSMarvin Liu
785174d15deSMarvin Liu**Implication**
786174d15deSMarvin Liu   Some Ethernet device operations like device start/stop will be failed on virtual
787174d15deSMarvin Liu   device in secondary process.
788174d15deSMarvin Liu
789174d15deSMarvin Liu**Affected Environment/Platform**:
790174d15deSMarvin Liu   ALL.
791174d15deSMarvin Liu
792174d15deSMarvin Liu**Driver/Module**:
793174d15deSMarvin Liu   Virtual Device Poll Mode Driver (PMD).
794a2e97ef7SJeff Guo
795a2e97ef7SJeff Guo
796a2e97ef7SJeff GuoKernel crash when hot-unplug igb_uio device while DPDK application is running
797a2e97ef7SJeff Guo-----------------------------------------------------------------------------
798a2e97ef7SJeff Guo
799a2e97ef7SJeff Guo**Description**:
800a2e97ef7SJeff Guo   When device has been bound to igb_uio driver and application is running,
801a2e97ef7SJeff Guo   hot-unplugging the device may cause kernel crash.
802a2e97ef7SJeff Guo
803a2e97ef7SJeff Guo**Reason**:
804a2e97ef7SJeff Guo   When device is hot-unplugged, igb_uio driver will be removed which will destroy UIO resources.
805b7fe612aSThomas Monjalon   Later trying to access any UIO resource will cause kernel crash.
806a2e97ef7SJeff Guo
807a2e97ef7SJeff Guo**Resolution/Workaround**:
808a2e97ef7SJeff Guo   If using DPDK for PCI HW hot-unplug, prefer to bind device with VFIO instead of IGB_UIO.
809a2e97ef7SJeff Guo
810a2e97ef7SJeff Guo**Affected Environment/Platform**:
811a2e97ef7SJeff Guo    ALL.
812a2e97ef7SJeff Guo
813a2e97ef7SJeff Guo**Driver/Module**:
814a2e97ef7SJeff Guo   ``igb_uio`` module.
815a32ca9a4SFerruh Yigit
816a32ca9a4SFerruh Yigit
817a32ca9a4SFerruh YigitAVX-512 support disabled
818a32ca9a4SFerruh Yigit------------------------
819a32ca9a4SFerruh Yigit
820a32ca9a4SFerruh Yigit**Description**:
821a32ca9a4SFerruh Yigit   ``AVX-512`` support has been disabled on some conditions.
822a32ca9a4SFerruh Yigit
823a32ca9a4SFerruh Yigit   On DPDK v18.11 ``AVX-512`` is disabled for all ``GCC`` builds which reported to cause a performance
824a32ca9a4SFerruh Yigit   drop.
825a32ca9a4SFerruh Yigit
826a32ca9a4SFerruh Yigit   On DPDK v19.02 ``AVX-512`` disable scope is reduced to ``GCC`` and ``binutils version 2.30`` based
827d629b7b5SJohn McNamara   on information accrued from the GCC community defect.
828a32ca9a4SFerruh Yigit
829a32ca9a4SFerruh Yigit**Reason**:
830a32ca9a4SFerruh Yigit   Generated ``AVX-512`` code cause crash:
831a32ca9a4SFerruh Yigit   https://bugs.dpdk.org/show_bug.cgi?id=97
832a32ca9a4SFerruh Yigit   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88096
833a32ca9a4SFerruh Yigit
834a32ca9a4SFerruh Yigit**Resolution/Workaround**:
835a32ca9a4SFerruh Yigit   * Update ``binutils`` to newer version than ``2.30``.
836a32ca9a4SFerruh Yigit
837a32ca9a4SFerruh Yigit   OR
838a32ca9a4SFerruh Yigit
839a32ca9a4SFerruh Yigit   * Use different compiler, like ``clang`` for this case.
840a32ca9a4SFerruh Yigit
841a32ca9a4SFerruh Yigit**Affected Environment/Platform**:
842a32ca9a4SFerruh Yigit    ``GCC`` and ``binutils version 2.30``.
843a32ca9a4SFerruh Yigit
844a32ca9a4SFerruh Yigit**Driver/Module**:
845a32ca9a4SFerruh Yigit    ALL.
84679a0bbe5SAnatoly Burakov
84779a0bbe5SAnatoly Burakov
84879a0bbe5SAnatoly BurakovUnsuitable IOVA mode may be picked as the default
84979a0bbe5SAnatoly Burakov-------------------------------------------------
85079a0bbe5SAnatoly Burakov
85179a0bbe5SAnatoly Burakov**Description**
85279a0bbe5SAnatoly Burakov   Not all kernel drivers and not all devices support all IOVA modes. EAL will
85379a0bbe5SAnatoly Burakov   attempt to pick a reasonable default based on a number of factors, but there
85479a0bbe5SAnatoly Burakov   may be cases where the default may be unsuitable (for example, hotplugging
85579a0bbe5SAnatoly Burakov   devices using `igb_uio` driver while having picked IOVA as VA mode on EAL
85679a0bbe5SAnatoly Burakov   initialization).
85779a0bbe5SAnatoly Burakov
85879a0bbe5SAnatoly Burakov**Implication**
85979a0bbe5SAnatoly Burakov   Some devices (hotplugged or otherwise) may not work due to incompatible IOVA
86079a0bbe5SAnatoly Burakov   mode being automatically picked by EAL.
86179a0bbe5SAnatoly Burakov
86279a0bbe5SAnatoly Burakov**Resolution/Workaround**:
86379a0bbe5SAnatoly Burakov   It is possible to force EAL to pick a particular IOVA mode by using the
86479a0bbe5SAnatoly Burakov   `--iova-mode` command-line parameter. If conflicting requirements are present
86579a0bbe5SAnatoly Burakov   (such as one device requiring IOVA as PA and one requiring IOVA as VA mode),
86679a0bbe5SAnatoly Burakov   there is no workaround.
86779a0bbe5SAnatoly Burakov
86879a0bbe5SAnatoly Burakov**Affected Environment/Platform**:
86979a0bbe5SAnatoly Burakov   Linux.
87079a0bbe5SAnatoly Burakov
87179a0bbe5SAnatoly Burakov**Driver/Module**:
87279a0bbe5SAnatoly Burakov   ALL.
873b37e9550SXuan Ding
8745d4a6a43SXuan DingVhost multi-queue reconnection failed with QEMU version 4.2.0 to 5.1.0
8755d4a6a43SXuan Ding----------------------------------------------------------------------
876b37e9550SXuan Ding
877b37e9550SXuan Ding**Description**
878b37e9550SXuan Ding   It's a QEMU regression bug (bad commit: c6beefd674ff). QEMU only saves
879b37e9550SXuan Ding   acked features for one vhost-net when vhost quits. When vhost reconnects
880b37e9550SXuan Ding   to virtio-net/virtio-pmd in multi-queue situations, the features been
8815d4a6a43SXuan Ding   set multiple times are not consistent. QEMU-5.2.0 fixes this issue in commit
8825d4a6a43SXuan Ding   f66337bdbfda ("vhost-user: save features of multiqueues if chardev is closed").
883b37e9550SXuan Ding
884b37e9550SXuan Ding**Implication**
885b37e9550SXuan Ding   Vhost cannot reconnect back to virtio-net/virtio-pmd normally.
886b37e9550SXuan Ding
887b37e9550SXuan Ding**Resolution/Workaround**:
888b37e9550SXuan Ding   It is possible to filter the incorrect acked features at vhost-user side.
889b37e9550SXuan Ding
890b37e9550SXuan Ding**Affected Environment/Platform**:
891b37e9550SXuan Ding   ALL.
892b37e9550SXuan Ding
893b37e9550SXuan Ding**Driver/Module**:
894b37e9550SXuan Ding   Virtual Device Poll Mode Driver (PMD).
895