docs: cleanup typos on readthrough

Type: style

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

docs/featuresbyrelease/vpp1908.md

@@ -10,7 +10,7 @@
   - 19.05 integration
   - Remove bonding code
   - Rework extended stats
-- Debugging & Servicability
+- Debugging & Serviceability
   - debug CLI leak-checker
   - vlib: add "memory-trace stats-segment"
   - vppapitrace JSON/API trace converter
@@ -130,7 +130,7 @@
   - support quic streams and "connectable listeners"
   - worker unregister api
   - fix epoll with large events batch
-  - ldp: add option to eanble transparent TLS connections
+  - ldp: add option to enable transparent TLS connections
 - udp:
   - support close with data
   - fixed session migration

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
+identifies 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
+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_AVAIL1: available bit
-    * VNET_BUFFER_F_AVAIL2: avaliable bit
+    * VNET_BUFFER_F_AVAIL2: available bit
-    * VNET_BUFFER_F_AVAIL3: avaliable bit
+    * VNET_BUFFER_F_AVAIL3: available bit
-    * VNET_BUFFER_F_AVAIL4: avaliable bit
+    * VNET_BUFFER_F_AVAIL4: available bit
-    * VNET_BUFFER_F_AVAIL5: avaliable bit
+    * VNET_BUFFER_F_AVAIL5: available bit
-    * VNET_BUFFER_F_AVAIL6: avaliable bit
+    * VNET_BUFFER_F_AVAIL6: available bit
-    * VNET_BUFFER_F_AVAIL7: avaliable 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::

docs/gettingstarted/progressivevpp/index.rst

@@ -7,7 +7,7 @@ Progressive VPP Tutorial
 ########################
 
 Learn to run FD.io VPP on a single Ubuntu 16.04 VM using Vagrant with this walkthrough
-covering basic FD.io VPP senarios. Useful FD.io VPP commands will be used, and
+covering basic FD.io VPP scenarios. Useful FD.io VPP commands will be used, and
 will discuss basic operations, and the state of a running FD.io VPP on a system.
 
 .. note::

docs/gettingstarted/progressivevpp/switching.rst

@@ -9,7 +9,7 @@ Skills to be Learned
 ----------------------
 
 #. Associate an interface with a bridge domain
-#. Create a loopback interaface
+#. Create a loopback interface
 #. Create a BVI (Bridge Virtual Interface) for a bridge domain
 #. Examine a bridge domain
 
@@ -46,7 +46,7 @@ To clear existing config from previous exercises run:
 
    $ ps -ef | grep vpp | awk '{print $2}'| xargs sudo kill
    $ sudo ip link del dev vpp1host
-   $ # do the next command if you are cleaing up from this example
+   $ # do the next command if you are cleaning up from this example
    $ sudo ip link del dev vpp1vpp2
 
 Run FD.io VPP instances

docs/gettingstarted/progressivevpp/twovppinstances.rst

@@ -83,7 +83,7 @@ socket **/run/vpp/cli-vpp1.sock**
    vpp# create interface memif id 0 master
 
 This will create an interface on vpp1 memif0/0 using /run/vpp/memif as
-its socket file. The role of vpp1 for this memif inteface is 'master'.
+its socket file. The role of vpp1 for this memif interface is 'master'.
 
 With what you have learned:
 
@@ -104,7 +104,7 @@ run/vpp/memif-vpp1vpp2 socket file
    vpp# create interface memif id 0 slave
 
 This will create an interface on vpp2 memif0/0 using /run/vpp/memif as
-its socket file. The role of vpp1 for this memif inteface is 'slave'.
+its socket file. The role of vpp1 for this memif interface is 'slave'.
 
 Use your previously used skills to:
 

docs/gettingstarted/users/configuring/hugepages.rst

@@ -24,7 +24,7 @@ the hugepage settings, perform the following commands:
     # All groups allowed to access hugepages
     vm.hugetlb_shm_group=0
     
-    # Shared Memory Max must be greator or equal to the total size of hugepages.
+    # Shared Memory Max must be greater or equal to the total size of hugepages.
     # For 2MB pages, TotalHugepageSize = vm.nr_hugepages * 2 * 1024 * 1024
     # If the existing kernel.shmmax setting  (cat /sys/proc/kernel/shmmax)
     # is greater than the calculated TotalHugepageSize then set this parameter

docs/gettingstarted/users/configuring/startup.rst

@@ -244,7 +244,7 @@ attributes.
      **Example:** cli-prompt vpp-2
      
  * **cli-history-limit <n>**
-     Limit commmand history to <n> lines. A value of 0 disables command history.
+     Limit command history to <n> lines. A value of 0 disables command history.
      Default value: 50
      
      **Example:** cli-history-limit 100
@@ -336,7 +336,7 @@ Popular options include:
           for all NICs except VICs, using ENIC driver, which has VLAN stripping on
           by default.
       * **hqos**
-          Enable the Hierarchical Quaity-of-Service (HQoS) scheduler, default is
+          Enable the Hierarchical Quality-of-Service (HQoS) scheduler, default is
           disabled. This enables HQoS on specific output interface.
       * **hqos { .. }**
           HQoS can also have its own set of custom parameters. Setting a custom
@@ -413,7 +413,7 @@ Popular options include:
      **Example:** enable-tcp-udp-checksum
 
  * **no-multi-seg**
-     Disable mutli-segment buffers, improves performance but disables Jumbo MTU
+     Disable multi-segment buffers, improves performance but disables Jumbo MTU
      support.
      
      **Example:** no-multi-seg
@@ -435,7 +435,7 @@ Popular options include:
      **Example:** log-level error
 
  * **dev default { .. }**
-     Change default settings for all intefaces. This sections supports the
+     Change default settings for all interfaces. This sections supports the
      same set of custom parameters described in *'dev <pci-dev> { .. }*'.
      
      **Example:**
@@ -1216,8 +1216,8 @@ ____________________
 
 A plugin can be disabled by default. It may still be in an experimental phase
 or only be needed in special circumstances. If this is the case, the plugin can
-be explicitely enabled in *'startup.conf'*. Also, a plugin that is enabled by
+be explicitly enabled in *'startup.conf'*. Also, a plugin that is enabled by
-default can be explicitely disabled in *'startup.conf'*.
+default can be explicitly disabled in *'startup.conf'*.
 
 Another useful use of this section is to disable all the plugins, then enable
 only the plugins that are desired.

docs/gettingstarted/users/configutil/sysinfo.rst

@@ -11,15 +11,15 @@ Threads
 -------
 
 It usually is not needed, but VPP can be configured to run on isolated CPUs. In the example shown
-VPP is configured with 2 workers. The main thread is also configured to run on a seperate CPU. The
+VPP is configured with 2 workers. The main thread is also configured to run on a separate CPU. The
-stats thread will always run on CPU 0. This utilty will put the worker threads on CPUs that are
+stats thread will always run on CPU 0. This utility will put the worker threads on CPUs that are
 associated with the ports that are configured.
 
 Grub Command Line
 -----------------
 
 In general the Grub command line does not need to be changed. If the system is running many processes
-it may be neccessary to isolate CPUs for VPP or other processes.
+it may be necessary to isolate CPUs for VPP or other processes.
 
 Huge Pages
 ----------

docs/gettingstarted/writingdocs/styleguide/index.rst

@@ -10,7 +10,7 @@ the Sphinx Markup Constructs used in these documents. The Sphinx style guide can
 For a more detailed list of Sphinx Markup Constructs please refer to:
 `Sphinx Markup Constructs <http://www.sphinx-doc.org/en/stable/markup/index.html>`_
 
-This document is also an example of a directory structure for a document that spans mutliple pages.
+This document is also an example of a directory structure for a document that spans multiple pages.
 Notice we have the file **index.rst** and the then documents that are referenced in index.rst. The
 referenced documents are shown at the bottom of this page.
 

docs/gettingstarted/writingdocs/styleguide/styleguide02.rst

@@ -16,7 +16,7 @@ Bold text can be show with **Bold Text**, Italics with *Italic text*. Bullets li
 Notes
 *****
 
-A note can be used to describe something not in the normal flow of the paragragh. This
+A note can be used to describe something not in the normal flow of the paragraph. This
 is an example of a note.
 
 .. note::
@@ -28,7 +28,7 @@ is an example of a note.
 Code Blocks
 ***********
 
-This paragraph describes how to do **Console Commands**. When showing VPP commands it is reccomended
+This paragraph describes how to do **Console Commands**. When showing VPP commands it is recommended
 that the command be executed from the linux console as shown. The Highlighting in the final documents
 shows up nicely this way.
 

docs/gettingstarted/writingdocs/styleguide/styleguide04.rst

@@ -4,7 +4,7 @@
 Including a file
 ****************
 
-A complete file should be included with the following construct. It is recomended it be included with
+A complete file should be included with the following construct. It is recommended it be included with
 it's own .rst file describing the file included. This is an example of an xml file is included.
 
 .. toctree::

docs/gettingstarted/writingdocs/styleguidemd/styleguide02.md

@@ -11,7 +11,7 @@ Code Blocks
 ===========
 
 This paragraph describes how to do **Console Commands**. When showing
-VPP commands it is reccomended that the command be executed from the
+VPP commands it is recommended that the command be executed from the
 linux console as shown. The Highlighting in the final documents shows up
 nicely this way.
 

docs/overview/features/l2.rst

@@ -12,7 +12,7 @@ MAC Layer
 
 Discovery
 ---------
-* Cisco Discovery Protocol
+* Cisco Discovery Protocol v2 (CDP)
 * Link Layer Discovery Protocol (LLDP)
 
 Link Layer Control Protocol

docs/overview/performance/index.rst

@@ -27,7 +27,7 @@ These features have been designed to take full advantage of common micro-process
 * Reducing cache and TLS misses by processing packets in vectors
 * Realizing `IPC <https://en.wikipedia.org/wiki/Instructions_per_cycle>`_ gains with vector instructions such as: SSE, AVX and NEON
 * Eliminating mode switching, context switches and blocking, to always be doing useful work
-* Cache-lined aliged buffers for cache and memory efficiency
+* Cache-lined aligned buffers for cache and memory efficiency
 
 
 Packet Throughput Graphs

docs/overview/whatisvpp/dataplane.rst

@@ -16,10 +16,10 @@ This section identifies different components of packet processing and describes
 
   * Wide support for standard Operating System Interfaces such as AF_Packet, Tun/Tap & Netmap.
 
-* Wide network and cryptograhic hardware support with `DPDK <https://www.dpdk.org/>`_.
+* Wide network and cryptographic hardware support with `DPDK <https://www.dpdk.org/>`_.
 * Container and Virtualization support
 
-  * Para-virtualized intefaces; Vhost and Virtio 
+  * Para-virtualized interfaces; Vhost and Virtio
   * Network Adapters over PCI passthrough
   * Native container interfaces; MemIF
   

docs/overview/whatisvpp/developer.rst

@@ -14,7 +14,7 @@ This section describes the different ways VPP is friendly to developers:
 
   * Runs as a standard user-space process for fault tolerance, software crashes seldom require more than a process restart. 
   * Improved fault-tolerance and upgradability when compared to running similar packet processing in the kernel, software updates never require system reboots. 
-  * Development expierence is easier compared to similar kernel code 
+  * Development experience is easier compared to similar kernel code
   * Hardware isolation and protection (`iommu <https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit>`_)
 
 * Built for security