[dpdk-dev] [PATCH v3 22/27] doc: update references to master/slave lcore in documentation

[Stephen Hemminger <stephen@networkplumber.org>]

New terms are initial and worker lcores.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 doc/guides/contributing/coding_style.rst            |  2 +-
 doc/guides/faq/faq.rst                              |  6 +++---
 doc/guides/howto/debug_troubleshoot.rst             |  2 +-
 doc/guides/linux_gsg/eal_args.include.rst           |  4 ++--
 doc/guides/nics/bnxt.rst                            |  2 +-
 doc/guides/nics/fail_safe.rst                       |  3 ---
 doc/guides/prog_guide/env_abstraction_layer.rst     |  6 +++---
 doc/guides/prog_guide/event_ethernet_rx_adapter.rst |  2 +-
 doc/guides/prog_guide/glossary.rst                  |  8 ++++----
 doc/guides/rel_notes/release_20_08.rst              |  7 ++++++-
 doc/guides/sample_app_ug/bbdev_app.rst              |  2 +-
 doc/guides/sample_app_ug/ethtool.rst                |  4 ++--
 doc/guides/sample_app_ug/hello_world.rst            |  8 ++++----
 doc/guides/sample_app_ug/ioat.rst                   | 12 ++++++------
 doc/guides/sample_app_ug/ip_pipeline.rst            |  4 ++--
 doc/guides/sample_app_ug/keep_alive.rst             |  2 +-
 doc/guides/sample_app_ug/l2_forward_event.rst       |  4 ++--
 .../sample_app_ug/l2_forward_real_virtual.rst       |  4 ++--
 doc/guides/sample_app_ug/l3_forward_graph.rst       |  6 +++---
 doc/guides/sample_app_ug/l3_forward_power_man.rst   |  2 +-
 doc/guides/sample_app_ug/link_status_intr.rst       |  4 ++--
 doc/guides/sample_app_ug/multi_process.rst          |  6 +++---
 doc/guides/sample_app_ug/packet_ordering.rst        |  8 ++++----
 doc/guides/sample_app_ug/performance_thread.rst     |  6 +++---
 doc/guides/sample_app_ug/qos_scheduler.rst          |  4 ++--
 doc/guides/sample_app_ug/timer.rst                  | 13 +++++++------
 doc/guides/testpmd_app_ug/run_app.rst               |  2 +-
 doc/guides/testpmd_app_ug/testpmd_funcs.rst         |  2 +-
 28 files changed, 69 insertions(+), 66 deletions(-)

diff --git a/doc/guides/contributing/coding_style.rst b/doc/guides/contributing/coding_style.rst
index 4efde93f6af0..321d54438f7d 100644
--- a/doc/guides/contributing/coding_style.rst
+++ b/doc/guides/contributing/coding_style.rst
@@ -334,7 +334,7 @@ For example:
 	typedef int (lcore_function_t)(void *);
 
 	/* launch a function of lcore_function_t type */
-	int rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned slave_id);
+	int rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned id);
 
 
 C Indentation
diff --git a/doc/guides/faq/faq.rst b/doc/guides/faq/faq.rst
index f19c1389b6af..cb5f35923d64 100644
--- a/doc/guides/faq/faq.rst
+++ b/doc/guides/faq/faq.rst
@@ -42,13 +42,13 @@ I am running a 32-bit DPDK application on a NUMA system, and sometimes the appli
 If your system has a lot (>1 GB size) of hugepage memory, not all of it will be allocated.
 Due to hugepages typically being allocated on a local NUMA node, the hugepages allocation the application gets during the initialization depends on which
 NUMA node it is running on (the EAL does not affinitize cores until much later in the initialization process).
-Sometimes, the Linux OS runs the DPDK application on a core that is located on a different NUMA node from DPDK master core and
+Sometimes, the Linux OS runs the DPDK application on a core that is located on a different NUMA node from DPDK initial core and
 therefore all the hugepages are allocated on the wrong socket.
 
 To avoid this scenario, either lower the amount of hugepage memory available to 1 GB size (or less), or run the application with taskset
-affinitizing the application to a would-be master core.
+affinitizing the application to a would-be initial core.
 
-For example, if your EAL coremask is 0xff0, the master core will usually be the first core in the coremask (0x10); this is what you have to supply to taskset::
+For example, if your EAL coremask is 0xff0, the initial core will usually be the first core in the coremask (0x10); this is what you have to supply to taskset::
 
    taskset 0x10 ./l2fwd -l 4-11 -n 2
 
diff --git a/doc/guides/howto/debug_troubleshoot.rst b/doc/guides/howto/debug_troubleshoot.rst
index cef016b2fef4..fdeaabe62206 100644
--- a/doc/guides/howto/debug_troubleshoot.rst
+++ b/doc/guides/howto/debug_troubleshoot.rst
@@ -311,7 +311,7 @@ Custom worker function :numref:`dtg_distributor_worker`.
      SERVICE. Check performance functions are mapped to run on the cores.
 
    * For high-performance execution logic ensure running it on correct NUMA
-     and non-master core.
+     and worker core.
 
    * Analyze run logic with ``rte_dump_stack``, ``rte_dump_registers`` and
      ``rte_memdump`` for more insights.
diff --git a/doc/guides/linux_gsg/eal_args.include.rst b/doc/guides/linux_gsg/eal_args.include.rst
index 0fe44579689b..ca7508fb423e 100644
--- a/doc/guides/linux_gsg/eal_args.include.rst
+++ b/doc/guides/linux_gsg/eal_args.include.rst
@@ -33,9 +33,9 @@ Lcore-related options
     At a given instance only one core option ``--lcores``, ``-l`` or ``-c`` can
     be used.
 
-*   ``--master-lcore <core ID>``
+*   ``--initial-lcore <core ID>``
 
-    Core ID that is used as master.
+    Core ID that is used as initial lcore.
 
 *   ``-s <service core mask>``
 
diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst
index a53cdad21d34..6a7314a91627 100644
--- a/doc/guides/nics/bnxt.rst
+++ b/doc/guides/nics/bnxt.rst
@@ -385,7 +385,7 @@ The application enables multiple TX and RX queues when it is started.
 
 .. code-block:: console
 
-    testpmd -l 1,3,5 --master-lcore 1 --txq=2 –rxq=2 --nb-cores=2
+    testpmd -l 1,3,5 --initial-lcore 1 --txq=2 –rxq=2 --nb-cores=2
 
 **TSS**
 
diff --git a/doc/guides/nics/fail_safe.rst b/doc/guides/nics/fail_safe.rst
index b4a92f663b17..3b15d6f0743d 100644
--- a/doc/guides/nics/fail_safe.rst
+++ b/doc/guides/nics/fail_safe.rst
@@ -236,9 +236,6 @@ Upkeep round
     (brought down or up accordingly). Additionally, any sub-device marked for
     removal is cleaned-up.
 
-Slave
-    In the context of the fail-safe PMD, synonymous to sub-device.
-
 Sub-device
     A device being utilized by the fail-safe PMD.
     This is another PMD running underneath the fail-safe PMD.
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index 48a2fec066db..463245463c52 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -64,7 +64,7 @@ It consist of calls to the pthread library (more specifically, pthread_self(), p
 .. note::
 
     Initialization of objects, such as memory zones, rings, memory pools, lpm tables and hash tables,
-    should be done as part of the overall application initialization on the master lcore.
+    should be done as part of the overall application initialization on the initial lcore.
     The creation and initialization functions for these objects are not multi-thread safe.
     However, once initialized, the objects themselves can safely be used in multiple threads simultaneously.
 
@@ -186,7 +186,7 @@ very dependent on the memory allocation patterns of the application.
 
 Additional restrictions are present when running in 32-bit mode. In dynamic
 memory mode, by default maximum of 2 gigabytes of VA space will be preallocated,
-and all of it will be on master lcore NUMA node unless ``--socket-mem`` flag is
+and all of it will be on initial lcore NUMA node unless ``--socket-mem`` flag is
 used.
 
 In legacy mode, VA space will only be preallocated for segments that were
@@ -603,7 +603,7 @@ controlled with tools like taskset (Linux) or cpuset (FreeBSD),
 - with affinity restricted to 2-4, the Control Threads will end up on
   CPU 4.
 - with affinity restricted to 2-3, the Control Threads will end up on
-  CPU 2 (master lcore, which is the default when no CPU is available).
+  CPU 2 (initial lcore, which is the default when no CPU is available).
 
 .. _known_issue_label:
 
diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
index c7dda92215ea..5d015fa2d678 100644
--- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
+++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
@@ -172,7 +172,7 @@ converts the received packets to events in the same manner as packets
 received on a polled Rx queue. The interrupt thread is affinitized to the same
 CPUs as the lcores of the Rx adapter service function, if the Rx adapter
 service function has not been mapped to any lcores, the interrupt thread
-is mapped to the master lcore.
+is mapped to the initial lcore.
 
 Rx Callback for SW Rx Adapter
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/prog_guide/glossary.rst b/doc/guides/prog_guide/glossary.rst
index 21063a414729..3716efd13da2 100644
--- a/doc/guides/prog_guide/glossary.rst
+++ b/doc/guides/prog_guide/glossary.rst
@@ -124,9 +124,9 @@ LAN
 LPM
    Longest Prefix Match
 
-master lcore
+initial lcore
    The execution unit that executes the main() function and that launches
-   other lcores.
+   other lcores. Described in older versions as master lcore.
 
 mbuf
    An mbuf is a data structure used internally to carry messages (mainly
@@ -184,8 +184,8 @@ RTE
 Rx
    Reception
 
-Slave lcore
-   Any *lcore* that is not the *master lcore*.
+Worker lcore
+   Any *lcore* that is not the *initial lcore*.
 
 Socket
    A physical CPU, that includes several *cores*.
diff --git a/doc/guides/rel_notes/release_20_08.rst b/doc/guides/rel_notes/release_20_08.rst
index 5cbc4ce14446..ecbceb0d05e3 100644
--- a/doc/guides/rel_notes/release_20_08.rst
+++ b/doc/guides/rel_notes/release_20_08.rst
@@ -107,6 +107,9 @@ New Features
   * Dump ``rte_flow`` memory consumption.
   * Measure packet per second forwarding.
 
+* **Renamed master lcore to initial lcore.**
+
+  The name given to the first thread in DPDK is changed from master lcore to initial lcore.
 
 Removed Items
 -------------
@@ -122,7 +125,6 @@ Removed Items
 
 * Removed ``RTE_KDRV_NONE`` based PCI device driver probing.
 
-
 API Changes
 -----------
 
@@ -143,6 +145,9 @@ API Changes
 * vhost: The API of ``rte_vhost_host_notifier_ctrl`` was changed to be per
   queue and not per device, a qid parameter was added to the arguments list.
 
+* ``rte_get_master_lcore`` was renamed to ``rte_get_initial_lcore``
+  The old function is deprecated and will be removed in future release.
+
 
 ABI Changes
 -----------
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 405e706a46e4..5917d52ca199 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -94,7 +94,7 @@ device gets linked to a corresponding ethernet port as whitelisted by
 the parameter -w.
 3 cores are allocated to the application, and assigned as:
 
- - core 3 is the master and used to print the stats live on screen,
+ - core 3 is the initial and used to print the stats live on screen,
 
  - core 4 is the encoding lcore performing Rx and Turbo Encode operations
 
diff --git a/doc/guides/sample_app_ug/ethtool.rst b/doc/guides/sample_app_ug/ethtool.rst
index 8f7fc6ca66c0..a4b92255c266 100644
--- a/doc/guides/sample_app_ug/ethtool.rst
+++ b/doc/guides/sample_app_ug/ethtool.rst
@@ -64,8 +64,8 @@ Explanation
 -----------
 
 The sample program has two parts: A background `packet reflector`_
-that runs on a slave core, and a foreground `Ethtool Shell`_ that
-runs on the master core. These are described below.
+that runs on a worker core, and a foreground `Ethtool Shell`_ that
+runs on the initial core. These are described below.
 
 Packet Reflector
 ~~~~~~~~~~~~~~~~
diff --git a/doc/guides/sample_app_ug/hello_world.rst b/doc/guides/sample_app_ug/hello_world.rst
index 46f997a7dce3..f6740b10e385 100644
--- a/doc/guides/sample_app_ug/hello_world.rst
+++ b/doc/guides/sample_app_ug/hello_world.rst
@@ -75,13 +75,13 @@ The code that launches the function on each lcore is as follows:
 
 .. code-block:: c
 
-    /* call lcore_hello() on every slave lcore */
+    /* call lcore_hello() on every worker lcore */
 
-    RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+    RTE_LCORE_FOREACH_WORKER(lcore_id) {
        rte_eal_remote_launch(lcore_hello, NULL, lcore_id);
     }
 
-    /* call it on master lcore too */
+    /* call it on initial lcore too */
 
     lcore_hello(NULL);
 
@@ -89,6 +89,6 @@ The following code is equivalent and simpler:
 
 .. code-block:: c
 
-    rte_eal_mp_remote_launch(lcore_hello, NULL, CALL_MASTER);
+    rte_eal_mp_remote_launch(lcore_hello, NULL, CALL_INITIAL);
 
 Refer to the *DPDK API Reference* for detailed information on the rte_eal_mp_remote_launch() function.
diff --git a/doc/guides/sample_app_ug/ioat.rst b/doc/guides/sample_app_ug/ioat.rst
index bab7654b8d4d..c75b91bfa989 100644
--- a/doc/guides/sample_app_ug/ioat.rst
+++ b/doc/guides/sample_app_ug/ioat.rst
@@ -69,13 +69,13 @@ provided parameters. The app can use up to 2 lcores: one of them receives
 incoming traffic and makes a copy of each packet. The second lcore then
 updates MAC address and sends the copy. If one lcore per port is used,
 both operations are done sequentially. For each configuration an additional
-lcore is needed since the master lcore does not handle traffic but is
+lcore is needed since the initial lcore does not handle traffic but is
 responsible for configuration, statistics printing and safe shutdown of
 all ports and devices.
 
 The application can use a maximum of 8 ports.
 
-To run the application in a Linux environment with 3 lcores (the master lcore,
+To run the application in a Linux environment with 3 lcores (the initial lcore,
 plus two forwarding cores), a single port (port 0), software copying and MAC
 updating issue the command:
 
@@ -83,7 +83,7 @@ updating issue the command:
 
     $ ./build/ioatfwd -l 0-2 -n 2 -- -p 0x1 --mac-updating -c sw
 
-To run the application in a Linux environment with 2 lcores (the master lcore,
+To run the application in a Linux environment with 2 lcores (the initial lcore,
 plus one forwarding core), 2 ports (ports 0 and 1), hardware copying and no MAC
 updating issue the command:
 
@@ -208,7 +208,7 @@ After that each port application assigns resources needed.
     cfg.nb_lcores = rte_lcore_count() - 1;
     if (cfg.nb_lcores < 1)
         rte_exit(EXIT_FAILURE,
-            "There should be at least one slave lcore.\n");
+            "There should be at least one worker lcore.\n");
 
     ret = 0;
 
@@ -310,8 +310,8 @@ If initialization is successful, memory for hardware device
 statistics is allocated.
 
 Finally ``main()`` function starts all packet handling lcores and starts
-printing stats in a loop on the master lcore. The application can be
-interrupted and closed using ``Ctrl-C``. The master lcore waits for
+printing stats in a loop on the initial lcore. The application can be
+interrupted and closed using ``Ctrl-C``. The initial lcore waits for
 all slave processes to finish, deallocates resources and exits.
 
 The processing lcores launching function are described below.
diff --git a/doc/guides/sample_app_ug/ip_pipeline.rst b/doc/guides/sample_app_ug/ip_pipeline.rst
index 56014be17458..f395027b3498 100644
--- a/doc/guides/sample_app_ug/ip_pipeline.rst
+++ b/doc/guides/sample_app_ug/ip_pipeline.rst
@@ -122,7 +122,7 @@ is displayed and the application is terminated.
 Run-time
 ~~~~~~~~
 
-The master thread is creating and managing all the application objects based on CLI input.
+The initial thread is creating and managing all the application objects based on CLI input.
 
 Each data plane thread runs one or several pipelines previously assigned to it in round-robin order. Each data plane thread
 executes two tasks in time-sharing mode:
@@ -130,7 +130,7 @@ executes two tasks in time-sharing mode:
 1. *Packet processing task*: Process bursts of input packets read from the pipeline input ports.
 
 2. *Message handling task*: Periodically, the data plane thread pauses the packet processing task and polls for request
-   messages send by the master thread. Examples: add/remove pipeline to/from current data plane thread, add/delete rules
+   messages send by the initial thread. Examples: add/remove pipeline to/from current data plane thread, add/delete rules
    to/from given table of a specific pipeline owned by the current data plane thread, read statistics, etc.
 
 Examples
diff --git a/doc/guides/sample_app_ug/keep_alive.rst b/doc/guides/sample_app_ug/keep_alive.rst
index 865ba69e5c47..bca5df8ba934 100644
--- a/doc/guides/sample_app_ug/keep_alive.rst
+++ b/doc/guides/sample_app_ug/keep_alive.rst
@@ -16,7 +16,7 @@ Overview
 --------
 
 The application demonstrates how to protect against 'silent outages'
-on packet processing cores. A Keep Alive Monitor Agent Core (master)
+on packet processing cores. A Keep Alive Monitor Agent Core (initial)
 monitors the state of packet processing cores (worker cores) by
 dispatching pings at a regular time interval (default is 5ms) and
 monitoring the state of the cores. Cores states are: Alive, MIA, Dead
diff --git a/doc/guides/sample_app_ug/l2_forward_event.rst b/doc/guides/sample_app_ug/l2_forward_event.rst
index d536eee819d0..f384420cf1f0 100644
--- a/doc/guides/sample_app_ug/l2_forward_event.rst
+++ b/doc/guides/sample_app_ug/l2_forward_event.rst
@@ -630,8 +630,8 @@ not many packets to send, however it improves performance:
 
                         /* if timer has reached its timeout */
                         if (unlikely(timer_tsc >= timer_period)) {
-                                /* do this only on master core */
-                                if (lcore_id == rte_get_master_lcore()) {
+                                /* do this only on initial core */
+                                if (lcore_id == rte_get_initial_lcore()) {
                                         print_stats();
                                         /* reset the timer */
                                         timer_tsc = 0;
diff --git a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
index 671d0c7c19d4..615a55c36db9 100644
--- a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
+++ b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
@@ -440,9 +440,9 @@ however it improves performance:
             /* if timer has reached its timeout */
 
             if (unlikely(timer_tsc >= (uint64_t) timer_period)) {
-                /* do this only on master core */
+                /* do this only on initial core */
 
-                if (lcore_id == rte_get_master_lcore()) {
+                if (lcore_id == rte_get_initial_lcore()) {
                     print_stats();
 
                     /* reset the timer */
diff --git a/doc/guides/sample_app_ug/l3_forward_graph.rst b/doc/guides/sample_app_ug/l3_forward_graph.rst
index df50827bab86..4ac96fc0c2f7 100644
--- a/doc/guides/sample_app_ug/l3_forward_graph.rst
+++ b/doc/guides/sample_app_ug/l3_forward_graph.rst
@@ -22,7 +22,7 @@ Run-time path is main thing that differs from L3 forwarding sample application.
 Difference is that forwarding logic starting from Rx, followed by LPM lookup,
 TTL update and finally Tx is implemented inside graph nodes. These nodes are
 interconnected in graph framework. Application main loop needs to walk over
-graph using ``rte_graph_walk()`` with graph objects created one per slave lcore.
+graph using ``rte_graph_walk()`` with graph objects created one per worker lcore.
 
 The lookup method is as per implementation of ``ip4_lookup`` graph node.
 The ID of the output interface for the input packet is the next hop returned by
@@ -265,7 +265,7 @@ headers will be provided run-time using ``rte_node_ip4_route_add()`` and
     Since currently ``ip4_lookup`` and ``ip4_rewrite`` nodes don't support
     lock-less mechanisms(RCU, etc) to add run-time forwarding data like route and
     rewrite data, forwarding data is added before packet processing loop is
-    launched on slave lcore.
+    launched on worker lcore.
 
 .. code-block:: c
 
@@ -297,7 +297,7 @@ Packet Forwarding using Graph Walk
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Now that all the device configurations are done, graph creations are done and
-forwarding data is updated with nodes, slave lcores will be launched with graph
+forwarding data is updated with nodes, worker lcores will be launched with graph
 main loop. Graph main loop is very simple in the sense that it needs to
 continuously call a non-blocking API ``rte_graph_walk()`` with it's lcore
 specific graph object that was already created.
diff --git a/doc/guides/sample_app_ug/l3_forward_power_man.rst b/doc/guides/sample_app_ug/l3_forward_power_man.rst
index 0cc6f2e62e75..f20502c41a37 100644
--- a/doc/guides/sample_app_ug/l3_forward_power_man.rst
+++ b/doc/guides/sample_app_ug/l3_forward_power_man.rst
@@ -441,7 +441,7 @@ The telemetry mode support for ``l3fwd-power`` is a standalone mode, in this mod
 ``l3fwd-power`` does simple l3fwding along with calculating empty polls, full polls,
 and busy percentage for each forwarding core. The aggregation of these
 values of all cores is reported as application level telemetry to metric
-library for every 500ms from the master core.
+library for every 500ms from the initial core.
 
 The busy percentage is calculated by recording the poll_count
 and when the count reaches a defined value the total
diff --git a/doc/guides/sample_app_ug/link_status_intr.rst b/doc/guides/sample_app_ug/link_status_intr.rst
index 04c40f28540d..e31fd2cc7368 100644
--- a/doc/guides/sample_app_ug/link_status_intr.rst
+++ b/doc/guides/sample_app_ug/link_status_intr.rst
@@ -401,9 +401,9 @@ However, it improves performance:
             /* if timer has reached its timeout */
 
             if (unlikely(timer_tsc >= (uint64_t) timer_period)) {
-                /* do this only on master core */
+                /* do this only on initial core */
 
-                if (lcore_id == rte_get_master_lcore()) {
+                if (lcore_id == rte_get_initial_lcore()) {
                     print_stats();
 
                     /* reset the timer */
diff --git a/doc/guides/sample_app_ug/multi_process.rst b/doc/guides/sample_app_ug/multi_process.rst
index f2a79a639763..51b8db5cf75a 100644
--- a/doc/guides/sample_app_ug/multi_process.rst
+++ b/doc/guides/sample_app_ug/multi_process.rst
@@ -66,7 +66,7 @@ The process should start successfully and display a command prompt as follows:
 
     EAL: check igb_uio module
     EAL: check module finished
-    EAL: Master core 0 is ready (tid=54e41820)
+    EAL: Initial core 0 is ready (tid=54e41820)
     EAL: Core 1 is ready (tid=53b32700)
 
     Starting core 1
@@ -92,7 +92,7 @@ At any stage, either process can be terminated using the quit command.
 
 .. code-block:: console
 
-   EAL: Master core 10 is ready (tid=b5f89820)           EAL: Master core 8 is ready (tid=864a3820)
+   EAL: Initial core 10 is ready (tid=b5f89820)           EAL: Initial core 8 is ready (tid=864a3820)
    EAL: Core 11 is ready (tid=84ffe700)                  EAL: Core 9 is ready (tid=85995700)
    Starting core 11                                      Starting core 9
    simple_mp > send hello_secondary                      simple_mp > core 9: Received 'hello_secondary'
@@ -273,7 +273,7 @@ In addition to the EAL parameters, the application- specific parameters are:
 
 .. note::
 
-    In the server process, a single thread, the master thread, that is, the lowest numbered lcore in the coremask/corelist, performs all packet I/O.
+    In the server process, a single thread, the initial thread, that is, the lowest numbered lcore in the coremask/corelist, performs all packet I/O.
     If a coremask/corelist is specified with more than a single lcore bit set in it,
     an additional lcore will be used for a thread to periodically print packet count statistics.
 
diff --git a/doc/guides/sample_app_ug/packet_ordering.rst b/doc/guides/sample_app_ug/packet_ordering.rst
index 1c8ee5d04071..e82938bd7c9c 100644
--- a/doc/guides/sample_app_ug/packet_ordering.rst
+++ b/doc/guides/sample_app_ug/packet_ordering.rst
@@ -12,14 +12,14 @@ Overview
 
 The application uses at least three CPU cores:
 
-* RX core (maser core) receives traffic from the NIC ports and feeds Worker
+* RX core (initial core) receives traffic from the NIC ports and feeds Worker
   cores with traffic through SW queues.
 
-* Worker core (slave core) basically do some light work on the packet.
+* Worker cores basically do some light work on the packet.
   Currently it modifies the output port of the packet for configurations with
   more than one port enabled.
 
-* TX Core (slave core) receives traffic from Worker cores through software queues,
+* TX Core receives traffic from Worker cores through software queues,
   inserts out-of-order packets into reorder buffer, extracts ordered packets
   from the reorder buffer and sends them to the NIC ports for transmission.
 
@@ -46,7 +46,7 @@ The application execution command line is:
     ./packet_ordering [EAL options] -- -p PORTMASK [--disable-reorder] [--insight-worker]
 
 The -c EAL CPU_COREMASK option has to contain at least 3 CPU cores.
-The first CPU core in the core mask is the master core and would be assigned to
+The first CPU core in the core mask is the initial core and would be assigned to
 RX core, the last to TX core and the rest to Worker cores.
 
 The PORTMASK parameter must contain either 1 or even enabled port numbers.
diff --git a/doc/guides/sample_app_ug/performance_thread.rst b/doc/guides/sample_app_ug/performance_thread.rst
index b04d0ba444af..29105f9708eb 100644
--- a/doc/guides/sample_app_ug/performance_thread.rst
+++ b/doc/guides/sample_app_ug/performance_thread.rst
@@ -280,8 +280,8 @@ functionality into different threads, and the pairs of RX and TX threads are
 interconnected via software rings.
 
 On initialization an L-thread scheduler is started on every EAL thread. On all
-but the master EAL thread only a dummy L-thread is initially started.
-The L-thread started on the master EAL thread then spawns other L-threads on
+but the initial EAL thread only a dummy L-thread is initially started.
+The L-thread started on the initial EAL thread then spawns other L-threads on
 different L-thread schedulers according the command line parameters.
 
 The RX threads poll the network interface queues and post received packets
@@ -1217,5 +1217,5 @@ Setting ``LTHREAD_DIAG`` also enables counting of statistics about cache and
 queue usage, and these statistics can be displayed by calling the function
 ``lthread_diag_stats_display()``. This function also performs a consistency
 check on the caches and queues. The function should only be called from the
-master EAL thread after all slave threads have stopped and returned to the C
+initial EAL thread after all worker threads have stopped and returned to the C
 main program, otherwise the consistency check will fail.
diff --git a/doc/guides/sample_app_ug/qos_scheduler.rst b/doc/guides/sample_app_ug/qos_scheduler.rst
index b5010657a7d8..345ecbb5905d 100644
--- a/doc/guides/sample_app_ug/qos_scheduler.rst
+++ b/doc/guides/sample_app_ug/qos_scheduler.rst
@@ -71,7 +71,7 @@ Optional application parameters include:
     In this mode, the application shows a command line that can be used for obtaining statistics while
     scheduling is taking place (see interactive mode below for more information).
 
-*   --mst n: Master core index (the default value is 1).
+*   --mst n: Initial core index (the default value is 1).
 
 *   --rsz "A, B, C": Ring sizes:
 
@@ -329,7 +329,7 @@ Another example with 2 packet flow configurations using different ports but shar
 Note that independent cores for the packet flow configurations for each of the RX, WT and TX thread are also supported,
 providing flexibility to balance the work.
 
-The EAL coremask/corelist is constrained to contain the default mastercore 1 and the RX, WT and TX cores only.
+The EAL coremask/corelist is constrained to contain the default initial lcore 1 and the RX, WT and TX cores only.
 
 Explanation
 -----------
diff --git a/doc/guides/sample_app_ug/timer.rst b/doc/guides/sample_app_ug/timer.rst
index 98d762d2388c..59a8ab11e9b6 100644
--- a/doc/guides/sample_app_ug/timer.rst
+++ b/doc/guides/sample_app_ug/timer.rst
@@ -49,17 +49,18 @@ In addition to EAL initialization, the timer subsystem must be initialized, by c
     rte_timer_subsystem_init();
 
 After timer creation (see the next paragraph),
-the main loop is executed on each slave lcore using the well-known rte_eal_remote_launch() and also on the master.
+the main loop is executed on each worker lcore using the well-known rte_eal_remote_launch() and
+also on the initial lcore.
 
 .. code-block:: c
 
-    /* call lcore_mainloop() on every slave lcore  */
+    /* call lcore_mainloop() on every worker lcore  */
 
-    RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+    RTE_LCORE_FOREACH_WORKER(lcore_id) {
         rte_eal_remote_launch(lcore_mainloop, NULL, lcore_id);
     }
 
-    /* call it on master lcore too */
+    /* call it on initial lcore too */
 
     (void) lcore_mainloop(NULL);
 
@@ -105,7 +106,7 @@ This call to rte_timer_init() is necessary before doing any other operation on t
 
 Then, the two timers are configured:
 
-*   The first timer (timer0) is loaded on the master lcore and expires every second.
+*   The first timer (timer0) is loaded on the initial lcore and expires every second.
     Since the PERIODICAL flag is provided, the timer is reloaded automatically by the timer subsystem.
     The callback function is timer0_cb().
 
@@ -115,7 +116,7 @@ Then, the two timers are configured:
 
 .. code-block:: c
 
-    /* load timer0, every second, on master lcore, reloaded automatically */
+    /* load timer0, every second, on initial lcore, reloaded automatically */
 
     hz = rte_get_hpet_hz();
 
diff --git a/doc/guides/testpmd_app_ug/run_app.rst b/doc/guides/testpmd_app_ug/run_app.rst
index f169604752b8..7d6b81de7f46 100644
--- a/doc/guides/testpmd_app_ug/run_app.rst
+++ b/doc/guides/testpmd_app_ug/run_app.rst
@@ -71,7 +71,7 @@ The command line options are:
 *   ``--coremask=0xXX``
 
     Set the hexadecimal bitmask of the cores running the packet forwarding test.
-    The master lcore is reserved for command line parsing only and cannot be masked on for packet forwarding.
+    The initial lcore is reserved for command line parsing only and cannot be masked on for packet forwarding.
 
 *   ``--portmask=0xXX``
 
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index a808b6a308f2..7d4db1140092 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -692,7 +692,7 @@ This is equivalent to the ``--coremask`` command-line option.
 
 .. note::
 
-   The master lcore is reserved for command line parsing only and cannot be masked on for packet forwarding.
+   The initial lcore is reserved for command line parsing only and cannot be masked on for packet forwarding.
 
 set portmask
 ~~~~~~~~~~~~
-- 
2.26.2