docs: cleanup typos on readthrough

Type: style

Change-Id: I3b15035ea6c13cd1ca3cdc9dfa9b10a6e1be9880
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>

docs/gettingstarted/developers/bihash.md

@@ -74,7 +74,7 @@ search across 2**log2_size backing pages on a per-bucket basis.
 
 To maintain *space* efficiency, we should configure the bucket array
 so that backing pages are effectively utilized. Lookup performance
-tends to change *very litte* if the bucket array is too small or too
+tends to change *very little* if the bucket array is too small or too
 large.
 
 Bihash depends on selecting an effective hash function. If one were to

docs/gettingstarted/developers/binary_api_support.rst

@@ -93,7 +93,7 @@ implement a variety of features:
 * Barrier synchronization of worker threads across thread-unsafe message handlers.
 
 Correctly-coded message handlers know nothing about the transport used
-to deliver messages to/from VPP. It's reasonably straighforward to use
+to deliver messages to/from VPP. It's reasonably straightforward to use
 multiple API message transport types simultaneously.
 
 For historical reasons, binary api messages are (putatively) sent in

docs/gettingstarted/developers/building.rst

@@ -164,7 +164,7 @@ Once the packages are built they can be found in the build-root directory.
     vpp-plugins_18.07-rc0~456-gb361076_amd64.deb
 
 Finally, the created packages can be installed using the following commands. Install
-the package that correspnds to OS that VPP will be running on:
+the package that corresponds to OS that VPP will be running on:
 
 For Ubuntu:
 

docs/gettingstarted/developers/buildsystem/buildrootmakefile.rst

@@ -156,7 +156,7 @@ Here are the contents of .../build-data/platforms/vpp.mk:
      
         vpp_uses_dpdk = yes
      
-        # Uncoment to enable building unit tests
+        # Uncomment to enable building unit tests
         # vpp_enable_tests = yes
      
         vpp_root_packages = vpp vom

docs/gettingstarted/developers/fib20/dataplane.rst

@@ -68,7 +68,7 @@ stacking occurs, the necessary VLIB graph arcs are automatically constructed
 from the respected DPO type's registered graph nodes.
 
 The diagrams above show that for any given route the full data-plane graph is
-known before anypacket arrives. If that graph is composed of n objects, then the
+known before any packet arrives. If that graph is composed of n objects, then the
 packet will visit n nodes and thus incur a forwarding cost of approximately n
 times the graph node cost. This could be reduced if the graph were *collapsed*
 into a single DPO and associated node. However, collapsing a graph removes the

docs/gettingstarted/developers/fib20/graphwalks.rst

@@ -15,8 +15,8 @@ child to parent relationship is thus fully known to the child, and hence a forwa
 walk of the graph (from child to parent) is trivial. However, a parent does not choose
 its children, it does not even choose the type. All object types that form part of the
 FIB control plane graph all inherit from a single base class14; *fib_node_t*. A *fib_node_t*
-indentifies the object's index and its associated virtual function table provides the
-parent a mechanism to Զisitՠthat object during the walk. The reason for a back-walk
+identifies the object's index and its associated virtual function table provides the
+parent a mechanism to visit that object during the walk. The reason for a back-walk
 is to inform all children that the state of the parent has changed in some way, and
 that the child may itself need to update.
 
@@ -65,7 +65,7 @@ Choosing between a synchronous and an asynchronous walk is therefore a trade-off
 time it takes to propagate a change in the parent to all of its children, versus the
 time it takes to act on a single route update. For example, if a route update where to
 affect millions of child recursive routes, then the rate at which such updates could be
-processed would be dependent on the number of child recursive route Рwhich would not be
+processed would be dependent on the number of child recursive route which would not be
 good. At the time of writing FIB2.0 uses synchronous walk in all locations except when
 walking the children of a path-list, and it has more than 32 [#f15]_ children. This avoids the
 case mentioned above.

docs/gettingstarted/developers/fib20/routes.rst

@@ -10,19 +10,19 @@ the route is resolved as the graph is complete from *fib_entry_t* to *ip_adjacen
 
 In some routing models a VRF will consist of a set of tables for IPv4 and IPv6, and
 unicast and multicast. In VPP there is no such grouping. Each table is distinct from
-each other. A table is indentified by its numerical ID. The ID range is separate for
+each other. A table is identified by its numerical ID. The ID range is separate for
 each address family.
 
 A table is comprised of two route data-bases; forwarding and non-forwarding. The
 forwarding data-base contains routes against which a packet will perform a longest
 prefix match (LPM) in the data-plane. The non-forwarding DB contains all the routes
-with which VPP has been programmed Рsome of these routes may be unresolved for reasons
+with which VPP has been programmed some of these routes may be unresolved for reasons
 that prevent their insertion into the forwarding DB
 (see section: Adjacency source FIB entries). 
 
 The route data is decomposed into three parts; entry, path-list and paths;
 
-* The *fib_entry_t*, which contains the routeճ prefix, is representation of that prefix's entry in the FIB table.
+* The *fib_entry_t*, which contains the routes prefix, is representation of that prefix's entry in the FIB table.
 * The *fib_path_t* is a description of where to send the packets destined to the route's prefix. There are several types of path.
 
     * Attached next-hop: the path is described with an interface and a next-hop. The next-hop is in the same sub-net as the router's own address on that interface, hence the peer is considered to be *attached*
@@ -37,10 +37,10 @@ The route data is decomposed into three parts; entry, path-list and paths;
 
 .. figure:: /_images/fib20fig2.png
 
-Figure 2: Route data model Рclass diagram
+Figure 2: Route data model class diagram
 
 Figure 2 shows an example of a route with two attached-next-hop paths. Each of these
-paths will *resolve* by finding the adjacency that matches the pathճ attributes, which
+paths will *resolve* by finding the adjacency that matches the paths attributes, which
 are the same as the key for the adjacency data-base [#f3]_. The *forwarding information (FI)*
 is the set of adjacencies that are available for load-balancing the traffic in the
 data-plane. A path *contributes* an adjacency to the route's forwarding information, the
@@ -68,10 +68,10 @@ forwarding information of multiple sources to be combined. Instead the FIB must
 to use the forwarding information from only one source. This choice is based on a static
 priority assignment [#f4]_. The FIB must maintain the information each source has added
 so it can be restored should that source become the best source. VPP has two
-*control-plane* sources; the API and the CLI Рthe API has the higher priority.
+*control-plane* sources; the API and the CLI the API has the higher priority.
 Each *source* data is represented by a *fib_entry_src_t* object of which a
 *fib_entry_t* maintains a sorted vector.n A prefix is *connected* when it is
-applied to a routerճ interface.
+applied to a routers interface.
 
 The following configuration:
 
@@ -84,7 +84,7 @@ attached, and 192.168.1.1/32 which is connected and local (a.k.a receive or for-
 Both prefixes are *interface* sourced. The interface source has a high priority, so
 the accidental or nefarious addition of identical prefixes does not prevent the
 router from correctly forwarding. Packets matching a connected prefix will
-generate an ARP request for the packetճ destination address, this process is known
+generate an ARP request for the packets destination address, this process is known
 as a *glean*. 
 
 An *attached* prefix also results in a glean, but the router does not have its own
@@ -147,7 +147,7 @@ So while the following configuration is accepted:
    $ ip arp 192.168.1.2 GigabitEthernet0/8/0 dead.dead.dead
    $ set interface ip table GigabitEthernet0/8/0 2
 
-it does not result in the desired behaviour, where the adj-fib and connecteds are
+it does not result in the desired behaviour, where the adj-fib and connected adjacencies are
 moved to table 2.
 
 Recursive Routes

docs/gettingstarted/developers/fib20/scale.rst

@@ -93,7 +93,7 @@ IP6 Heap
 The IPv6 heap is used to allocate the memory needed for the
 data-structure within which the IPv6 prefixes are stored. IPv6 also
 has the concept of forwarding and non-forwarding entries, however for
-IPv6 all the forwardind entries are stored in a single hash table
+IPv6 all the forwarding entries are stored in a single hash table
 (same goes for the non-forwarding). The key to the hash table includes
 the IPv6 table-id.
 

docs/gettingstarted/developers/fib20/tunnels.rst

@@ -23,7 +23,7 @@ graph/chain rather than its usual terminal location.
 
 The mid-chain adjacency is contributed by the gre_tunnel_t , which also becomes
 part of the FIB control-plane graph. Consequently it will be visited by a
-back-walk when the forwarding information for the tunnelճ destination changes.
+back-walk when the forwarding information for the tunnel's destination changes.
 This will trigger it to restack the mid-chain adjacency on the new
 *load_balance_t* contributed by the parent *fib_entry_t*.
 

docs/gettingstarted/developers/gdb_examples.rst

@@ -32,7 +32,7 @@ or abort signal, then you can run the VPP debug binary and then execute **backtr
     (gdb) bt
     #0  ip4_icmp_input (vm=0x7ffff7b89a40 <vlib_global_main>, node=0x7fffb6bb6900, frame=0x7fffb6725ac0) at /scratch/vpp-master/build-data/../src/vnet/ip/icmp4.c:187
     #1  0x00007ffff78da4be in dispatch_node (vm=0x7ffff7b89a40 <vlib_global_main>, node=0x7fffb6bb    6900, type=VLIB_NODE_TYPE_INTERNAL, dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffb6725ac0, last_time_stamp=10581236529    65565) at /scratch/vpp-master/build-data/../src/vlib/main.c:988
-    #2  0x00007ffff78daa77 in dispatch_pending_node (vm=0x7ffff7b89a40 <vlib_global_main>, pending_f    rame_index=6, last_time_stamp=1058123652965565) at /scratch/vpp-master/build-data/../src/vlib/main.c:1138
+    #2  0x00007ffff78daa77 in dispatch_pending_node (vm=0x7ffff7b89a40 <vlib_global_main>, pending_frame_index=6, last_time_stamp=1058123652965565) at /scratch/vpp-master/build-data/../src/vlib/main.c:1138
     ....
 
 Get to the GDB prompt

docs/gettingstarted/developers/infrastructure.md

@@ -161,7 +161,7 @@ format specification. For example:
 
 format\_junk() can invoke other user-format functions if desired. The
 programmer shoulders responsibility for argument type-checking. It is
-typical for user format functions to blow up spectaculary if the
+typical for user format functions to blow up spectacularly if the
 va\_arg(va, type) macros don't match the caller's idea of reality.
 
 Unformat

docs/gettingstarted/developers/metadata.md

@@ -31,7 +31,7 @@ the pre-data (rewrite space) area.
     * VNET_BUFFER_F_L4_CHECKSUM_COMPUTED: tcp/udp checksum has been computed
     * VNET_BUFFER_F_L4_CHECKSUM_CORRECT: tcp/udp checksum is correct
     * VNET_BUFFER_F_VLAN_2_DEEP: two vlan tags present
-    * VNET_BUFFER_F_VLAN_1_DEEP: one vlag tag present
+    * VNET_BUFFER_F_VLAN_1_DEEP: one vlan tag present
     * VNET_BUFFER_F_SPAN_CLONE: packet has already been cloned (span feature)
     * VNET_BUFFER_F_LOOP_COUNTER_VALID: packet look-up loop count valid
     * VNET_BUFFER_F_LOCALLY_ORIGINATED: packet built by vpp
@@ -48,13 +48,13 @@ the pre-data (rewrite space) area.
     * VNET_BUFFER_F_IS_DVR: packet to be reinjected into the l2 output path
     * VNET_BUFFER_F_QOS_DATA_VALID: QoS data valid in vnet_buffer_opaque2
     * VNET_BUFFER_F_GSO: generic segmentation offload requested
-    * VNET_BUFFER_F_AVAIL1: avaliable bit
-    * VNET_BUFFER_F_AVAIL2: avaliable bit
-    * VNET_BUFFER_F_AVAIL3: avaliable bit
-    * VNET_BUFFER_F_AVAIL4: avaliable bit
-    * VNET_BUFFER_F_AVAIL5: avaliable bit
-    * VNET_BUFFER_F_AVAIL6: avaliable bit
-    * VNET_BUFFER_F_AVAIL7: avaliable bit
+    * VNET_BUFFER_F_AVAIL1: available bit
+    * VNET_BUFFER_F_AVAIL2: available bit
+    * VNET_BUFFER_F_AVAIL3: available bit
+    * VNET_BUFFER_F_AVAIL4: available bit
+    * VNET_BUFFER_F_AVAIL5: available bit
+    * VNET_BUFFER_F_AVAIL6: available bit
+    * VNET_BUFFER_F_AVAIL7: available bit
 * u32 flow_id: generic flow identifier
 * u8 ref_count: buffer reference / clone count (e.g. for span replication)
 * u8 buffer_pool_index: buffer pool index which owns this buffer

docs/gettingstarted/developers/multiarch/index.rst

@@ -3,7 +3,7 @@
 Multi-architecture support
 ==========================
 
-This reference guide describes how to use the vpp muli-architecture support scheme
+This reference guide describes how to use the vpp multi-architecture support scheme
 
 .. toctree::
    :maxdepth: 1

docs/gettingstarted/developers/vnet.md

@@ -325,7 +325,7 @@ these data to easily filter/track single packets as they traverse the
 forwarding graph.
 
 Multiple records per packet are normal, and to be expected. Packets
-will appear multipe times as they traverse the vpp forwarding
+will appear multiple times as they traverse the vpp forwarding
 graph. In this way, vpp graph dispatch traces are significantly
 different from regular network packet captures from an end-station.
 This property complicates stateful packet analysis.
@@ -494,7 +494,7 @@ These commands have the following optional parameters:
   capture is off.
 
 - <b>max-bytes-per-pkt _nnnn_</b> - maximum number of bytes to trace
-  on a per-paket basis. Must be >32 and less than 9000. Default value:
+  on a per-packet basis. Must be >32 and less than 9000. Default value:
   512.
 
 - <b>filter</b> - Use the pcap rx / tx / drop trace filter, which must
@@ -529,7 +529,7 @@ These commands have the following optional parameters:
 The "classify filter pcap | <interface-name> " debug CLI command
 constructs an arbitrary set of packet classifier tables for use with
 "pcap rx | tx | drop trace," and with the vpp packet tracer on a
-per-interrface basis.
+per-interface basis.
 
 Packets which match a rule in the classifier table chain will be
 traced. The tables are automatically ordered so that matches in the
@@ -538,7 +538,7 @@ most specific table are tried first.
 It's reasonably likely that folks will configure a single table with
 one or two matches. As a result, we configure 8 hash buckets and 128K
 of match rule space by default. One can override the defaults by
-specifiying "buckets <nnn>" and "memory-size <xxx>" as desired.
+specifying "buckets <nnn>" and "memory-size <xxx>" as desired.
 
 To build up complex filter chains, repeatedly issue the classify
 filter debug CLI command. Each command must specify the desired mask

docs/gettingstarted/developers/vpp_api_module.rst

@@ -56,7 +56,7 @@ _______
 
 **Low-level API**
 
-Refer to inline API documentation in doxygen format in vapi.h header for description of functions. It's recommened to use the safer, high-level API provided by specialized headers (e.g. vpe.api.vapi.h or vpe.api.vapi.hpp).
+Refer to inline API documentation in doxygen format in vapi.h header for description of functions. It's recommended to use the safer, high-level API provided by specialized headers (e.g. vpe.api.vapi.h or vpe.api.vapi.hpp).
 
 **C high-level API**
 
@@ -113,7 +113,7 @@ _________
 
 *Create a Connection and execute the appropriate Request to subscribe to events (e.g. Want_stats)*
 
-#. Create an Event_registration with a template argument being the type of event you are insterested in.
+#. Create an Event_registration with a template argument being the type of event you are interested in.
 #. Call dispatch() or wait_for_response() to wait for the event. A callback will be called when an event occurs (if passed to Event_registration() constructor). Alternatively, read the result set.
 
 .. note::