On 11-Sep-20 8:06 PM, Stephen Hemminger wrote:
Make sure that master lcore is not used in documentation.

Signed-off-by: Stephen Hemminger <step...@networkplumber.org>
---
  doc/guides/faq/faq.rst                               |  2 +-
  doc/guides/linux_gsg/eal_args.include.rst            |  2 +-
  doc/guides/nics/bnxt.rst                             |  2 +-
  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                   | 10 ++++++++--
  doc/guides/sample_app_ug/bbdev_app.rst               |  2 +-
  doc/guides/sample_app_ug/ethtool.rst                 |  2 +-
  doc/guides/sample_app_ug/hello_world.rst             |  2 +-
  doc/guides/sample_app_ug/ioat.rst                    | 10 +++++-----
  doc/guides/sample_app_ug/ip_pipeline.rst             |  2 +-
  doc/guides/sample_app_ug/l2_forward_event.rst        |  2 +-
  doc/guides/sample_app_ug/l2_forward_real_virtual.rst |  2 +-
  doc/guides/sample_app_ug/l3_forward_power_man.rst    |  2 +-
  doc/guides/sample_app_ug/link_status_intr.rst        |  2 +-
  doc/guides/sample_app_ug/multi_process.rst           |  2 +-
  doc/guides/sample_app_ug/packet_ordering.rst         |  2 +-
  doc/guides/sample_app_ug/performance_thread.rst      |  4 ++--
  doc/guides/sample_app_ug/ptpclient.rst               |  2 +-
  doc/guides/sample_app_ug/timer.rst                   |  8 ++++----
  doc/guides/testpmd_app_ug/run_app.rst                |  2 +-
  doc/guides/testpmd_app_ug/testpmd_funcs.rst          |  2 +-
  22 files changed, 39 insertions(+), 33 deletions(-)

Missed a few of updates:

- Coding style guide @ line 342
- Debug/troublshooting guide @ line 315
- Logs in quickstart guide @ lines 235 and 297
- QoS scheduler guide @ lines 74 and 332


diff --git a/doc/guides/faq/faq.rst b/doc/guides/faq/faq.rst
index bb1df7dc8a0f..d517e08a1e1f 100644
--- a/doc/guides/faq/faq.rst
+++ b/doc/guides/faq/faq.rst
@@ -48,7 +48,7 @@ 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.
-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 main 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

Missed instance right above this hunk (line 45), and right below this hunk (line 49).

diff --git a/doc/guides/linux_gsg/eal_args.include.rst 
b/doc/guides/linux_gsg/eal_args.include.rst
index 0fe44579689b..329d4cdfbfb3 100644
--- a/doc/guides/linux_gsg/eal_args.include.rst
+++ b/doc/guides/linux_gsg/eal_args.include.rst
@@ -33,7 +33,7 @@ Lcore-related options
      At a given instance only one core option ``--lcores``, ``-l`` or ``-c`` 
can
      be used.
-* ``--master-lcore <core ID>``
+*   ``--main-lcore <core ID>``
Core ID that is used as master.

Missed updating the comment under the flag.

<snip>

index 46f997a7dce3..3504b744844f 100644
--- a/doc/guides/sample_app_ug/hello_world.rst
+++ b/doc/guides/sample_app_ug/hello_world.rst
@@ -81,7 +81,7 @@ The code that launches the function on each lcore is as 
follows:
         rte_eal_remote_launch(lcore_hello, NULL, lcore_id);
      }
- /* call it on master lcore too */
+    /* call it on main lcore too */
lcore_hello(NULL);

Missed a couple of instances right above this hunk.

<snip>

  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..c497ffc0a6c9 100644
--- a/doc/guides/sample_app_ug/ip_pipeline.rst
+++ b/doc/guides/sample_app_ug/ip_pipeline.rst
@@ -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 main 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.

Missed an instance right above this hunk.

Examples
diff --git a/doc/guides/sample_app_ug/l2_forward_event.rst 
b/doc/guides/sample_app_ug/l2_forward_event.rst
index d536eee819d0..6e2324552f49 100644
--- a/doc/guides/sample_app_ug/l2_forward_event.rst
+++ b/doc/guides/sample_app_ug/l2_forward_event.rst
@@ -631,7 +631,7 @@ 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()) {
+                                if (lcore_id == rte_get_main_lcore()) {

Missed comment above this.

                                          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 c0e8488e7987..06586ed4a822 100644
--- a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
+++ b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
@@ -455,7 +455,7 @@ however it improves performance:
              if (unlikely(timer_tsc >= (uint64_t) timer_period)) {
                  /* do this only on master core */
- if (lcore_id == rte_get_master_lcore()) {
+                if (lcore_id == rte_get_main_lcore()) {

Missed comment above this.

                      print_stats();
/* reset the timer */
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..f05816d9b24e 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 main 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..8ceacc42eb9b 100644
--- a/doc/guides/sample_app_ug/link_status_intr.rst
+++ b/doc/guides/sample_app_ug/link_status_intr.rst
@@ -403,7 +403,7 @@ However, it improves performance:
              if (unlikely(timer_tsc >= (uint64_t) timer_period)) {
                  /* do this only on master core */
- if (lcore_id == rte_get_master_lcore()) {
+                if (lcore_id == rte_get_main_lcore()) {

Missed comment above this.

                      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..c391c549b9b5 100644
--- a/doc/guides/sample_app_ug/multi_process.rst
+++ b/doc/guides/sample_app_ug/multi_process.rst
@@ -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 main 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.

Missed logs in this file @ lines 69 and 95.

diff --git a/doc/guides/sample_app_ug/packet_ordering.rst b/doc/guides/sample_app_ug/packet_ordering.rst
index 1c8ee5d04071..26bed0136a12 100644
--- a/doc/guides/sample_app_ug/packet_ordering.rst
+++ b/doc/guides/sample_app_ug/packet_ordering.rst
@@ -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 main core and would be assigned to
  RX core, the last to TX core and the rest to Worker cores.

Missed lines 18 and 22 in this file.

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..cfc0676e9210 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 main EAL thread only a dummy L-thread is initially started.
+The L-thread started on the main EAL thread then spawns other L-threads on
  different L-thread schedulers according the command line parameters.

Missed instances on line 1220 in this file.

The RX threads poll the network interface queues and post received packets
diff --git a/doc/guides/sample_app_ug/ptpclient.rst 
b/doc/guides/sample_app_ug/ptpclient.rst
index 12b4f13d5bd8..5b51c8526c5a 100644
--- a/doc/guides/sample_app_ug/ptpclient.rst
+++ b/doc/guides/sample_app_ug/ptpclient.rst
@@ -21,7 +21,7 @@ The PTP sample application is intended as a simple reference 
implementation of
  a PTP client using the DPDK IEEE1588 API.
  In order to keep the application simple the following assumptions are made:
-* The first discovered master is the master for the session.
+* The first discovered master is the main for the session.
  * Only L2 PTP packets are supported.
  * Only the PTP v2 protocol is supported.
  * Only the slave clock is implemented.
diff --git a/doc/guides/sample_app_ug/timer.rst 
b/doc/guides/sample_app_ug/timer.rst
index 98d762d2388c..071db764b170 100644
--- a/doc/guides/sample_app_ug/timer.rst
+++ b/doc/guides/sample_app_ug/timer.rst
@@ -49,7 +49,7 @@ 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 slave lcore using the well-known 
rte_eal_remote_launch() and also on the main.

Replaced master but not slave. Also missed a couple of instances below this hunk.

.. code-block:: c @@ -59,7 +59,7 @@ the main loop is executed on each slave lcore using the well-known rte_eal_remot
          rte_eal_remote_launch(lcore_mainloop, NULL, lcore_id);
      }
- /* call it on master lcore too */
+    /* call it on main lcore too */
(void) lcore_mainloop(NULL); @@ -105,7 +105,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 main 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().
--
Thanks,
Anatoly

Reply via email to