[PATCH v5 37/54] doc: correct grammar in multi-process guide

[Stephen Hemminger <stephen@networkplumber.org>]

Correct various grammar and style issues in the multi-process support
documentation:

- remove spurious spaces in hyphenated words (pre-initialized,
  Multi-process, side-by-side)
- add missing article "the" before "same DPDK version"
- fix subject-verb agreement in multiple places
- correct book title from "Application's" to "Applications"
- remove duplicate word "process" in startup description
- fix typo "pass long" to "pass along"
- add missing past participle "triggered"
- expand abbreviation "Misc" to "Miscellaneous"

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 doc/guides/prog_guide/multi_proc_support.rst | 28 ++++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index a73918a5da..722506e385 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -17,7 +17,7 @@ For now, there are two types of process specified:
 *   primary processes, which can initialize and which have full permissions on shared memory
 
 *   secondary processes, which cannot initialize shared memory,
-    but can attach to pre- initialized shared memory and create objects in it.
+    but can attach to pre-initialized shared memory and create objects in it.
 
 Standalone DPDK processes are primary processes,
 while secondary processes can only run alongside a primary process or
@@ -25,9 +25,9 @@ after a primary process has already configured the hugepage shared memory for th
 
 .. note::
 
-    Secondary processes should run alongside primary process with same DPDK version.
+    Secondary processes should run alongside primary process with the same DPDK version.
 
-    Secondary processes which requires access to physical devices in Primary process, must
+    Secondary processes which require access to physical devices in Primary process, must
     be passed with the same allow and block options.
 
 To support these two process types, and other multi-process setups described later,
@@ -38,8 +38,8 @@ two additional command-line parameters are available to the EAL:
 *   ``--file-prefix:`` to allow processes that do not want to co-operate to have different memory regions
 
 A number of example applications are provided that demonstrate how multiple DPDK processes can be used together.
-These are more fully documented in the "Multi- process Sample Application" chapter
-in the *DPDK Sample Application's User Guide*.
+These are more fully documented in the "Multi-process Sample Application" chapter
+in the *DPDK Sample Applications User Guide*.
 
 Memory Sharing
 --------------
@@ -47,7 +47,7 @@ Memory Sharing
 The key element in getting a multi-process application working using the DPDK is to ensure that
 memory resources are properly shared among the processes making up the multi-process application.
 Once there are blocks of shared memory available that can be accessed by multiple processes,
-then issues such as inter-process communication (IPC) becomes much simpler.
+then issues such as inter-process communication (IPC) become much simpler.
 
 On application start-up in a primary or standalone process,
 the DPDK records to memory-mapped files the details of the memory configuration it is using - hugepages in use,
@@ -88,7 +88,7 @@ In this model, the first of the processes spawned should be spawned using the ``
 while all subsequent instances should be spawned using the ``--proc-type=secondary`` flag.
 
 The simple_mp and symmetric_mp sample applications demonstrate this usage model.
-They are described in the "Multi-process Sample Application" chapter in the *DPDK Sample Application's User Guide*.
+They are described in the "Multi-process Sample Application" chapter in the *DPDK Sample Applications User Guide*.
 
 Asymmetric/Non-Peer Processes
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -99,7 +99,7 @@ server distributing received packets among worker or client threads, which are r
 In this case, extensive use of rte_ring objects is made, which are located in shared hugepage memory.
 
 The client_server_mp sample application shows this usage model.
-It is described in the "Multi-process Sample Application" chapter in the *DPDK Sample Application's User Guide*.
+It is described in the "Multi-process Sample Application" chapter in the *DPDK Sample Applications User Guide*.
 
 Running Multiple Independent DPDK Applications
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -138,7 +138,7 @@ can use).
 Running Multiple Independent Groups of DPDK Applications
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-In the same way that it is possible to run independent DPDK applications side- by-side on a single system,
+In the same way that it is possible to run independent DPDK applications side-by-side on a single system,
 this can be trivially extended to multi-process groups of DPDK applications running side-by-side.
 In this case, the secondary processes must use the same ``--file-prefix`` parameter
 as the primary process whose shared memory they are connecting to.
@@ -155,7 +155,7 @@ There are a number of limitations to what can be done when running DPDK multi-pr
 Some of these are documented below:
 
 *   The multi-process feature requires that the exact same hugepage memory mappings be present in all applications.
-    This makes secondary process startup process generally unreliable. Disabling
+    This makes secondary process startup generally unreliable. Disabling
     Linux security feature - Address-Space Layout Randomization (ASLR) may
     help getting more consistent mappings, but not necessarily more reliable -
     if the mappings are wrong, they will be consistently wrong!
@@ -247,7 +247,7 @@ of fields to be populated are as follows:
 * ``name`` - message name. This name must match receivers' callback name.
 * ``param`` - message data (up to 256 bytes).
 * ``len_param`` - length of message data.
-* ``fds`` - file descriptors to pass long with the data (up to 8 fd's).
+* ``fds`` - file descriptors to pass along with the data (up to 8 fd's).
 * ``num_fds`` - number of file descriptors to send.
 
 Once the structure is populated, calling ``rte_mp_sendmsg()`` will send the
@@ -301,7 +301,7 @@ Receiving and responding to messages
 To receive a message, a name callback must be registered using the
 ``rte_mp_action_register()`` function. The name of the callback must match the
 ``name`` field in sender's ``rte_mp_msg`` message descriptor in order for this
-message to be delivered and for the callback to be trigger.
+message to be delivered and for the callback to be triggered.
 
 The callback's definition is ``rte_mp_t``, and consists of the incoming message
 pointer ``msg``, and an opaque pointer ``peer``. Contents of ``msg`` will be
@@ -318,8 +318,8 @@ pointer. The resulting response will then be delivered to the correct requestor.
     there is no built-in way to indicate success or error for a request. Failing
     to do so will cause the requestor to time out while waiting on a response.
 
-Misc considerations
-~~~~~~~~~~~~~~~~~~~~~~~~
+Miscellaneous considerations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Due to the underlying IPC implementation being single-threaded, recursive
 requests (i.e. sending a request while responding to another request) is not
-- 
2.51.0