[dpdk-dev] [PATCH v2 20.08 1/6] doc: announce deprecation of master lcore

[Bruce Richardson]

On Wed, Jul 29, 2020 at 05:57:59PM -0700, Stephen Hemminger wrote:
> Announce upcoming changes related to master/slave in reference
> to lcore.
> 
> Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
> ---
>  doc/guides/rel_notes/deprecation.rst | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 99c98062ffc2..7c60779f3e68 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -148,3 +148,20 @@ Deprecation Notices
>    Python 2 support will be completely removed in 20.11.
>    In 20.08, explicit deprecation warnings will be displayed when running
>    scripts with Python 2.
> +
> +* eal: To be more inclusive in choice of naming, the DPDK project
> +  will replace uses of master/slave in  the API's and command line arguments.
> +
> +  References to master/slave in relation to lcore will be renamed
> +  to initial/worker.  The function ``rte_get_master_lcore()``
> +  will be renamed to ``rte_get_initial_lcore()``.
> +  For the 20.11, release both names will be present and the
> +  old function will be marked with the deprecated tag.
> +  The old function will be removed in 21.11 version.

Since 20.11 is going to be ABI incompatible with previous versions anyway,
can we not have the function as a macro alias for the new, allowing us to
remove the old sooner without breaking any apps? Even if this is not the
case, I think it might be better to change "21.11 version" to "a future
release" to allow us some flexibility on when to remove them in case we can
remove them sooner.

> +
> +  The iterator for worker lcores will also change:
> +  ``RTE_LCORE_FOREACH_SLAVE`` will be replaced with
> +  ``RTE_LCORE_FOREACH_WORKER``.
> +
> +  The ``master-lcore`` argument to testpmd will be replaced
> +  with ``initial-lcore``.
> -- 

With the above comment.

Acked-by: Bruce Richardson <bruce.richardson at intel.com>