[dpdk-dev] [RFC 1/2] doc: clean ABI/API policy guide

[dpdk-dev] [RFC 1/2] doc: clean ABI/API policy guide

[Ferruh Yigit]

The original document written from the point of ABI versioning but later
additions make document confusing, convert document into a ABI/API
policy documentation and organize the document in subsections:
- ABI/API Deprecation
- Experimental APIs
- Library versioning
- ABI versioning

Aim to clarify confusion between deprecation versioned ABI and overall
ABI/API deprecation, also ABI versioning and Library versioning by
organizing the sections.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
 doc/guides/contributing/versioning.rst | 132 +++++++++++++------------
 1 file changed, 71 insertions(+), 61 deletions(-)

diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 01b36247e..19af56cd2 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -1,33 +1,31 @@
 ..  SPDX-License-Identifier: BSD-3-Clause
     Copyright 2018 The DPDK contributors
 
-Managing ABI updates
-====================
+DPDK ABI/API policy
+===================
 
 Description
 -----------
 
 This document details some methods for handling ABI management in the DPDK.
-Note this document is not exhaustive, in that C library versioning is flexible
-allowing multiple methods to achieve various goals, but it will provide the user
-with some introductory methods
 
 General Guidelines
 ------------------
 
 #. Whenever possible, ABI should be preserved
-#. Libraries or APIs marked in ``experimental`` state may change without constraint.
+#. ABI/API may be changed with a deprecation process
+#. The modification of symbols can generally be managed with versioning
+#. Libraries or APIs marked in ``experimental`` state may change without constraint
 #. New APIs will be marked as ``experimental`` for at least one release to allow
    any issues found by users of the new API to be fixed quickly
 #. The addition of symbols is generally not problematic
-#. The modification of symbols can generally be managed with versioning
 #. The removal of symbols generally is an ABI break and requires bumping of the
    LIBABIVER macro
 #. Updates to the minimum hardware requirements, which drop support for hardware which
    was previously supported, should be treated as an ABI change.
 
 What is an ABI
---------------
+~~~~~~~~~~~~~~
 
 An ABI (Application Binary Interface) is the set of runtime interfaces exposed
 by a library. It is similar to an API (Application Programming Interface) but
@@ -39,9 +37,13 @@ Therefore, in the case of dynamic linking, it is critical that an ABI is
 preserved, or (when modified), done in such a way that the application is unable
 to behave improperly or in an unexpected fashion.
 
-The DPDK ABI policy
+
+ABI/API Deprecation
 -------------------
 
+The DPDK ABI policy
+~~~~~~~~~~~~~~~~~~~
+
 ABI versions are set at the time of major release labeling, and the ABI may
 change multiple times, without warning, between the last release label and the
 HEAD label of the git tree.
@@ -99,8 +101,36 @@ readability purposes should be avoided.
    follow the relevant deprecation policy procedures as above: 3 acks and
    announcement at least one release in advance.
 
+Examples of Deprecation Notices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following are some examples of ABI deprecation notices which would be
+added to the Release Notes:
+
+* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
+  to be replaced with the inline function ``rte_foo()``.
+
+* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
+  in version 2.0. Backwards compatibility will be maintained for this function
+  until the release of version 2.1
+
+* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
+  performance reasons. Existing binary applications will have backwards
+  compatibility in release 2.0, while newly built binaries will need to
+  reference the new structure variant ``struct rte_foo2``. Compatibility will
+  be removed in release 2.2, and all applications will require updating and
+  rebuilding to the new structure at that time, which will be renamed to the
+  original ``struct rte_foo``.
+
+* Significant ABI changes are planned for the ``librte_dostuff`` library. The
+  upcoming release 2.0 will not contain these changes, but release 2.1 will,
+  and no backwards compatibility is planned due to the extensive nature of
+  these changes. Binaries using this library built prior to version 2.1 will
+  require updating and recompilation.
+
+
 Experimental APIs
-~~~~~~~~~~~~~~~~~
+-----------------
 
 APIs marked as ``experimental`` are not considered part of the ABI and may
 change without warning at any time.  Since changes to APIs are most likely
@@ -130,35 +160,38 @@ is not required. Though, an API should remain in experimental state for at least
 one release. Thereafter, normal process of posting patch for review to mailing
 list can be followed.
 
-Examples of Deprecation Notices
--------------------------------
 
-The following are some examples of ABI deprecation notices which would be
-added to the Release Notes:
+Library versioning
+------------------
 
-* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
-  to be replaced with the inline function ``rte_foo()``.
+Downstreams might want to provide different DPDK releases at the same time to
+support multiple consumers of DPDK linked against older and newer sonames.
 
-* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
-  in version 2.0. Backwards compatibility will be maintained for this function
-  until the release of version 2.1
+Also due to the interdependencies that DPDK libraries can have applications
+might end up with an executable space in which multiple versions of a library
+are mapped by ld.so.
 
-* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
-  performance reasons. Existing binary applications will have backwards
-  compatibility in release 2.0, while newly built binaries will need to
-  reference the new structure variant ``struct rte_foo2``. Compatibility will
-  be removed in release 2.2, and all applications will require updating and
-  rebuilding to the new structure at that time, which will be renamed to the
-  original ``struct rte_foo``.
+Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
+depending on LibA.
 
-* Significant ABI changes are planned for the ``librte_dostuff`` library. The
-  upcoming release 2.0 will not contain these changes, but release 2.1 will,
-  and no backwards compatibility is planned due to the extensive nature of
-  these changes. Binaries using this library built prior to version 2.1 will
-  require updating and recompilation.
+.. note::
+
+    Application
+    \-> LibA.old
+    \-> LibB.new -> LibA.new
+
+That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
+If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
+library - versions defined in the libraries ``LIBABIVER``.
+An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
+``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
+
+
+ABI versioning
+--------------
 
 Versioning Macros
------------------
+~~~~~~~~~~~~~~~~~
 
 When a symbol is exported from a library to provide an API, it also provides a
 calling convention (ABI) that is embodied in its name, return type and
@@ -186,36 +219,11 @@ The macros exported are:
   fully qualified function ``p``, so that if a symbol becomes versioned, it
   can still be mapped back to the public symbol name.
 
-Setting a Major ABI version
----------------------------
-
-Downstreams might want to provide different DPDK releases at the same time to
-support multiple consumers of DPDK linked against older and newer sonames.
-
-Also due to the interdependencies that DPDK libraries can have applications
-might end up with an executable space in which multiple versions of a library
-are mapped by ld.so.
-
-Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
-depending on LibA.
-
-.. note::
-
-    Application
-    \-> LibA.old
-    \-> LibB.new -> LibA.new
-
-That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
-If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
-library - versions defined in the libraries ``LIBABIVER``.
-An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
-``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
-
 Examples of ABI Macro use
--------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Updating a public API
-~~~~~~~~~~~~~~~~~~~~~
+_____________________
 
 Assume we have a function as follows
 
@@ -425,7 +433,7 @@ and a new DPDK_2.1 version, used by future built applications.
 
 
 Deprecating part of a public API
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+________________________________
 
 Lets assume that you've done the above update, and after a few releases have
 passed you decide you would like to retire the old version of the function.
@@ -483,7 +491,7 @@ possibly incompatible library version:
    +LIBABIVER := 2
 
 Deprecating an entire ABI version
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+_________________________________
 
 While removing a symbol from and ABI may be useful, it is often more practical
 to remove an entire version node at once.  If a version node completely
@@ -532,6 +540,7 @@ Lastly, any VERSION_SYMBOL macros that point to the old version node should be
 removed, taking care to keep, where need old code in place to support newer
 versions of the symbol.
 
+
 Running the ABI Validator
 -------------------------
 
@@ -571,3 +580,4 @@ compile both tags) it will create compatibility reports in the
 follows::
 
   grep -lr Incompatible compat_reports/
+
-- 
2.17.2

[dpdk-dev] [RFC 2/2] doc: add deprecation marker usage

[Ferruh Yigit]

Define '__rte_deprecated' usage process.

Suggests keeping old API with '__rte_deprecated' marker until next LTS.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
 doc/guides/contributing/versioning.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 19af56cd2..e0edd2e20 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -128,6 +128,15 @@ added to the Release Notes:
   these changes. Binaries using this library built prior to version 2.1 will
   require updating and recompilation.
 
+New API replacing previous one
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If a new API proposed functionally replaces an existing one, when new API becomes
+active old one marked with ``__rte_deprecated`` until next LTS. In next LTS API
+removed completely.
+
+Reminder that new API should follow deprecation process to become active.
+
 
 Experimental APIs
 -----------------
-- 
2.17.2

Re: [dpdk-dev] [RFC 2/2] doc: add deprecation marker usage

[Luca Boccassi]

On Wed, 2018-12-19 at 12:52 +0000, Ferruh Yigit wrote:
> Define '__rte_deprecated' usage process.
> 
> Suggests keeping old API with '__rte_deprecated' marker until next
> LTS.
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> ---
> Cc: Luca Boccassi <bluca@debian.org>
> Cc: Kevin Traynor <ktraynor@redhat.com>
> Cc: Yongseok Koh <yskoh@mellanox.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> ---
>  doc/guides/contributing/versioning.rst | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/doc/guides/contributing/versioning.rst
> b/doc/guides/contributing/versioning.rst
> index 19af56cd2..e0edd2e20 100644
> --- a/doc/guides/contributing/versioning.rst
> +++ b/doc/guides/contributing/versioning.rst
> @@ -128,6 +128,15 @@ added to the Release Notes:
>    these changes. Binaries using this library built prior to version
> 2.1 will
>    require updating and recompilation.
>  
> +New API replacing previous one
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +If a new API proposed functionally replaces an existing one, when
> new API becomes
> +active old one marked with ``__rte_deprecated`` until next LTS. In
> next LTS API
> +removed completely.
> +

Perhaps a bit of rephrasing, ie:

"If a new API proposed functionally replaces an existing one, when the
new API becomes active then the old one is marked with
``__rte_deprecated`` until the next LTS. In the next LTS, the API is
removed completely."

Other than that:

Acked-by: Luca Boccassi <bluca@debian.org>

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-dev] [RFC 1/2] doc: clean ABI/API policy guide

[Luca Boccassi]

On Wed, 2018-12-19 at 12:52 +0000, Ferruh Yigit wrote:
> The original document written from the point of ABI versioning but
> later
> additions make document confusing, convert document into a ABI/API
> policy documentation and organize the document in subsections:
> - ABI/API Deprecation
> - Experimental APIs
> - Library versioning
> - ABI versioning
> 
> Aim to clarify confusion between deprecation versioned ABI and
> overall
> ABI/API deprecation, also ABI versioning and Library versioning by
> organizing the sections.
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> ---
> Cc: Luca Boccassi <bluca@debian.org>
> Cc: Kevin Traynor <ktraynor@redhat.com>
> Cc: Yongseok Koh <yskoh@mellanox.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>

Acked-by: Luca Boccassi <bluca@debian.org>

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-dev] [RFC 1/2] doc: clean ABI/API policy guide

[Luca Boccassi]

On Wed, 2018-12-19 at 12:52 +0000, Ferruh Yigit wrote:
> +    Application
> +    \-> LibA.old
> +    \-> LibB.new -> LibA.new
> +
> +That is a conflict which can be avoided by setting
> ``CONFIG_RTE_MAJOR_ABI``.
> +If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all -
> otherwise per
> +library - versions defined in the libraries ``LIBABIVER``.
> +An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make
> all libraries
> +``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.

This is not related to your reorganisation, but to solve this problem
properly should we start considering ABI bumps as "sticky", so that in
the example above _both_ libA and libB would get an ABI bump?

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-dev] [RFC 2/2] doc: add deprecation marker usage

[Ferruh Yigit]

On 12/20/2018 8:02 AM, Luca Boccassi wrote:
> On Wed, 2018-12-19 at 12:52 +0000, Ferruh Yigit wrote:
>> Define '__rte_deprecated' usage process.
>>
>> Suggests keeping old API with '__rte_deprecated' marker until next
>> LTS.
>>
>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>> ---
>> Cc: Luca Boccassi <bluca@debian.org>
>> Cc: Kevin Traynor <ktraynor@redhat.com>
>> Cc: Yongseok Koh <yskoh@mellanox.com>
>> Cc: Neil Horman <nhorman@tuxdriver.com>
>> ---
>>  doc/guides/contributing/versioning.rst | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/doc/guides/contributing/versioning.rst
>> b/doc/guides/contributing/versioning.rst
>> index 19af56cd2..e0edd2e20 100644
>> --- a/doc/guides/contributing/versioning.rst
>> +++ b/doc/guides/contributing/versioning.rst
>> @@ -128,6 +128,15 @@ added to the Release Notes:
>>    these changes. Binaries using this library built prior to version
>> 2.1 will
>>    require updating and recompilation.
>>  
>> +New API replacing previous one
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +If a new API proposed functionally replaces an existing one, when
>> new API becomes
>> +active old one marked with ``__rte_deprecated`` until next LTS. In
>> next LTS API
>> +removed completely.
>> +
> 
> Perhaps a bit of rephrasing, ie:
> 
> "If a new API proposed functionally replaces an existing one, when the
> new API becomes active then the old one is marked with
> ``__rte_deprecated`` until the next LTS. In the next LTS, the API is
> removed completely."

Thanks for suggestion, I will send a new version with this update.

> 
> Other than that:
> 
> Acked-by: Luca Boccassi <bluca@debian.org>
> 

[dpdk-dev] [PATCH v2 1/2] doc: clean ABI/API policy guide

[Ferruh Yigit]

The original document written from the point of ABI versioning but later
additions make document confusing, convert document into a ABI/API
policy documentation and organize the document in subsections:
- ABI/API Deprecation
- Experimental APIs
- Library versioning
- ABI versioning

Aim to clarify confusion between deprecation versioned ABI and overall
ABI/API deprecation, also ABI versioning and Library versioning by
organizing the sections.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
 doc/guides/contributing/versioning.rst | 132 +++++++++++++------------
 1 file changed, 71 insertions(+), 61 deletions(-)

diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 01b36247e..19af56cd2 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -1,33 +1,31 @@
 ..  SPDX-License-Identifier: BSD-3-Clause
     Copyright 2018 The DPDK contributors
 
-Managing ABI updates
-====================
+DPDK ABI/API policy
+===================
 
 Description
 -----------
 
 This document details some methods for handling ABI management in the DPDK.
-Note this document is not exhaustive, in that C library versioning is flexible
-allowing multiple methods to achieve various goals, but it will provide the user
-with some introductory methods
 
 General Guidelines
 ------------------
 
 #. Whenever possible, ABI should be preserved
-#. Libraries or APIs marked in ``experimental`` state may change without constraint.
+#. ABI/API may be changed with a deprecation process
+#. The modification of symbols can generally be managed with versioning
+#. Libraries or APIs marked in ``experimental`` state may change without constraint
 #. New APIs will be marked as ``experimental`` for at least one release to allow
    any issues found by users of the new API to be fixed quickly
 #. The addition of symbols is generally not problematic
-#. The modification of symbols can generally be managed with versioning
 #. The removal of symbols generally is an ABI break and requires bumping of the
    LIBABIVER macro
 #. Updates to the minimum hardware requirements, which drop support for hardware which
    was previously supported, should be treated as an ABI change.
 
 What is an ABI
---------------
+~~~~~~~~~~~~~~
 
 An ABI (Application Binary Interface) is the set of runtime interfaces exposed
 by a library. It is similar to an API (Application Programming Interface) but
@@ -39,9 +37,13 @@ Therefore, in the case of dynamic linking, it is critical that an ABI is
 preserved, or (when modified), done in such a way that the application is unable
 to behave improperly or in an unexpected fashion.
 
-The DPDK ABI policy
+
+ABI/API Deprecation
 -------------------
 
+The DPDK ABI policy
+~~~~~~~~~~~~~~~~~~~
+
 ABI versions are set at the time of major release labeling, and the ABI may
 change multiple times, without warning, between the last release label and the
 HEAD label of the git tree.
@@ -99,8 +101,36 @@ readability purposes should be avoided.
    follow the relevant deprecation policy procedures as above: 3 acks and
    announcement at least one release in advance.
 
+Examples of Deprecation Notices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following are some examples of ABI deprecation notices which would be
+added to the Release Notes:
+
+* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
+  to be replaced with the inline function ``rte_foo()``.
+
+* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
+  in version 2.0. Backwards compatibility will be maintained for this function
+  until the release of version 2.1
+
+* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
+  performance reasons. Existing binary applications will have backwards
+  compatibility in release 2.0, while newly built binaries will need to
+  reference the new structure variant ``struct rte_foo2``. Compatibility will
+  be removed in release 2.2, and all applications will require updating and
+  rebuilding to the new structure at that time, which will be renamed to the
+  original ``struct rte_foo``.
+
+* Significant ABI changes are planned for the ``librte_dostuff`` library. The
+  upcoming release 2.0 will not contain these changes, but release 2.1 will,
+  and no backwards compatibility is planned due to the extensive nature of
+  these changes. Binaries using this library built prior to version 2.1 will
+  require updating and recompilation.
+
+
 Experimental APIs
-~~~~~~~~~~~~~~~~~
+-----------------
 
 APIs marked as ``experimental`` are not considered part of the ABI and may
 change without warning at any time.  Since changes to APIs are most likely
@@ -130,35 +160,38 @@ is not required. Though, an API should remain in experimental state for at least
 one release. Thereafter, normal process of posting patch for review to mailing
 list can be followed.
 
-Examples of Deprecation Notices
--------------------------------
 
-The following are some examples of ABI deprecation notices which would be
-added to the Release Notes:
+Library versioning
+------------------
 
-* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
-  to be replaced with the inline function ``rte_foo()``.
+Downstreams might want to provide different DPDK releases at the same time to
+support multiple consumers of DPDK linked against older and newer sonames.
 
-* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
-  in version 2.0. Backwards compatibility will be maintained for this function
-  until the release of version 2.1
+Also due to the interdependencies that DPDK libraries can have applications
+might end up with an executable space in which multiple versions of a library
+are mapped by ld.so.
 
-* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
-  performance reasons. Existing binary applications will have backwards
-  compatibility in release 2.0, while newly built binaries will need to
-  reference the new structure variant ``struct rte_foo2``. Compatibility will
-  be removed in release 2.2, and all applications will require updating and
-  rebuilding to the new structure at that time, which will be renamed to the
-  original ``struct rte_foo``.
+Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
+depending on LibA.
 
-* Significant ABI changes are planned for the ``librte_dostuff`` library. The
-  upcoming release 2.0 will not contain these changes, but release 2.1 will,
-  and no backwards compatibility is planned due to the extensive nature of
-  these changes. Binaries using this library built prior to version 2.1 will
-  require updating and recompilation.
+.. note::
+
+    Application
+    \-> LibA.old
+    \-> LibB.new -> LibA.new
+
+That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
+If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
+library - versions defined in the libraries ``LIBABIVER``.
+An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
+``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
+
+
+ABI versioning
+--------------
 
 Versioning Macros
------------------
+~~~~~~~~~~~~~~~~~
 
 When a symbol is exported from a library to provide an API, it also provides a
 calling convention (ABI) that is embodied in its name, return type and
@@ -186,36 +219,11 @@ The macros exported are:
   fully qualified function ``p``, so that if a symbol becomes versioned, it
   can still be mapped back to the public symbol name.
 
-Setting a Major ABI version
----------------------------
-
-Downstreams might want to provide different DPDK releases at the same time to
-support multiple consumers of DPDK linked against older and newer sonames.
-
-Also due to the interdependencies that DPDK libraries can have applications
-might end up with an executable space in which multiple versions of a library
-are mapped by ld.so.
-
-Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
-depending on LibA.
-
-.. note::
-
-    Application
-    \-> LibA.old
-    \-> LibB.new -> LibA.new
-
-That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
-If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
-library - versions defined in the libraries ``LIBABIVER``.
-An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
-``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
-
 Examples of ABI Macro use
--------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Updating a public API
-~~~~~~~~~~~~~~~~~~~~~
+_____________________
 
 Assume we have a function as follows
 
@@ -425,7 +433,7 @@ and a new DPDK_2.1 version, used by future built applications.
 
 
 Deprecating part of a public API
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+________________________________
 
 Lets assume that you've done the above update, and after a few releases have
 passed you decide you would like to retire the old version of the function.
@@ -483,7 +491,7 @@ possibly incompatible library version:
    +LIBABIVER := 2
 
 Deprecating an entire ABI version
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+_________________________________
 
 While removing a symbol from and ABI may be useful, it is often more practical
 to remove an entire version node at once.  If a version node completely
@@ -532,6 +540,7 @@ Lastly, any VERSION_SYMBOL macros that point to the old version node should be
 removed, taking care to keep, where need old code in place to support newer
 versions of the symbol.
 
+
 Running the ABI Validator
 -------------------------
 
@@ -571,3 +580,4 @@ compile both tags) it will create compatibility reports in the
 follows::
 
   grep -lr Incompatible compat_reports/
+
-- 
2.17.2

[dpdk-dev] [PATCH v2 2/2] doc: add deprecation marker usage

[Ferruh Yigit]

Define '__rte_deprecated' usage process.

Suggests keeping old API with '__rte_deprecated' marker until next LTS.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>

v2:
* Rephrased as commented
---
 doc/guides/contributing/versioning.rst | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 19af56cd2..360238985 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -128,6 +128,16 @@ added to the Release Notes:
   these changes. Binaries using this library built prior to version 2.1 will
   require updating and recompilation.
 
+New API replacing previous one
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If a new API proposed functionally replaces an existing one, when the
+new API becomes active then the old one is marked with
+``__rte_deprecated`` until the next LTS. In the next LTS, the API is
+removed completely.
+
+Reminder that new API should follow deprecation process to become active.
+
 
 Experimental APIs
 -----------------
-- 
2.17.2

[dpdk-dev] [PATCH v3 1/3] doc: clean ABI/API policy guide

[Ferruh Yigit]

The original document written from the point of ABI versioning but later
additions make document confusing, convert document into a ABI/API
policy documentation and organize the document in subsections:
- ABI/API Deprecation
- Experimental APIs
- Library versioning
- ABI versioning

Aim to clarify confusion between deprecation versioned ABI and overall
ABI/API deprecation, also ABI versioning and Library versioning by
organizing the sections.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
 doc/guides/contributing/versioning.rst | 132 +++++++++++++------------
 1 file changed, 71 insertions(+), 61 deletions(-)

diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 01b36247e..19af56cd2 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -1,33 +1,31 @@
 ..  SPDX-License-Identifier: BSD-3-Clause
     Copyright 2018 The DPDK contributors
 
-Managing ABI updates
-====================
+DPDK ABI/API policy
+===================
 
 Description
 -----------
 
 This document details some methods for handling ABI management in the DPDK.
-Note this document is not exhaustive, in that C library versioning is flexible
-allowing multiple methods to achieve various goals, but it will provide the user
-with some introductory methods
 
 General Guidelines
 ------------------
 
 #. Whenever possible, ABI should be preserved
-#. Libraries or APIs marked in ``experimental`` state may change without constraint.
+#. ABI/API may be changed with a deprecation process
+#. The modification of symbols can generally be managed with versioning
+#. Libraries or APIs marked in ``experimental`` state may change without constraint
 #. New APIs will be marked as ``experimental`` for at least one release to allow
    any issues found by users of the new API to be fixed quickly
 #. The addition of symbols is generally not problematic
-#. The modification of symbols can generally be managed with versioning
 #. The removal of symbols generally is an ABI break and requires bumping of the
    LIBABIVER macro
 #. Updates to the minimum hardware requirements, which drop support for hardware which
    was previously supported, should be treated as an ABI change.
 
 What is an ABI
---------------
+~~~~~~~~~~~~~~
 
 An ABI (Application Binary Interface) is the set of runtime interfaces exposed
 by a library. It is similar to an API (Application Programming Interface) but
@@ -39,9 +37,13 @@ Therefore, in the case of dynamic linking, it is critical that an ABI is
 preserved, or (when modified), done in such a way that the application is unable
 to behave improperly or in an unexpected fashion.
 
-The DPDK ABI policy
+
+ABI/API Deprecation
 -------------------
 
+The DPDK ABI policy
+~~~~~~~~~~~~~~~~~~~
+
 ABI versions are set at the time of major release labeling, and the ABI may
 change multiple times, without warning, between the last release label and the
 HEAD label of the git tree.
@@ -99,8 +101,36 @@ readability purposes should be avoided.
    follow the relevant deprecation policy procedures as above: 3 acks and
    announcement at least one release in advance.
 
+Examples of Deprecation Notices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following are some examples of ABI deprecation notices which would be
+added to the Release Notes:
+
+* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
+  to be replaced with the inline function ``rte_foo()``.
+
+* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
+  in version 2.0. Backwards compatibility will be maintained for this function
+  until the release of version 2.1
+
+* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
+  performance reasons. Existing binary applications will have backwards
+  compatibility in release 2.0, while newly built binaries will need to
+  reference the new structure variant ``struct rte_foo2``. Compatibility will
+  be removed in release 2.2, and all applications will require updating and
+  rebuilding to the new structure at that time, which will be renamed to the
+  original ``struct rte_foo``.
+
+* Significant ABI changes are planned for the ``librte_dostuff`` library. The
+  upcoming release 2.0 will not contain these changes, but release 2.1 will,
+  and no backwards compatibility is planned due to the extensive nature of
+  these changes. Binaries using this library built prior to version 2.1 will
+  require updating and recompilation.
+
+
 Experimental APIs
-~~~~~~~~~~~~~~~~~
+-----------------
 
 APIs marked as ``experimental`` are not considered part of the ABI and may
 change without warning at any time.  Since changes to APIs are most likely
@@ -130,35 +160,38 @@ is not required. Though, an API should remain in experimental state for at least
 one release. Thereafter, normal process of posting patch for review to mailing
 list can be followed.
 
-Examples of Deprecation Notices
--------------------------------
 
-The following are some examples of ABI deprecation notices which would be
-added to the Release Notes:
+Library versioning
+------------------
 
-* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
-  to be replaced with the inline function ``rte_foo()``.
+Downstreams might want to provide different DPDK releases at the same time to
+support multiple consumers of DPDK linked against older and newer sonames.
 
-* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
-  in version 2.0. Backwards compatibility will be maintained for this function
-  until the release of version 2.1
+Also due to the interdependencies that DPDK libraries can have applications
+might end up with an executable space in which multiple versions of a library
+are mapped by ld.so.
 
-* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
-  performance reasons. Existing binary applications will have backwards
-  compatibility in release 2.0, while newly built binaries will need to
-  reference the new structure variant ``struct rte_foo2``. Compatibility will
-  be removed in release 2.2, and all applications will require updating and
-  rebuilding to the new structure at that time, which will be renamed to the
-  original ``struct rte_foo``.
+Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
+depending on LibA.
 
-* Significant ABI changes are planned for the ``librte_dostuff`` library. The
-  upcoming release 2.0 will not contain these changes, but release 2.1 will,
-  and no backwards compatibility is planned due to the extensive nature of
-  these changes. Binaries using this library built prior to version 2.1 will
-  require updating and recompilation.
+.. note::
+
+    Application
+    \-> LibA.old
+    \-> LibB.new -> LibA.new
+
+That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
+If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
+library - versions defined in the libraries ``LIBABIVER``.
+An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
+``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
+
+
+ABI versioning
+--------------
 
 Versioning Macros
------------------
+~~~~~~~~~~~~~~~~~
 
 When a symbol is exported from a library to provide an API, it also provides a
 calling convention (ABI) that is embodied in its name, return type and
@@ -186,36 +219,11 @@ The macros exported are:
   fully qualified function ``p``, so that if a symbol becomes versioned, it
   can still be mapped back to the public symbol name.
 
-Setting a Major ABI version
----------------------------
-
-Downstreams might want to provide different DPDK releases at the same time to
-support multiple consumers of DPDK linked against older and newer sonames.
-
-Also due to the interdependencies that DPDK libraries can have applications
-might end up with an executable space in which multiple versions of a library
-are mapped by ld.so.
-
-Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
-depending on LibA.
-
-.. note::
-
-    Application
-    \-> LibA.old
-    \-> LibB.new -> LibA.new
-
-That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
-If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
-library - versions defined in the libraries ``LIBABIVER``.
-An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
-``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
-
 Examples of ABI Macro use
--------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Updating a public API
-~~~~~~~~~~~~~~~~~~~~~
+_____________________
 
 Assume we have a function as follows
 
@@ -425,7 +433,7 @@ and a new DPDK_2.1 version, used by future built applications.
 
 
 Deprecating part of a public API
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+________________________________
 
 Lets assume that you've done the above update, and after a few releases have
 passed you decide you would like to retire the old version of the function.
@@ -483,7 +491,7 @@ possibly incompatible library version:
    +LIBABIVER := 2
 
 Deprecating an entire ABI version
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+_________________________________
 
 While removing a symbol from and ABI may be useful, it is often more practical
 to remove an entire version node at once.  If a version node completely
@@ -532,6 +540,7 @@ Lastly, any VERSION_SYMBOL macros that point to the old version node should be
 removed, taking care to keep, where need old code in place to support newer
 versions of the symbol.
 
+
 Running the ABI Validator
 -------------------------
 
@@ -571,3 +580,4 @@ compile both tags) it will create compatibility reports in the
 follows::
 
   grep -lr Incompatible compat_reports/
+
-- 
2.17.2

[dpdk-dev] [PATCH v3 2/3] doc: make RTE_NEXT_ABI optional

[Ferruh Yigit]

Initial process requires oncoming changes described in deprecation
notice should be implemented in a RTE_NEXT_ABI gated way.

This has been discussed in technical board, and since this can cause a
multiple #ifdef blocks in multiple locations of the code, can be
confusing specially for the modifications that requires data structure
changes. Anyway this was not happening in practice.

Making RTE_NEXT_ABI usage more optional based on techboard decision:
http://mails.dpdk.org/archives/dev/2019-January/123519.html

The intention with using RTE_NEXT_ABI was to provide more information
to the user about planned changes, and force developer to think more in
coding level. Since RTE_NEXT_ABI become optional, now the preferred way
to do this is, if possible, sending changes, described in deprecation
notice, as a separate patch and reference it in deprecation notice.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
 doc/guides/contributing/versioning.rst | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 19af56cd2..bfc27fbe0 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -73,19 +73,16 @@ being provided. The requirements for doing so are:
      interest" be sought for each deprecation, for example: from NIC vendors,
      CPU vendors, end-users, etc.
 
-#. The changes (including an alternative map file) must be gated with
-   the ``RTE_NEXT_ABI`` option, and provided with a deprecation notice at the
-   same time.
-   It will become the default ABI in the next release.
+#. The changes (including an alternative map file) can be included with
+   deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option,
+   to provide more details about oncoming changes.
+   ``RTE_NEXT_ABI`` wrapper will be removed when it become the default ABI.
+   More preferred way to provide this information is sending the feature
+   as a separate patch and reference it in deprecation notice.
 
 #. A full deprecation cycle, as explained above, must be made to offer
    downstream consumers sufficient warning of the change.
 
-#. At the beginning of the next release cycle, every ``RTE_NEXT_ABI``
-   conditions will be removed, the ``LIBABIVER`` variable in the makefile(s)
-   where the ABI is changed will be incremented, and the map files will
-   be updated.
-
 Note that the above process for ABI deprecation should not be undertaken
 lightly. ABI stability is extremely important for downstream consumers of the
 DPDK, especially when distributed in shared object form. Every effort should
-- 
2.17.2

[dpdk-dev] [PATCH v3 3/3] doc: add deprecation marker usage

[Ferruh Yigit]

Define '__rte_deprecated' usage process.

Suggests keeping old API with '__rte_deprecated' marker including
next LTS, they will be removed just after the LTS release.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>

v2:
* Rephrased as commented

v3:
* changed when to remove the deprecated API. It is now just after
an LTS release, the motivation is to keep changes small in LTS.
Based on techboard discussion:
http://mails.dpdk.org/archives/dev/2019-January/123519.html
---
 doc/guides/contributing/versioning.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index bfc27fbe0..977d06c60 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -125,6 +125,15 @@ added to the Release Notes:
   these changes. Binaries using this library built prior to version 2.1 will
   require updating and recompilation.
 
+New API replacing previous one
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If a new API proposed functionally replaces an existing one, when the
+new API becomes active then the old one is marked with ``__rte_deprecated``.
+Deprecated APIs removed completely just after the next LTS.
+
+Reminder that new API should follow deprecation process to become active.
+
 
 Experimental APIs
 -----------------
-- 
2.17.2

Re: [dpdk-dev] [PATCH v3 1/3] doc: clean ABI/API policy guide

[Neil Horman]

On Tue, Jan 22, 2019 at 04:23:08PM +0000, Ferruh Yigit wrote:
> The original document written from the point of ABI versioning but later
> additions make document confusing, convert document into a ABI/API
> policy documentation and organize the document in subsections:
> - ABI/API Deprecation
> - Experimental APIs
> - Library versioning
> - ABI versioning
> 
> Aim to clarify confusion between deprecation versioned ABI and overall
> ABI/API deprecation, also ABI versioning and Library versioning by
> organizing the sections.
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> ---
> Cc: Luca Boccassi <bluca@debian.org>
> Cc: Kevin Traynor <ktraynor@redhat.com>
> Cc: Yongseok Koh <yskoh@mellanox.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> ---
>  doc/guides/contributing/versioning.rst | 132 +++++++++++++------------
>  1 file changed, 71 insertions(+), 61 deletions(-)
> 
> diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
> index 01b36247e..19af56cd2 100644
> --- a/doc/guides/contributing/versioning.rst
> +++ b/doc/guides/contributing/versioning.rst
> @@ -1,33 +1,31 @@
>  ..  SPDX-License-Identifier: BSD-3-Clause
>      Copyright 2018 The DPDK contributors
>  
> -Managing ABI updates
> -====================
> +DPDK ABI/API policy
> +===================
>  
>  Description
>  -----------
>  
>  This document details some methods for handling ABI management in the DPDK.
> -Note this document is not exhaustive, in that C library versioning is flexible
> -allowing multiple methods to achieve various goals, but it will provide the user
> -with some introductory methods
>  
>  General Guidelines
>  ------------------
>  
>  #. Whenever possible, ABI should be preserved
> -#. Libraries or APIs marked in ``experimental`` state may change without constraint.
> +#. ABI/API may be changed with a deprecation process
> +#. The modification of symbols can generally be managed with versioning
> +#. Libraries or APIs marked in ``experimental`` state may change without constraint
>  #. New APIs will be marked as ``experimental`` for at least one release to allow
>     any issues found by users of the new API to be fixed quickly
>  #. The addition of symbols is generally not problematic
> -#. The modification of symbols can generally be managed with versioning
>  #. The removal of symbols generally is an ABI break and requires bumping of the
>     LIBABIVER macro
>  #. Updates to the minimum hardware requirements, which drop support for hardware which
>     was previously supported, should be treated as an ABI change.
>  
>  What is an ABI
> ---------------
> +~~~~~~~~~~~~~~
>  
>  An ABI (Application Binary Interface) is the set of runtime interfaces exposed
>  by a library. It is similar to an API (Application Programming Interface) but
> @@ -39,9 +37,13 @@ Therefore, in the case of dynamic linking, it is critical that an ABI is
>  preserved, or (when modified), done in such a way that the application is unable
>  to behave improperly or in an unexpected fashion.
>  
> -The DPDK ABI policy
> +
> +ABI/API Deprecation
>  -------------------
>  
> +The DPDK ABI policy
> +~~~~~~~~~~~~~~~~~~~
> +
>  ABI versions are set at the time of major release labeling, and the ABI may
>  change multiple times, without warning, between the last release label and the
>  HEAD label of the git tree.
> @@ -99,8 +101,36 @@ readability purposes should be avoided.
>     follow the relevant deprecation policy procedures as above: 3 acks and
>     announcement at least one release in advance.
>  
> +Examples of Deprecation Notices
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +The following are some examples of ABI deprecation notices which would be
> +added to the Release Notes:
> +
> +* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
> +  to be replaced with the inline function ``rte_foo()``.
> +
> +* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
> +  in version 2.0. Backwards compatibility will be maintained for this function
> +  until the release of version 2.1
> +
> +* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
> +  performance reasons. Existing binary applications will have backwards
> +  compatibility in release 2.0, while newly built binaries will need to
> +  reference the new structure variant ``struct rte_foo2``. Compatibility will
> +  be removed in release 2.2, and all applications will require updating and
> +  rebuilding to the new structure at that time, which will be renamed to the
> +  original ``struct rte_foo``.
> +
> +* Significant ABI changes are planned for the ``librte_dostuff`` library. The
> +  upcoming release 2.0 will not contain these changes, but release 2.1 will,
> +  and no backwards compatibility is planned due to the extensive nature of
> +  these changes. Binaries using this library built prior to version 2.1 will
> +  require updating and recompilation.
> +
> +
>  Experimental APIs
> -~~~~~~~~~~~~~~~~~
> +-----------------
>  
>  APIs marked as ``experimental`` are not considered part of the ABI and may
>  change without warning at any time.  Since changes to APIs are most likely
> @@ -130,35 +160,38 @@ is not required. Though, an API should remain in experimental state for at least
>  one release. Thereafter, normal process of posting patch for review to mailing
>  list can be followed.
>  
> -Examples of Deprecation Notices
> --------------------------------
>  
> -The following are some examples of ABI deprecation notices which would be
> -added to the Release Notes:
> +Library versioning
> +------------------
>  
> -* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
> -  to be replaced with the inline function ``rte_foo()``.
> +Downstreams might want to provide different DPDK releases at the same time to
> +support multiple consumers of DPDK linked against older and newer sonames.
>  
> -* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
> -  in version 2.0. Backwards compatibility will be maintained for this function
> -  until the release of version 2.1
> +Also due to the interdependencies that DPDK libraries can have applications
> +might end up with an executable space in which multiple versions of a library
> +are mapped by ld.so.
>  
> -* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
> -  performance reasons. Existing binary applications will have backwards
> -  compatibility in release 2.0, while newly built binaries will need to
> -  reference the new structure variant ``struct rte_foo2``. Compatibility will
> -  be removed in release 2.2, and all applications will require updating and
> -  rebuilding to the new structure at that time, which will be renamed to the
> -  original ``struct rte_foo``.
> +Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
> +depending on LibA.
>  
> -* Significant ABI changes are planned for the ``librte_dostuff`` library. The
> -  upcoming release 2.0 will not contain these changes, but release 2.1 will,
> -  and no backwards compatibility is planned due to the extensive nature of
> -  these changes. Binaries using this library built prior to version 2.1 will
> -  require updating and recompilation.
> +.. note::
> +
> +    Application
> +    \-> LibA.old
> +    \-> LibB.new -> LibA.new
> +
> +That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
> +If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
> +library - versions defined in the libraries ``LIBABIVER``.
> +An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
> +``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
> +
> +
> +ABI versioning
> +--------------
>  
>  Versioning Macros
> ------------------
> +~~~~~~~~~~~~~~~~~
>  
>  When a symbol is exported from a library to provide an API, it also provides a
>  calling convention (ABI) that is embodied in its name, return type and
> @@ -186,36 +219,11 @@ The macros exported are:
>    fully qualified function ``p``, so that if a symbol becomes versioned, it
>    can still be mapped back to the public symbol name.
>  
> -Setting a Major ABI version
> ----------------------------
> -
> -Downstreams might want to provide different DPDK releases at the same time to
> -support multiple consumers of DPDK linked against older and newer sonames.
> -
> -Also due to the interdependencies that DPDK libraries can have applications
> -might end up with an executable space in which multiple versions of a library
> -are mapped by ld.so.
> -
> -Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
> -depending on LibA.
> -
> -.. note::
> -
> -    Application
> -    \-> LibA.old
> -    \-> LibB.new -> LibA.new
> -
> -That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
> -If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
> -library - versions defined in the libraries ``LIBABIVER``.
> -An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
> -``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
> -
>  Examples of ABI Macro use
> --------------------------
> +^^^^^^^^^^^^^^^^^^^^^^^^^
>  
>  Updating a public API
> -~~~~~~~~~~~~~~~~~~~~~
> +_____________________
>  
>  Assume we have a function as follows
>  
> @@ -425,7 +433,7 @@ and a new DPDK_2.1 version, used by future built applications.
>  
>  
>  Deprecating part of a public API
> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +________________________________
>  
>  Lets assume that you've done the above update, and after a few releases have
>  passed you decide you would like to retire the old version of the function.
> @@ -483,7 +491,7 @@ possibly incompatible library version:
>     +LIBABIVER := 2
>  
>  Deprecating an entire ABI version
> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +_________________________________
>  
>  While removing a symbol from and ABI may be useful, it is often more practical
>  to remove an entire version node at once.  If a version node completely
> @@ -532,6 +540,7 @@ Lastly, any VERSION_SYMBOL macros that point to the old version node should be
>  removed, taking care to keep, where need old code in place to support newer
>  versions of the symbol.
>  
> +
>  Running the ABI Validator
>  -------------------------
>  
> @@ -571,3 +580,4 @@ compile both tags) it will create compatibility reports in the
>  follows::
>  
>    grep -lr Incompatible compat_reports/
> +
> -- 
> 2.17.2
> 
> 
Series
Acked-by: Neil Horman <nhorman@tuxdriver.com>

Re: [dpdk-dev] [PATCH v3 3/3] doc: add deprecation marker usage

[Kevin Traynor]

On 01/22/2019 05:23 PM, Ferruh Yigit wrote:
> Define '__rte_deprecated' usage process.
> 
> Suggests keeping old API with '__rte_deprecated' marker including
> next LTS, they will be removed just after the LTS release.
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> Acked-by: Luca Boccassi <bluca@debian.org>
> ---
> Cc: Luca Boccassi <bluca@debian.org>
> Cc: Kevin Traynor <ktraynor@redhat.com>
> Cc: Yongseok Koh <yskoh@mellanox.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> 
> v2:
> * Rephrased as commented
> 
> v3:
> * changed when to remove the deprecated API. It is now just after
> an LTS release, the motivation is to keep changes small in LTS.
> Based on techboard discussion:
> http://mails.dpdk.org/archives/dev/2019-January/123519.html
> ---
>  doc/guides/contributing/versioning.rst | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
> index bfc27fbe0..977d06c60 100644
> --- a/doc/guides/contributing/versioning.rst
> +++ b/doc/guides/contributing/versioning.rst
> @@ -125,6 +125,15 @@ added to the Release Notes:
>    these changes. Binaries using this library built prior to version 2.1 will
>    require updating and recompilation.
>  
> +New API replacing previous one
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +If a new API proposed functionally replaces an existing one, when the
> +new API becomes active then the old one is marked with ``__rte_deprecated``.

I don't think it's clear what 'active' means here. Can it be re-phrased
as something like "..when the new API has it's experimental tag removed,
then the old one..".

It might also be worth mentioning the reasoning behind this, perhaps
something like: This is so an application continues to be provided with
at least one stable (non-deprecated/non-experimental) API for this
functionality.

> +Deprecated APIs removed completely just after the next LTS.
> +
> +Reminder that new API should follow deprecation process to become active.
> +
>  
>  Experimental APIs
>  -----------------
> 

Re: [dpdk-dev] [PATCH v3 3/3] doc: add deprecation marker usage

[Ferruh Yigit]

On 1/23/2019 11:07 PM, Kevin Traynor wrote:
> On 01/22/2019 05:23 PM, Ferruh Yigit wrote:
>> Define '__rte_deprecated' usage process.
>>
>> Suggests keeping old API with '__rte_deprecated' marker including
>> next LTS, they will be removed just after the LTS release.
>>
>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>> Acked-by: Luca Boccassi <bluca@debian.org>
>> ---
>> Cc: Luca Boccassi <bluca@debian.org>
>> Cc: Kevin Traynor <ktraynor@redhat.com>
>> Cc: Yongseok Koh <yskoh@mellanox.com>
>> Cc: Neil Horman <nhorman@tuxdriver.com>
>>
>> v2:
>> * Rephrased as commented
>>
>> v3:
>> * changed when to remove the deprecated API. It is now just after
>> an LTS release, the motivation is to keep changes small in LTS.
>> Based on techboard discussion:
>> http://mails.dpdk.org/archives/dev/2019-January/123519.html
>> ---
>>  doc/guides/contributing/versioning.rst | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
>> index bfc27fbe0..977d06c60 100644
>> --- a/doc/guides/contributing/versioning.rst
>> +++ b/doc/guides/contributing/versioning.rst
>> @@ -125,6 +125,15 @@ added to the Release Notes:
>>    these changes. Binaries using this library built prior to version 2.1 will
>>    require updating and recompilation.
>>  
>> +New API replacing previous one
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +If a new API proposed functionally replaces an existing one, when the
>> +new API becomes active then the old one is marked with ``__rte_deprecated``.
> 
> I don't think it's clear what 'active' means here. Can it be re-phrased
> as something like "..when the new API has it's experimental tag removed,
> then the old one..".

This was what in my mind by 'active' but didn't want to create confusion with
details, and really it doesn't matter the "experimental" detail, by any means if
the new API is not 'active' we shouldn't mark the old one as 'deprecated'.

But agree can be defined better than 'active'. Do you have any suggestion here,
'GA', 'public', 'official', 'supported'?

> 
> It might also be worth mentioning the reasoning behind this, perhaps
> something like: This is so an application continues to be provided with
> at least one stable (non-deprecated/non-experimental) API for this
> functionality.
> 
>> +Deprecated APIs removed completely just after the next LTS.
>> +
>> +Reminder that new API should follow deprecation process to become active.
>> +
>>  
>>  Experimental APIs
>>  -----------------
>>
> 

Re: [dpdk-dev] [PATCH v3 3/3] doc: add deprecation marker usage

[Kevin Traynor]

On 01/24/2019 03:31 PM, Ferruh Yigit wrote:
> On 1/23/2019 11:07 PM, Kevin Traynor wrote:
>> On 01/22/2019 05:23 PM, Ferruh Yigit wrote:
>>> Define '__rte_deprecated' usage process.
>>>
>>> Suggests keeping old API with '__rte_deprecated' marker including
>>> next LTS, they will be removed just after the LTS release.
>>>
>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>> Acked-by: Luca Boccassi <bluca@debian.org>
>>> ---
>>> Cc: Luca Boccassi <bluca@debian.org>
>>> Cc: Kevin Traynor <ktraynor@redhat.com>
>>> Cc: Yongseok Koh <yskoh@mellanox.com>
>>> Cc: Neil Horman <nhorman@tuxdriver.com>
>>>
>>> v2:
>>> * Rephrased as commented
>>>
>>> v3:
>>> * changed when to remove the deprecated API. It is now just after
>>> an LTS release, the motivation is to keep changes small in LTS.
>>> Based on techboard discussion:
>>> http://mails.dpdk.org/archives/dev/2019-January/123519.html
>>> ---
>>>  doc/guides/contributing/versioning.rst | 9 +++++++++
>>>  1 file changed, 9 insertions(+)
>>>
>>> diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
>>> index bfc27fbe0..977d06c60 100644
>>> --- a/doc/guides/contributing/versioning.rst
>>> +++ b/doc/guides/contributing/versioning.rst
>>> @@ -125,6 +125,15 @@ added to the Release Notes:
>>>    these changes. Binaries using this library built prior to version 2.1 will
>>>    require updating and recompilation.
>>>  
>>> +New API replacing previous one
>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> +
>>> +If a new API proposed functionally replaces an existing one, when the
>>> +new API becomes active then the old one is marked with ``__rte_deprecated``.
>>
>> I don't think it's clear what 'active' means here. Can it be re-phrased
>> as something like "..when the new API has it's experimental tag removed,
>> then the old one..".
> 
> This was what in my mind by 'active' but didn't want to create confusion with
> details, and really it doesn't matter the "experimental" detail, by any means if
> the new API is not 'active' we shouldn't mark the old one as 'deprecated'.
> 
> But agree can be defined better than 'active'. Do you have any suggestion here,
> 'GA', 'public', 'official', 'supported'?
> 

How about 'non-experimental' ? I think it would make it clear in meaning
for general reading and also avoid a mis-interpretation of what the
actual detail is.

>>
>> It might also be worth mentioning the reasoning behind this, perhaps
>> something like: This is so an application continues to be provided with
>> at least one stable (non-deprecated/non-experimental) API for this
>> functionality.
>>
>>> +Deprecated APIs removed completely just after the next LTS.
>>> +
>>> +Reminder that new API should follow deprecation process to become active.
>>> +
>>>  
>>>  Experimental APIs
>>>  -----------------
>>>
>>
> 

Re: [dpdk-dev] [PATCH v3 3/3] doc: add deprecation marker usage

[Ferruh Yigit]

On 1/24/2019 3:33 PM, Kevin Traynor wrote:
> On 01/24/2019 03:31 PM, Ferruh Yigit wrote:
>> On 1/23/2019 11:07 PM, Kevin Traynor wrote:
>>> On 01/22/2019 05:23 PM, Ferruh Yigit wrote:
>>>> Define '__rte_deprecated' usage process.
>>>>
>>>> Suggests keeping old API with '__rte_deprecated' marker including
>>>> next LTS, they will be removed just after the LTS release.
>>>>
>>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>>> Acked-by: Luca Boccassi <bluca@debian.org>
>>>> ---
>>>> Cc: Luca Boccassi <bluca@debian.org>
>>>> Cc: Kevin Traynor <ktraynor@redhat.com>
>>>> Cc: Yongseok Koh <yskoh@mellanox.com>
>>>> Cc: Neil Horman <nhorman@tuxdriver.com>
>>>>
>>>> v2:
>>>> * Rephrased as commented
>>>>
>>>> v3:
>>>> * changed when to remove the deprecated API. It is now just after
>>>> an LTS release, the motivation is to keep changes small in LTS.
>>>> Based on techboard discussion:
>>>> http://mails.dpdk.org/archives/dev/2019-January/123519.html
>>>> ---
>>>>  doc/guides/contributing/versioning.rst | 9 +++++++++
>>>>  1 file changed, 9 insertions(+)
>>>>
>>>> diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
>>>> index bfc27fbe0..977d06c60 100644
>>>> --- a/doc/guides/contributing/versioning.rst
>>>> +++ b/doc/guides/contributing/versioning.rst
>>>> @@ -125,6 +125,15 @@ added to the Release Notes:
>>>>    these changes. Binaries using this library built prior to version 2.1 will
>>>>    require updating and recompilation.
>>>>  
>>>> +New API replacing previous one
>>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> +
>>>> +If a new API proposed functionally replaces an existing one, when the
>>>> +new API becomes active then the old one is marked with ``__rte_deprecated``.
>>>
>>> I don't think it's clear what 'active' means here. Can it be re-phrased
>>> as something like "..when the new API has it's experimental tag removed,
>>> then the old one..".
>>
>> This was what in my mind by 'active' but didn't want to create confusion with
>> details, and really it doesn't matter the "experimental" detail, by any means if
>> the new API is not 'active' we shouldn't mark the old one as 'deprecated'.
>>
>> But agree can be defined better than 'active'. Do you have any suggestion here,
>> 'GA', 'public', 'official', 'supported'?
>>
> 
> How about 'non-experimental' ? I think it would make it clear in meaning
> for general reading and also avoid a mis-interpretation of what the
> actual detail is.

OK, I will send a new versions with s/active/non-experimental/

> 
>>>
>>> It might also be worth mentioning the reasoning behind this, perhaps
>>> something like: This is so an application continues to be provided with
>>> at least one stable (non-deprecated/non-experimental) API for this
>>> functionality.
>>>
>>>> +Deprecated APIs removed completely just after the next LTS.
>>>> +
>>>> +Reminder that new API should follow deprecation process to become active.
>>>> +
>>>>  
>>>>  Experimental APIs
>>>>  -----------------
>>>>
>>>
>>
> 

[dpdk-dev] [PATCH v4 1/3] doc: clean ABI/API policy guide

[Ferruh Yigit]

The original document written from the point of ABI versioning but later
additions make document confusing, convert document into a ABI/API
policy documentation and organize the document in subsections:
- ABI/API Deprecation
- Experimental APIs
- Library versioning
- ABI versioning

Aim to clarify confusion between deprecation versioned ABI and overall
ABI/API deprecation, also ABI versioning and Library versioning by
organizing the sections.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
 doc/guides/contributing/versioning.rst | 132 +++++++++++++------------
 1 file changed, 71 insertions(+), 61 deletions(-)

diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 01b36247e..19af56cd2 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -1,33 +1,31 @@
 ..  SPDX-License-Identifier: BSD-3-Clause
     Copyright 2018 The DPDK contributors
 
-Managing ABI updates
-====================
+DPDK ABI/API policy
+===================
 
 Description
 -----------
 
 This document details some methods for handling ABI management in the DPDK.
-Note this document is not exhaustive, in that C library versioning is flexible
-allowing multiple methods to achieve various goals, but it will provide the user
-with some introductory methods
 
 General Guidelines
 ------------------
 
 #. Whenever possible, ABI should be preserved
-#. Libraries or APIs marked in ``experimental`` state may change without constraint.
+#. ABI/API may be changed with a deprecation process
+#. The modification of symbols can generally be managed with versioning
+#. Libraries or APIs marked in ``experimental`` state may change without constraint
 #. New APIs will be marked as ``experimental`` for at least one release to allow
    any issues found by users of the new API to be fixed quickly
 #. The addition of symbols is generally not problematic
-#. The modification of symbols can generally be managed with versioning
 #. The removal of symbols generally is an ABI break and requires bumping of the
    LIBABIVER macro
 #. Updates to the minimum hardware requirements, which drop support for hardware which
    was previously supported, should be treated as an ABI change.
 
 What is an ABI
---------------
+~~~~~~~~~~~~~~
 
 An ABI (Application Binary Interface) is the set of runtime interfaces exposed
 by a library. It is similar to an API (Application Programming Interface) but
@@ -39,9 +37,13 @@ Therefore, in the case of dynamic linking, it is critical that an ABI is
 preserved, or (when modified), done in such a way that the application is unable
 to behave improperly or in an unexpected fashion.
 
-The DPDK ABI policy
+
+ABI/API Deprecation
 -------------------
 
+The DPDK ABI policy
+~~~~~~~~~~~~~~~~~~~
+
 ABI versions are set at the time of major release labeling, and the ABI may
 change multiple times, without warning, between the last release label and the
 HEAD label of the git tree.
@@ -99,8 +101,36 @@ readability purposes should be avoided.
    follow the relevant deprecation policy procedures as above: 3 acks and
    announcement at least one release in advance.
 
+Examples of Deprecation Notices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following are some examples of ABI deprecation notices which would be
+added to the Release Notes:
+
+* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
+  to be replaced with the inline function ``rte_foo()``.
+
+* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
+  in version 2.0. Backwards compatibility will be maintained for this function
+  until the release of version 2.1
+
+* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
+  performance reasons. Existing binary applications will have backwards
+  compatibility in release 2.0, while newly built binaries will need to
+  reference the new structure variant ``struct rte_foo2``. Compatibility will
+  be removed in release 2.2, and all applications will require updating and
+  rebuilding to the new structure at that time, which will be renamed to the
+  original ``struct rte_foo``.
+
+* Significant ABI changes are planned for the ``librte_dostuff`` library. The
+  upcoming release 2.0 will not contain these changes, but release 2.1 will,
+  and no backwards compatibility is planned due to the extensive nature of
+  these changes. Binaries using this library built prior to version 2.1 will
+  require updating and recompilation.
+
+
 Experimental APIs
-~~~~~~~~~~~~~~~~~
+-----------------
 
 APIs marked as ``experimental`` are not considered part of the ABI and may
 change without warning at any time.  Since changes to APIs are most likely
@@ -130,35 +160,38 @@ is not required. Though, an API should remain in experimental state for at least
 one release. Thereafter, normal process of posting patch for review to mailing
 list can be followed.
 
-Examples of Deprecation Notices
--------------------------------
 
-The following are some examples of ABI deprecation notices which would be
-added to the Release Notes:
+Library versioning
+------------------
 
-* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
-  to be replaced with the inline function ``rte_foo()``.
+Downstreams might want to provide different DPDK releases at the same time to
+support multiple consumers of DPDK linked against older and newer sonames.
 
-* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
-  in version 2.0. Backwards compatibility will be maintained for this function
-  until the release of version 2.1
+Also due to the interdependencies that DPDK libraries can have applications
+might end up with an executable space in which multiple versions of a library
+are mapped by ld.so.
 
-* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
-  performance reasons. Existing binary applications will have backwards
-  compatibility in release 2.0, while newly built binaries will need to
-  reference the new structure variant ``struct rte_foo2``. Compatibility will
-  be removed in release 2.2, and all applications will require updating and
-  rebuilding to the new structure at that time, which will be renamed to the
-  original ``struct rte_foo``.
+Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
+depending on LibA.
 
-* Significant ABI changes are planned for the ``librte_dostuff`` library. The
-  upcoming release 2.0 will not contain these changes, but release 2.1 will,
-  and no backwards compatibility is planned due to the extensive nature of
-  these changes. Binaries using this library built prior to version 2.1 will
-  require updating and recompilation.
+.. note::
+
+    Application
+    \-> LibA.old
+    \-> LibB.new -> LibA.new
+
+That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
+If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
+library - versions defined in the libraries ``LIBABIVER``.
+An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
+``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
+
+
+ABI versioning
+--------------
 
 Versioning Macros
------------------
+~~~~~~~~~~~~~~~~~
 
 When a symbol is exported from a library to provide an API, it also provides a
 calling convention (ABI) that is embodied in its name, return type and
@@ -186,36 +219,11 @@ The macros exported are:
   fully qualified function ``p``, so that if a symbol becomes versioned, it
   can still be mapped back to the public symbol name.
 
-Setting a Major ABI version
----------------------------
-
-Downstreams might want to provide different DPDK releases at the same time to
-support multiple consumers of DPDK linked against older and newer sonames.
-
-Also due to the interdependencies that DPDK libraries can have applications
-might end up with an executable space in which multiple versions of a library
-are mapped by ld.so.
-
-Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
-depending on LibA.
-
-.. note::
-
-    Application
-    \-> LibA.old
-    \-> LibB.new -> LibA.new
-
-That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
-If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
-library - versions defined in the libraries ``LIBABIVER``.
-An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
-``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
-
 Examples of ABI Macro use
--------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Updating a public API
-~~~~~~~~~~~~~~~~~~~~~
+_____________________
 
 Assume we have a function as follows
 
@@ -425,7 +433,7 @@ and a new DPDK_2.1 version, used by future built applications.
 
 
 Deprecating part of a public API
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+________________________________
 
 Lets assume that you've done the above update, and after a few releases have
 passed you decide you would like to retire the old version of the function.
@@ -483,7 +491,7 @@ possibly incompatible library version:
    +LIBABIVER := 2
 
 Deprecating an entire ABI version
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+_________________________________
 
 While removing a symbol from and ABI may be useful, it is often more practical
 to remove an entire version node at once.  If a version node completely
@@ -532,6 +540,7 @@ Lastly, any VERSION_SYMBOL macros that point to the old version node should be
 removed, taking care to keep, where need old code in place to support newer
 versions of the symbol.
 
+
 Running the ABI Validator
 -------------------------
 
@@ -571,3 +580,4 @@ compile both tags) it will create compatibility reports in the
 follows::
 
   grep -lr Incompatible compat_reports/
+
-- 
2.17.2

[dpdk-dev] [PATCH v4 2/3] doc: make RTE_NEXT_ABI optional

[Ferruh Yigit]

Initial process requires oncoming changes described in deprecation
notice should be implemented in a RTE_NEXT_ABI gated way.

This has been discussed in technical board, and since this can cause a
multiple #ifdef blocks in multiple locations of the code, can be
confusing specially for the modifications that requires data structure
changes. Anyway this was not happening in practice.

Making RTE_NEXT_ABI usage more optional based on techboard decision:
http://mails.dpdk.org/archives/dev/2019-January/123519.html

The intention with using RTE_NEXT_ABI was to provide more information
to the user about planned changes, and force developer to think more in
coding level. Since RTE_NEXT_ABI become optional, now the preferred way
to do this is, if possible, sending changes, described in deprecation
notice, as a separate patch and reference it in deprecation notice.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
 doc/guides/contributing/versioning.rst | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 19af56cd2..bfc27fbe0 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -73,19 +73,16 @@ being provided. The requirements for doing so are:
      interest" be sought for each deprecation, for example: from NIC vendors,
      CPU vendors, end-users, etc.
 
-#. The changes (including an alternative map file) must be gated with
-   the ``RTE_NEXT_ABI`` option, and provided with a deprecation notice at the
-   same time.
-   It will become the default ABI in the next release.
+#. The changes (including an alternative map file) can be included with
+   deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option,
+   to provide more details about oncoming changes.
+   ``RTE_NEXT_ABI`` wrapper will be removed when it become the default ABI.
+   More preferred way to provide this information is sending the feature
+   as a separate patch and reference it in deprecation notice.
 
 #. A full deprecation cycle, as explained above, must be made to offer
    downstream consumers sufficient warning of the change.
 
-#. At the beginning of the next release cycle, every ``RTE_NEXT_ABI``
-   conditions will be removed, the ``LIBABIVER`` variable in the makefile(s)
-   where the ABI is changed will be incremented, and the map files will
-   be updated.
-
 Note that the above process for ABI deprecation should not be undertaken
 lightly. ABI stability is extremely important for downstream consumers of the
 DPDK, especially when distributed in shared object form. Every effort should
-- 
2.17.2

[dpdk-dev] [PATCH v4 3/3] doc: add deprecation marker usage

[Ferruh Yigit]

Define '__rte_deprecated' usage process.

Suggests keeping old API with '__rte_deprecated' marker including
next LTS, they will be removed just after the LTS release.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>

v2:
* Rephrased as commented

v3:
* changed when to remove the deprecated API. It is now just after
an LTS release, the motivation is to keep changes small in LTS.
Based on techboard discussion:
http://mails.dpdk.org/archives/dev/2019-January/123519.html

v4:
change working around 'active':
s/active/non-experimental/
s/become active/be able to replace old API
---
 doc/guides/contributing/versioning.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index bfc27fbe0..491fae438 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -125,6 +125,15 @@ added to the Release Notes:
   these changes. Binaries using this library built prior to version 2.1 will
   require updating and recompilation.
 
+New API replacing previous one
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If a new API proposed functionally replaces an existing one, when the new API
+becomes non-experimental then the old one is marked with ``__rte_deprecated``.
+Deprecated APIs removed completely just after the next LTS.
+
+Reminder that new API should follow deprecation process to be able to replace old API.
+
 
 Experimental APIs
 -----------------
-- 
2.17.2

Re: [dpdk-dev] [PATCH v4 3/3] doc: add deprecation marker usage

[Thomas Monjalon]

24/01/2019 19:10, Ferruh Yigit:
> Define '__rte_deprecated' usage process.
> 
> Suggests keeping old API with '__rte_deprecated' marker including
> next LTS, they will be removed just after the LTS release.
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> Acked-by: Luca Boccassi <bluca@debian.org>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
[...]
> +New API replacing previous one
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +If a new API proposed functionally replaces an existing one, when the new API
> +becomes non-experimental then the old one is marked with ``__rte_deprecated``.
> +Deprecated APIs removed completely just after the next LTS.

APIs removed -> APIs are removed

> +
> +Reminder that new API should follow deprecation process to be able to replace old API.

This last sentence is not clear to me.
I think you mean the old API should follow deprecation process
to be removed (replaced).

Re: [dpdk-dev] [PATCH v4 2/3] doc: make RTE_NEXT_ABI optional

[Thomas Monjalon]

24/01/2019 19:10, Ferruh Yigit:
> Initial process requires oncoming changes described in deprecation
> notice should be implemented in a RTE_NEXT_ABI gated way.
> 
> This has been discussed in technical board, and since this can cause a
> multiple #ifdef blocks in multiple locations of the code, can be
> confusing specially for the modifications that requires data structure
> changes. Anyway this was not happening in practice.
> 
> Making RTE_NEXT_ABI usage more optional based on techboard decision:
> http://mails.dpdk.org/archives/dev/2019-January/123519.html
> 
> The intention with using RTE_NEXT_ABI was to provide more information
> to the user about planned changes, and force developer to think more in
> coding level. Since RTE_NEXT_ABI become optional, now the preferred way
> to do this is, if possible, sending changes, described in deprecation
> notice, as a separate patch and reference it in deprecation notice.
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>

Acked-by: Thomas Monjalon <thomas@monjalon.net>

Re: [dpdk-dev] [PATCH v4 1/3] doc: clean ABI/API policy guide

[Kevin Traynor]

On 01/24/2019 06:10 PM, Ferruh Yigit wrote:
> The original document written from the point of ABI versioning but later
> additions make document confusing, convert document into a ABI/API
> policy documentation and organize the document in subsections:
> - ABI/API Deprecation
> - Experimental APIs
> - Library versioning
> - ABI versioning
> 
> Aim to clarify confusion between deprecation versioned ABI and overall
> ABI/API deprecation, also ABI versioning and Library versioning by
> organizing the sections.
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>

For series
Acked-by: Kevin Traynor <ktraynor@redhat.com>

Re: [dpdk-dev] [PATCH v4 3/3] doc: add deprecation marker usage

[Ferruh Yigit]

On 1/31/2019 5:17 PM, Thomas Monjalon wrote:
>> +
>> +Reminder that new API should follow deprecation process to be able to replace old API.
> This last sentence is not clear to me.
> I think you mean the old API should follow deprecation process
> to be removed (replaced).

Yes, we are trying to say same thing.

Deprecation process required for replacing API.

Re: [dpdk-dev] [PATCH v4 3/3] doc: add deprecation marker usage

[Thomas Monjalon]

01/02/2019 18:06, Ferruh Yigit:
> On 1/31/2019 5:17 PM, Thomas Monjalon wrote:
> >> +
> >> +Reminder that new API should follow deprecation process to be able to replace old API.
> > This last sentence is not clear to me.
> > I think you mean the old API should follow deprecation process
> > to be removed (replaced).
> 
> Yes, we are trying to say same thing.
> 
> Deprecation process required for replacing API.

I think it is important to emphasize that the process applies to removal.

[dpdk-dev] [PATCH v5 1/3] doc: clean ABI/API policy guide

[Ferruh Yigit]

The original document written from the point of ABI versioning but later
additions make document confusing, convert document into a ABI/API
policy documentation and organize the document in subsections:
- ABI/API Deprecation
- Experimental APIs
- Library versioning
- ABI versioning

Aim to clarify confusion between deprecation versioned ABI and overall
ABI/API deprecation, also ABI versioning and Library versioning by
organizing the sections.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
 doc/guides/contributing/versioning.rst | 132 +++++++++++++------------
 1 file changed, 71 insertions(+), 61 deletions(-)

diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 18b031998..0bd7e6c44 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -1,33 +1,31 @@
 ..  SPDX-License-Identifier: BSD-3-Clause
     Copyright 2018 The DPDK contributors
 
-Managing ABI updates
-====================
+DPDK ABI/API policy
+===================
 
 Description
 -----------
 
 This document details some methods for handling ABI management in the DPDK.
-Note this document is not exhaustive, in that C library versioning is flexible
-allowing multiple methods to achieve various goals, but it will provide the user
-with some introductory methods
 
 General Guidelines
 ------------------
 
 #. Whenever possible, ABI should be preserved
-#. Libraries or APIs marked in ``experimental`` state may change without constraint.
+#. ABI/API may be changed with a deprecation process
+#. The modification of symbols can generally be managed with versioning
+#. Libraries or APIs marked in ``experimental`` state may change without constraint
 #. New APIs will be marked as ``experimental`` for at least one release to allow
    any issues found by users of the new API to be fixed quickly
 #. The addition of symbols is generally not problematic
-#. The modification of symbols can generally be managed with versioning
 #. The removal of symbols generally is an ABI break and requires bumping of the
    LIBABIVER macro
 #. Updates to the minimum hardware requirements, which drop support for hardware which
    was previously supported, should be treated as an ABI change.
 
 What is an ABI
---------------
+~~~~~~~~~~~~~~
 
 An ABI (Application Binary Interface) is the set of runtime interfaces exposed
 by a library. It is similar to an API (Application Programming Interface) but
@@ -39,9 +37,13 @@ Therefore, in the case of dynamic linking, it is critical that an ABI is
 preserved, or (when modified), done in such a way that the application is unable
 to behave improperly or in an unexpected fashion.
 
-The DPDK ABI policy
+
+ABI/API Deprecation
 -------------------
 
+The DPDK ABI policy
+~~~~~~~~~~~~~~~~~~~
+
 ABI versions are set at the time of major release labeling, and the ABI may
 change multiple times, without warning, between the last release label and the
 HEAD label of the git tree.
@@ -99,8 +101,36 @@ readability purposes should be avoided.
    follow the relevant deprecation policy procedures as above: 3 acks and
    announcement at least one release in advance.
 
+Examples of Deprecation Notices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following are some examples of ABI deprecation notices which would be
+added to the Release Notes:
+
+* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
+  to be replaced with the inline function ``rte_foo()``.
+
+* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
+  in version 2.0. Backwards compatibility will be maintained for this function
+  until the release of version 2.1
+
+* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
+  performance reasons. Existing binary applications will have backwards
+  compatibility in release 2.0, while newly built binaries will need to
+  reference the new structure variant ``struct rte_foo2``. Compatibility will
+  be removed in release 2.2, and all applications will require updating and
+  rebuilding to the new structure at that time, which will be renamed to the
+  original ``struct rte_foo``.
+
+* Significant ABI changes are planned for the ``librte_dostuff`` library. The
+  upcoming release 2.0 will not contain these changes, but release 2.1 will,
+  and no backwards compatibility is planned due to the extensive nature of
+  these changes. Binaries using this library built prior to version 2.1 will
+  require updating and recompilation.
+
+
 Experimental APIs
-~~~~~~~~~~~~~~~~~
+-----------------
 
 APIs marked as ``experimental`` are not considered part of the ABI and may
 change without warning at any time.  Since changes to APIs are most likely
@@ -130,35 +160,38 @@ is not required. Though, an API should remain in experimental state for at least
 one release. Thereafter, normal process of posting patch for review to mailing
 list can be followed.
 
-Examples of Deprecation Notices
--------------------------------
 
-The following are some examples of ABI deprecation notices which would be
-added to the Release Notes:
+Library versioning
+------------------
 
-* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
-  to be replaced with the inline function ``rte_foo()``.
+Downstreams might want to provide different DPDK releases at the same time to
+support multiple consumers of DPDK linked against older and newer sonames.
 
-* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
-  in version 2.0. Backwards compatibility will be maintained for this function
-  until the release of version 2.1
+Also due to the interdependencies that DPDK libraries can have applications
+might end up with an executable space in which multiple versions of a library
+are mapped by ld.so.
 
-* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
-  performance reasons. Existing binary applications will have backwards
-  compatibility in release 2.0, while newly built binaries will need to
-  reference the new structure variant ``struct rte_foo2``. Compatibility will
-  be removed in release 2.2, and all applications will require updating and
-  rebuilding to the new structure at that time, which will be renamed to the
-  original ``struct rte_foo``.
+Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
+depending on LibA.
 
-* Significant ABI changes are planned for the ``librte_dostuff`` library. The
-  upcoming release 2.0 will not contain these changes, but release 2.1 will,
-  and no backwards compatibility is planned due to the extensive nature of
-  these changes. Binaries using this library built prior to version 2.1 will
-  require updating and recompilation.
+.. note::
+
+    Application
+    \-> LibA.old
+    \-> LibB.new -> LibA.new
+
+That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
+If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
+library - versions defined in the libraries ``LIBABIVER``.
+An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
+``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
+
+
+ABI versioning
+--------------
 
 Versioning Macros
------------------
+~~~~~~~~~~~~~~~~~
 
 When a symbol is exported from a library to provide an API, it also provides a
 calling convention (ABI) that is embodied in its name, return type and
@@ -186,36 +219,11 @@ The macros exported are:
   fully qualified function ``p``, so that if a symbol becomes versioned, it
   can still be mapped back to the public symbol name.
 
-Setting a Major ABI version
----------------------------
-
-Downstreams might want to provide different DPDK releases at the same time to
-support multiple consumers of DPDK linked against older and newer sonames.
-
-Also due to the interdependencies that DPDK libraries can have applications
-might end up with an executable space in which multiple versions of a library
-are mapped by ld.so.
-
-Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
-depending on LibA.
-
-.. note::
-
-    Application
-    \-> LibA.old
-    \-> LibB.new -> LibA.new
-
-That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
-If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
-library - versions defined in the libraries ``LIBABIVER``.
-An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
-``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
-
 Examples of ABI Macro use
--------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Updating a public API
-~~~~~~~~~~~~~~~~~~~~~
+_____________________
 
 Assume we have a function as follows
 
@@ -425,7 +433,7 @@ and a new DPDK_2.1 version, used by future built applications.
 
 
 Deprecating part of a public API
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+________________________________
 
 Lets assume that you've done the above update, and after a few releases have
 passed you decide you would like to retire the old version of the function.
@@ -483,7 +491,7 @@ possibly incompatible library version:
    +LIBABIVER := 2
 
 Deprecating an entire ABI version
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+_________________________________
 
 While removing a symbol from and ABI may be useful, it is often more practical
 to remove an entire version node at once.  If a version node completely
@@ -532,6 +540,7 @@ Lastly, any VERSION_SYMBOL macros that point to the old version node should be
 removed, taking care to keep, where need old code in place to support newer
 versions of the symbol.
 
+
 Running the ABI Validator
 -------------------------
 
@@ -571,3 +580,4 @@ compile both tags) it will create compatibility reports in the
 follows::
 
   grep -lr Incompatible compat_reports/
+
-- 
2.20.1

[dpdk-dev] [PATCH v5 2/3] doc: make RTE_NEXT_ABI optional

[Ferruh Yigit]

Initial process requires oncoming changes described in deprecation
notice should be implemented in a RTE_NEXT_ABI gated way.

This has been discussed in technical board, and since this can cause a
multiple #ifdef blocks in multiple locations of the code, can be
confusing specially for the modifications that requires data structure
changes. Anyway this was not happening in practice.

Making RTE_NEXT_ABI usage more optional based on techboard decision:
http://mails.dpdk.org/archives/dev/2019-January/123519.html

The intention with using RTE_NEXT_ABI was to provide more information
to the user about planned changes, and force developer to think more in
coding level. Since RTE_NEXT_ABI become optional, now the preferred way
to do this is, if possible, sending changes, described in deprecation
notice, as a separate patch and reference it in deprecation notice.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
 doc/guides/contributing/versioning.rst | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 0bd7e6c44..2fcb8bafd 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -73,19 +73,16 @@ being provided. The requirements for doing so are:
      interest" be sought for each deprecation, for example: from NIC vendors,
      CPU vendors, end-users, etc.
 
-#. The changes (including an alternative map file) must be gated with
-   the ``RTE_NEXT_ABI`` option, and provided with a deprecation notice at the
-   same time.
-   It will become the default ABI in the next release.
+#. The changes (including an alternative map file) can be included with
+   deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option,
+   to provide more details about oncoming changes.
+   ``RTE_NEXT_ABI`` wrapper will be removed when it become the default ABI.
+   More preferred way to provide this information is sending the feature
+   as a separate patch and reference it in deprecation notice.
 
 #. A full deprecation cycle, as explained above, must be made to offer
    downstream consumers sufficient warning of the change.
 
-#. At the beginning of the next release cycle, every ``RTE_NEXT_ABI``
-   conditions will be removed, the ``LIBABIVER`` variable in the makefile(s)
-   where the ABI is changed will be incremented, and the map files will
-   be updated.
-
 Note that the above process for ABI deprecation should not be undertaken
 lightly. ABI stability is extremely important for downstream consumers of the
 DPDK, especially when distributed in shared object form. Every effort should
-- 
2.20.1

[dpdk-dev] [PATCH v5 3/3] doc: add deprecation marker usage

[Ferruh Yigit]

Define '__rte_deprecated' usage process.

Suggests keeping old API with '__rte_deprecated' marker including
next LTS, they will be removed just after the LTS release.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>

v2:
* Rephrased as commented

v3:
* changed when to remove the deprecated API. It is now just after
an LTS release, the motivation is to keep changes small in LTS.
Based on techboard discussion:
http://mails.dpdk.org/archives/dev/2019-January/123519.html

v4:
change working around 'active':
s/active/non-experimental/
s/become active/be able to replace old API

v5:
Grammar fix
Rephrase API removal reminder
---
 doc/guides/contributing/versioning.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 2fcb8bafd..30f8735ba 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -125,6 +125,15 @@ added to the Release Notes:
   these changes. Binaries using this library built prior to version 2.1 will
   require updating and recompilation.
 
+New API replacing previous one
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If a new API proposed functionally replaces an existing one, when the new API
+becomes non-experimental then the old one is marked with ``__rte_deprecated``.
+Deprecated APIs are removed completely just after the next LTS.
+
+Reminder that old API should follow deprecation process to be removed.
+
 
 Experimental APIs
 -----------------
-- 
2.20.1

Re: [dpdk-dev] [PATCH v5 3/3] doc: add deprecation marker usage

[Kevin Traynor]

On 01/03/2019 17:32, Ferruh Yigit wrote:
> Define '__rte_deprecated' usage process.
> 
> Suggests keeping old API with '__rte_deprecated' marker including
> next LTS, they will be removed just after the LTS release.
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> Acked-by: Luca Boccassi <bluca@debian.org>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
> ---
> Cc: Luca Boccassi <bluca@debian.org>
> Cc: Kevin Traynor <ktraynor@redhat.com>
> Cc: Yongseok Koh <yskoh@mellanox.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> 
> v2:
> * Rephrased as commented
> 
> v3:
> * changed when to remove the deprecated API. It is now just after
> an LTS release, the motivation is to keep changes small in LTS.
> Based on techboard discussion:
> http://mails.dpdk.org/archives/dev/2019-January/123519.html
> 
> v4:
> change working around 'active':
> s/active/non-experimental/
> s/become active/be able to replace old API
> 
> v5:
> Grammar fix
> Rephrase API removal reminder
> ---
>  doc/guides/contributing/versioning.rst | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
> index 2fcb8bafd..30f8735ba 100644
> --- a/doc/guides/contributing/versioning.rst
> +++ b/doc/guides/contributing/versioning.rst
> @@ -125,6 +125,15 @@ added to the Release Notes:
>    these changes. Binaries using this library built prior to version 2.1 will
>    require updating and recompilation.
>  
> +New API replacing previous one
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +If a new API proposed functionally replaces an existing one, when the new API
> +becomes non-experimental then the old one is marked with ``__rte_deprecated``.
> +Deprecated APIs are removed completely just after the next LTS.
> +
> +Reminder that old API should follow deprecation process to be removed.
> +
>  
>  Experimental APIs
>  -----------------
> 

Acked-by: Kevin Traynor <ktraynor@redhat.com>

for series, again :-)

Re: [dpdk-dev] [PATCH v5 3/3] doc: add deprecation marker usage

[Thomas Monjalon]

01/03/2019 18:40, Kevin Traynor:
> On 01/03/2019 17:32, Ferruh Yigit wrote:
> > Define '__rte_deprecated' usage process.
> > 
> > Suggests keeping old API with '__rte_deprecated' marker including
> > next LTS, they will be removed just after the LTS release.
> > 
> > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> > Acked-by: Luca Boccassi <bluca@debian.org>
> > Acked-by: Neil Horman <nhorman@tuxdriver.com>
> 
> Acked-by: Kevin Traynor <ktraynor@redhat.com>
> 
> for series, again :-)

Applied, thanks

Re: [dpdk-dev] [PATCH v5 3/3] doc: add deprecation marker usage

[Thomas Monjalon]

01/03/2019 18:40, Kevin Traynor:
> On 01/03/2019 17:32, Ferruh Yigit wrote:
> > Define '__rte_deprecated' usage process.
> > 
> > Suggests keeping old API with '__rte_deprecated' marker including
> > next LTS, they will be removed just after the LTS release.
> > 
> > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> > Acked-by: Luca Boccassi <bluca@debian.org>
> > Acked-by: Neil Horman <nhorman@tuxdriver.com>
> 
> Acked-by: Kevin Traynor <ktraynor@redhat.com>
> 
> for series, again :-)

Applied, thanks