6e5794d008
Add known issue about DPDK not compiling on some CPUs with clang versions older than 3.7.0. Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com> Acked-by: John McNamara <john.mcnamara@intel.com>
621 lines
21 KiB
ReStructuredText
621 lines
21 KiB
ReStructuredText
.. BSD LICENSE
|
|
Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
|
|
All rights reserved.
|
|
|
|
Redistribution and use in source and binary forms, with or without
|
|
modification, are permitted provided that the following conditions
|
|
are met:
|
|
|
|
* Redistributions of source code must retain the above copyright
|
|
notice, this list of conditions and the following disclaimer.
|
|
* Redistributions in binary form must reproduce the above copyright
|
|
notice, this list of conditions and the following disclaimer in
|
|
the documentation and/or other materials provided with the
|
|
distribution.
|
|
* Neither the name of Intel Corporation nor the names of its
|
|
contributors may be used to endorse or promote products derived
|
|
from this software without specific prior written permission.
|
|
|
|
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
|
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
|
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
|
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
|
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
|
|
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 the ``CONFIG_RTE_LIBEAL_USE_HPET=n``
|
|
configuration option 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/librte_eal/common/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 PMD drivers do not work when the ``--no-huge`` command line parameter is supplied to EAL.
|
|
|
|
**Implication**:
|
|
Sending and receiving data with PMD will not work.
|
|
|
|
**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).
|
|
|
|
|
|
Binding PCI devices to igb_uio fails on Linux kernel 3.9 when more than one device is used
|
|
------------------------------------------------------------------------------------------
|
|
|
|
**Description**:
|
|
A known bug in the uio driver included in Linux kernel version 3.9 prevents more than one PCI device to be
|
|
bound to the igb_uio driver.
|
|
|
|
**Implication**:
|
|
The Poll Mode Driver (PMD) will crash on initialization.
|
|
|
|
**Resolution/Workaround**:
|
|
Use earlier or later kernel versions, or apply the following
|
|
`patch <https://github.com/torvalds/linux/commit/5ed0505c713805f89473cdc0bbfb5110dfd840cb>`_.
|
|
|
|
**Affected Environment/Platform**:
|
|
Linux systems with kernel version 3.9
|
|
|
|
**Driver/Module**:
|
|
igb_uio module
|
|
|
|
|
|
GCC might generate Intel® AVX instructions for processors without Intel® AVX support
|
|
------------------------------------------------------------------------------------
|
|
|
|
**Description**:
|
|
When compiling DPDK (and any DPDK app), gcc may generate Intel® AVX instructions, even when the
|
|
processor does not support Intel® AVX.
|
|
|
|
**Implication**:
|
|
Any DPDK app might crash while starting up.
|
|
|
|
**Resolution/Workaround**:
|
|
Either compile using icc or set ``EXTRA_CFLAGS='-O3'`` prior to compilation.
|
|
|
|
**Affected Environment/Platform**:
|
|
Platforms which processor does not support Intel® AVX.
|
|
|
|
**Driver/Module**:
|
|
Environment Abstraction Layer (EAL).
|
|
|
|
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).
|
|
|
|
|
|
Stopping the port does not down the link on Intel® 40G Ethernet controller
|
|
--------------------------------------------------------------------------
|
|
|
|
**Description**:
|
|
On Intel® 40G Ethernet Controller stopping the port does not really down the port link.
|
|
|
|
**Implication**:
|
|
The port link will be still up after stopping the port.
|
|
|
|
**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).
|