maintainers: add Windows exports script

[dpdk.git] / doc / guides / rel_notes / deprecation.rst

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 287ffb2..e2721fa 100644 (file)
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -11,15 +11,21 @@ API and ABI deprecation notices are to be posted here.
 Deprecation Notices
 -------------------
 
 Deprecation Notices
 -------------------
 

-* linux: Linux kernel version 3.2 (which is the current minimum required
-  version for the DPDK) is not maintained anymore. Therefore the planned
-  minimum required kernel version for DPDK 19.02 will be the next oldest
-  Long Term Stable (LTS) version which is 3.16, but compatibility for
-  recent distribution kernels will be kept.
+* meson: The minimum supported version of meson for configuring and building
+  DPDK will be increased to v0.47.1 (from 0.41) from DPDK 19.05 onwards. For
+  those users with a version earlier than 0.47.1, an updated copy of meson
+  can be got using the ``pip``, or ``pip3``, tool for downloading python
+  packages.

 
 * kvargs: The function ``rte_kvargs_process`` will get a new parameter
   for returning key match count. It will ease handling of no-match case.
 
 
 * kvargs: The function ``rte_kvargs_process`` will get a new parameter
   for returning key match count. It will ease handling of no-match case.
 

+* eal: The function ``rte_eal_remote_launch`` will return new error codes
+  after read or write error on the pipe, instead of calling ``rte_panic``.
+
+* eal: the ``rte_mem_config`` struct will be made private to remove it from the
+  externally visible ABI and allow it to be updated in the future.
+

 * eal: both declaring and identifying devices will be streamlined in v18.11.
   New functions will appear to query a specific port from buses, classes of
   device and device drivers. Device declaration will be made coherent with the
 * eal: both declaring and identifying devices will be streamlined in v18.11.
   New functions will appear to query a specific port from buses, classes of
   device and device drivers. Device declaration will be made coherent with the


@@ -31,6 +37,10 @@ Deprecation Notices
 
     + ``rte_eal_devargs_type_count``
 
 
     + ``rte_eal_devargs_type_count``
 

+* vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
+  have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
+  functions.  The due date for the removal targets DPDK 20.02.
+

 * pci: Several exposed functions are misnamed.
   The following functions are deprecated starting from v17.11 and are replaced:
 
 * pci: Several exposed functions are misnamed.
   The following functions are deprecated starting from v17.11 and are replaced:
 


@@ -44,13 +54,6 @@ Deprecation Notices
   structure would be made internal (or removed if all dependencies are cleared)
   in future releases.
 
   structure would be made internal (or removed if all dependencies are cleared)
   in future releases.
 

-* mbuf: the macro ``RTE_MBUF_INDIRECT()`` will be removed in v18.08 or later and
-  replaced with ``RTE_MBUF_CLONED()`` which is already added in v18.05. As
-  ``EXT_ATTACHED_MBUF`` is newly introduced in v18.05, ``RTE_MBUF_INDIRECT()``
-  can no longer be mutually exclusive with ``RTE_MBUF_DIRECT()`` if the new
-  experimental API ``rte_pktmbuf_attach_extbuf()`` is used. Removal of the macro
-  is to fix this semantic inconsistency.
-

 * ethdev: the legacy filter API, including
   ``rte_eth_dev_filter_supported()``, ``rte_eth_dev_filter_ctrl()`` as well
   as filter types MACVLAN, ETHERTYPE, FLEXIBLE, SYN, NTUPLE, TUNNEL, FDIR,
 * ethdev: the legacy filter API, including
   ``rte_eth_dev_filter_supported()``, ``rte_eth_dev_filter_ctrl()`` as well
   as filter types MACVLAN, ETHERTYPE, FLEXIBLE, SYN, NTUPLE, TUNNEL, FDIR,


@@ -59,27 +62,40 @@ Deprecation Notices
   Target release for removal of the legacy API will be defined once most
   PMDs have switched to rte_flow.
 
   Target release for removal of the legacy API will be defined once most
   PMDs have switched to rte_flow.
 

-* ethdev: Maximum and minimum MTU values vary between hardware devices. In
-  hardware agnostic DPDK applications access to such information would allow
-  a more accurate way of validating and setting supported MTU values on a per
-  device basis rather than using a defined default for all devices. To
-  resolve this, the following members will be added to ``rte_eth_dev_info``.
-  Note: these can be added to fit a hole in the existing structure for amd64
-  but not for 32-bit, as such ABI change will occur as size of the structure
-  will increase.
+* cryptodev: New member in ``rte_cryptodev_config`` to allow applications to
+  disable features supported by the crypto device. Only the following features
+  would be allowed to be disabled this way,
+
+  - ``RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO``
+  - ``RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO``
+  - ``RTE_CRYPTODEV_FF_SECURITY``
+
+  Disabling unused features would facilitate efficient usage of HW/SW offload.
+
+  - Member ``uint64_t ff_disable`` in ``rte_cryptodev_config``
+
+  The field would be added in v19.08.

 
 

-  - Member ``uint16_t min_mtu`` the minimum MTU allowed.
-  - Member ``uint16_t max_mtu`` the maximum MTU allowed.
+* cryptodev: the ``uint8_t *data`` member of ``key`` structure in the xforms
+  structure (``rte_crypto_cipher_xform``, ``rte_crypto_auth_xform``, and
+  ``rte_crypto_aead_xform``) will be changed to ``const uint8_t *data``.

 
 

-* security: New field ``uint64_t opaque_data`` is planned to be added into
-  ``rte_security_session`` structure. That would allow upper layer to easily
-  associate/de-associate some user defined data with the security session.
+* cryptodev: support for using IV with all sizes is added, J0 still can
+  be used but only when IV length in following structs ``rte_crypto_auth_xform``,
+  ``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
+  to one it means it represents IV, when is set to zero it means J0 is used
+  directly, in this case 16 bytes of J0 need to be passed.

 
 

-* cryptodev: several API and ABI changes are planned for rte_cryptodev
-  in v19.02:
+* sched: To allow more traffic classes, flexible mapping of pipe queues to
+  traffic classes, and subport level configuration of pipes and queues
+  changes will be made to macros, data structures and API functions defined
+  in "rte_sched.h". These changes are aligned to improvements suggested in the
+  RFC https://mails.dpdk.org/archives/dev/2018-November/120035.html.

 
 

-  - The size and layout of ``rte_cryptodev_sym_session`` will change
-    to fix existing issues.
+* metrics: The function ``rte_metrics_init`` will have a non-void return
+  in order to notify errors instead of calling ``rte_exit``.

 
 

-* crypto/aesni_mb: the minimum supported intel-ipsec-mb library version will be
-  changed from 0.49.0 to 0.52.0.
+* power: ``rte_power_set_env`` function will no longer return 0 on attempt
+  to set new power environment if power environment was already initialized.
+  In this case the function will return -1 unless the environment is unset first
+  (using ``rte_power_unset_env``). Other function usage scenarios will not change.