[dpdk-dev] [PATCH 05/15] doc: replace master lcore with main lcore
Burakov, Anatoly
anatoly.burakov at intel.com
Mon Sep 14 16:56:21 CEST 2020
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 <stephen at 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
More information about the dev
mailing list