numam-dpdk/doc/guides/rel_notes/release_18_05.rst

386 lines
13 KiB
ReStructuredText
Raw Normal View History

DPDK Release 18.05
==================
.. **Read this first.**
The text in the sections below explains how to update the release notes.
Use proper spelling, capitalization and punctuation in all sections.
Variable and config names should be quoted as fixed width text:
``LIKE_THIS``.
Build the docs and view the output file to ensure the changes are correct::
make doc-guides-html
xdg-open build/doc/html/guides/rel_notes/release_18_05.html
New Features
------------
.. This section should contain new features added in this release. Sample
format:
* **Add a title in the past tense with a full stop.**
Add a short 1-2 sentence description in the past tense. The description
should be enough to allow someone scanning the release notes to
understand the new feature.
If the feature adds a lot of sub-features you can use a bullet list like
this:
* Added feature foo to do something.
* Enhanced feature bar to do something else.
Refer to the previous release notes for examples.
This section is a comment. Do not overwrite or remove it.
Also, make sure to start the actual text at the margin.
=========================================================
* **Added PMD-recommended Tx and Rx parameters**
Applications can now query drivers for device-tuned values of
ring sizes, burst sizes, and number of queues.
* **Added RSS hash and key update to CXGBE PMD.**
Support to update RSS hash and key has been added to CXGBE PMD.
* **Added CXGBE VF PMD.**
CXGBE VF Poll Mode Driver has been added to run DPDK over Chelsio
T5/T6 NIC VF instances.
* **Updated Solarflare network PMD.**
Updated the sfc_efx driver including the following changes:
* Added support for Solarflare XtremeScale X2xxx family adapters.
* Added support for NVGRE, VXLAN and GENEVE filters in flow API.
* Added support for DROP action in flow API.
* **Added Ethernet poll mode driver for AMD XGBE devices.**
Added the new ``axgbe`` ethernet poll mode driver for AMD XGBE devices.
See the :doc:`../nics/axgbe` nic driver guide for more details on this
new driver.
* **Updated szedata2 PMD.**
Added support for new NFB-200G2QL card.
* **Added support for Broadcom NetXtreme-S (BCM58800) family of controllers (aka Stingray)**
The BCM58800 devices feature a NetXtreme E-Series advanced network controller, a high-performance
ARM CPU block, PCI Express (PCIe) Gen3 interfaces, key accelerators for compute offload and a high-
speed memory subsystem including L3 cache and DDR4 interfaces, all interconnected by a coherent
Network-on-chip (NOC) fabric.
The ARM CPU subsystem features eight ARMv8 Cortex-A72 CPUs at 3.0 GHz, arranged in a multi-cluster
configuration.
* **Added support for virtio-user server mode.**
In a container environment if the vhost-user backend restarts, there's no way
for it to reconnect to virtio-user. To address this, support for server mode
is added. In this mode the socket file is created by virtio-user, which the
backend connects to. This means that if the backend restarts, it can reconnect
to virtio-user and continue communications.
* **Added crypto workload support to vhost library.**
New APIs are introduced in vhost library to enable virtio crypto support
including session creation/deletion handling and translating virtio-crypto
request into DPDK crypto operations. A sample application is also introduced.
* **Added virtio crypto PMD.**
Added a new poll mode driver for virtio crypto devices, which provides
AES-CBC ciphering and AES-CBC with HMAC-SHA1 algorithm-chaining. See the
:doc:`../cryptodevs/virtio` crypto driver guide for more details on
this new driver.
* **Added AMD CCP Crypto PMD.**
Added the new ``ccp`` crypto driver for AMD CCP devices. See the
:doc:`../cryptodevs/ccp` crypto driver guide for more details on
this new driver.
* **Updated AESNI MB PMD.**
The AESNI MB PMD has been updated with additional support for:
* AES-CMAC (128-bit key).
* **Added the Event Timer Adapter Library.**
The Event Timer Adapter Library extends the event-based model by introducing
APIs that allow applications to arm/cancel event timers that generate
timer expiry events. This new type of event is scheduled by an event device
along with existing types of events.
* **Added device event monitor framework.**
Added a general device event monitor framework at EAL, for device dynamic management.
Such as device hotplug awareness and actions adopted accordingly. The list of new APIs:
* ``rte_dev_event_monitor_start`` and ``rte_dev_event_monitor_stop`` are for
the event monitor enable and disable.
* ``rte_dev_event_callback_register`` and ``rte_dev_event_callback_unregister``
are for the user's callbacks register and unregister.
Linux uevent is supported as backend of this device event notification framework.
API Changes
-----------
.. This section should contain API changes. Sample format:
* Add a short 1-2 sentence description of the API change. Use fixed width
quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past
tense.
This section is a comment. Do not overwrite or remove it.
Also, make sure to start the actual text at the margin.
=========================================================
* mempool: capability flags and related functions have been removed.
Flags ``MEMPOOL_F_CAPA_PHYS_CONTIG`` and
``MEMPOOL_F_CAPA_BLK_ALIGNED_OBJECTS`` were used by octeontx mempool
driver to customize generic mempool library behaviour.
Now the new driver callbacks ``calc_mem_size`` and ``populate`` may be
used to achieve it without specific knowledge in the generic code.
* mempool: xmem functions have been deprecated:
- ``rte_mempool_xmem_create``
- ``rte_mempool_xmem_size``
- ``rte_mempool_xmem_usage``
- ``rte_mempool_populate_iova_tab``
* mbuf: The control mbuf API has been removed in v18.05. The impacted
functions and macros are:
- ``rte_ctrlmbuf_init()``
- ``rte_ctrlmbuf_alloc()``
- ``rte_ctrlmbuf_free()``
- ``rte_ctrlmbuf_data()``
- ``rte_ctrlmbuf_len()``
- ``rte_is_ctrlmbuf()``
- ``CTRL_MBUF_FLAG``
The packet mbuf API should be used as a replacement.
* meter: updated to accommodate configuration profiles.
The meter API is changed to support meter configuration profiles. The
configuration profile represents the set of configuration parameters
for a given meter object, such as the rates and sizes for the token
buckets. These configuration parameters were previously the part of meter
object internal data strcuture. The separation of the configuration
parameters from meter object data structure results in reducing its
memory footprint which helps in better cache utilization when large number
of meter objects are used.
* ethdev: The function ``rte_eth_dev_count``, often mis-used to iterate
over ports, is deprecated and replaced by ``rte_eth_dev_count_avail``.
There is also a new function ``rte_eth_dev_count_total`` to get the
total number of allocated ports, available or not.
The hotplug-proof applications should use ``RTE_ETH_FOREACH_DEV`` or
``RTE_ETH_FOREACH_DEV_OWNED_BY`` as port iterators.
* ethdev, in struct ``struct rte_eth_dev_info``, field ``rte_pci_device *pci_dev``
replaced with field ``struct rte_device *device``.
* **Changes to semantics of rte_eth_dev_configure() parameters.**
If both the ``nb_rx_q`` and ``nb_tx_q`` parameters are zero,
``rte_eth_dev_configure`` will now use PMD-recommended queue sizes, or if
recommendations are not provided by the PMD the function will use ethdev
fall-back values. Previously setting both of the parameters to zero would
have resulted in ``-EINVAL`` being returned.
* **Changes to semantics of rte_eth_rx_queue_setup() parameters.**
If the ``nb_rx_desc`` parameter is zero, ``rte_eth_rx_queue_setup`` will
now use the PMD-recommended Rx ring size, or in the case where the PMD
does not provide a recommendation, will use an ethdev-provided
fall-back value. Previously, setting ``nb_rx_desc`` to zero would have
resulted in an error.
* **Changes to semantics of rte_eth_tx_queue_setup() parameters.**
If the ``nb_tx_desc`` parameter is zero, ``rte_eth_tx_queue_setup`` will
now use the PMD-recommended Tx ring size, or in the case where the PMD
does not provide a recoomendation, will use an ethdev-provided
fall-back value. Previously, setting ``nb_tx_desc`` to zero would have
resulted in an error.
ABI Changes
-----------
.. This section should contain ABI changes. Sample format:
* Add a short 1-2 sentence description of the ABI change that was announced
in the previous releases and made in this release. Use fixed width quotes
for ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
This section is a comment. Do not overwrite or remove it.
Also, make sure to start the actual text at the margin.
=========================================================
* ring: the alignment constraints on the ring structure has been relaxed
to one cache line instead of two, and an empty cache line padding is
added between the producer and consumer structures. The size of the
structure and the offset of the fields remains the same on platforms
with 64B cache line, but change on other platforms.
* mempool: ops have changed.
A new callback ``calc_mem_size`` has been added to ``rte_mempool_ops``
to allow to customize required memory size calculation.
A new callback ``populate`` has been added to ``rte_mempool_ops``
to allow to customize objects population.
Callback ``get_capabilities`` has been removed from ``rte_mempool_ops``
since its features are covered by ``calc_mem_size`` and ``populate``
callbacks.
* **Additional fields in rte_eth_dev_info.**
The ``rte_eth_dev_info`` structure has had two extra entries appended to the
end of it: ``default_rxportconf`` and ``default_txportconf``. Each of these
in turn are ``rte_eth_dev_portconf`` structures containing three fields of
type ``uint16_t``: ``burst_size``, ``ring_size``, and ``nb_queues``. These
are parameter values recommended for use by the PMD.
Removed Items
-------------
.. This section should contain removed items in this release. Sample format:
* Add a short 1-2 sentence description of the removed item in the past
tense.
This section is a comment. Do not overwrite or remove it.
Also, make sure to start the actual text at the margin.
=========================================================
Known Issues
------------
.. This section should contain new known issues in this release. Sample format:
* **Add title in present tense with full stop.**
Add a short 1-2 sentence description of the known issue in the present
tense. Add information on any known workarounds.
This section is a comment. Do not overwrite or remove it.
Also, make sure to start the actual text at the margin.
=========================================================
* **pdump is not compatible with old applications.**
As we changed to use generic multi-process communication for pdump negotiation
instead of previous dedicated unix socket way, pdump applications, including
dpdk-pdump example and any other applications using librte_pdump, cannot work
with older version DPDK primary applications.
Shared Library Versions
-----------------------
.. Update any library version updated in this release and prepend with a ``+``
sign, like this:
librte_acl.so.2
+ librte_cfgfile.so.2
librte_cmdline.so.2
This section is a comment. Do not overwrite or remove it.
=========================================================
The libraries prepended with a plus sign were incremented in this version.
.. code-block:: diff
librte_acl.so.2
librte_bbdev.so.1
librte_bitratestats.so.2
librte_bus_dpaa.so.1
librte_bus_fslmc.so.1
librte_bus_pci.so.1
librte_bus_vdev.so.1
librte_cfgfile.so.2
librte_cmdline.so.2
+ librte_common_octeontx.so.1
librte_cryptodev.so.4
librte_distributor.so.1
+ librte_eal.so.7
+ librte_ethdev.so.9
librte_eventdev.so.3
librte_flow_classify.so.1
librte_gro.so.1
librte_gso.so.1
librte_hash.so.2
librte_ip_frag.so.1
librte_jobstats.so.1
librte_kni.so.2
librte_kvargs.so.1
librte_latencystats.so.1
librte_lpm.so.2
+ librte_mbuf.so.4
+ librte_mempool.so.4
meter: add configuration profile This patch adds support for meter configuration profiles. Benefits: simplified configuration procedure, improved performance. Q1: What is the configuration profile and why does it make sense? A1: The configuration profile represents the set of configuration parameters for a given meter object, such as the rates and sizes for the token buckets. The configuration profile concept makes sense when many meter objects share the same configuration, which is the typical usage model: thousands of traffic flows are each individually metered according to just a few service levels (i.e. profiles). Q2: How is the configuration profile improving the performance? A2: The performance improvement is achieved by reducing the memory footprint of a meter object, which results in better cache utilization for the typical case when large arrays of meter objects are used. The internal data structures stored for each meter object contain: a) Constant fields: Low level translation of the configuration parameters that does not change post-configuration. This is really duplicated for all meters that use the same configuration. This is the configuration profile data that is moved away from the meter object. Current size (implementation dependent): srTCM = 32 bytes, trTCM = 32 bytes. b) Variable fields: Time stamps and running counters that change during the on-going traffic metering process. Current size (implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes. Therefore, by moving the constant fields to a separate profile data structure shared by all the meters with the same configuration, the size of the meter object is reduced by ~50%. Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
2018-01-08 15:43:56 +00:00
+ librte_meter.so.2
librte_metrics.so.1
librte_net.so.1
librte_pci.so.1
librte_pdump.so.2
librte_pipeline.so.3
librte_pmd_bnxt.so.2
librte_pmd_bond.so.2
librte_pmd_i40e.so.2
librte_pmd_ixgbe.so.2
librte_pmd_ring.so.2
librte_pmd_softnic.so.1
librte_pmd_vhost.so.2
librte_port.so.3
librte_power.so.1
librte_rawdev.so.1
librte_reorder.so.1
+ librte_ring.so.2
librte_sched.so.1
librte_security.so.1
librte_table.so.3
librte_timer.so.1
librte_vhost.so.3
Tested Platforms
----------------
.. This section should contain a list of platforms that were tested with this
release.
The format is:
* <vendor> platform with <vendor> <type of devices> combinations
* List of CPU
* List of OS
* List of devices
* Other relevant details...
This section is a comment. Do not overwrite or remove it.
Also, make sure to start the actual text at the margin.
=========================================================