Clean up some minor spelling and typos.

Signed-off-by: Justin Pettit <jpettit@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>

Documentation/howto/docker.rst

@@ -43,7 +43,7 @@ Setup
 -----
 
 For multi-host networking with OVN and Docker, Docker has to be started with a
-destributed key-value store. For example, if you decide to use consul as your
+distributed key-value store. For example, if you decide to use consul as your
 distributed key-value store and your host IP address is ``$HOST_IP``, start
 your Docker daemon with::
 
@@ -120,7 +120,7 @@ The "overlay" mode
      The options are ``geneve`` or ``stt``. Your kernel must have support for
      your chosen ``$ENCAP_TYPE``. Both ``geneve`` and ``stt`` are part of the
      Open vSwitch kernel module that is compiled from this repo. If you use the
-     Open vSwitch kernel module from upstream Linux, you will need a minumum
+     Open vSwitch kernel module from upstream Linux, you will need a minimum
      kernel version of 3.18 for ``geneve``. There is no ``stt`` support in
      upstream Linux. You can verify whether you have the support in your kernel
      as follows::
@@ -322,5 +322,5 @@ The "underlay" mode
 From here-on you can use the same Docker commands as described in
 `docker-overlay`_.
 
-Refer the the ovs-architecture man pages (``man ovn-architecture``) to
+Refer to the ovs-architecture man pages (``man ovn-architecture``) to
 understand OVN's architecture in detail.

Documentation/howto/dpdk.rst

@@ -337,10 +337,10 @@ performance of non-tunnel traffic, specifically for smaller size packet.
 Extended & Custom Statistics
 ----------------------------
 
-DPDK Extended Statistics API allows PMD to expose unique set of statistics.
-The Extended statistics are implemented and supported only for DPDK physical
-and vHost ports. Custom statistics are dynamic set of counters which can
-vary depenend on a driver. Those statistics are implemented
+DPDK Extended Statistics API allows PMD to expose a unique set of statistics.
+The Extended Statistics are implemented and supported only for DPDK physical
+and vHost ports. Custom statistics are a dynamic set of counters which can
+vary depending on the driver. Those statistics are implemented
 for DPDK physical ports and contain all "dropped", "error" and "management"
 counters from XSTATS. XSTATS counters list can be found here:
 <https://wiki.opnfv.org/display/fastpath/Collectd+Metrics+and+Events>`__.
@@ -508,7 +508,7 @@ Add a userspace bridge and two ``dpdk`` (PHY) ports::
     $ ovs-vsctl add-port br0 phy1 -- set Interface phy1 type=dpdk
           options:dpdk-devargs=0000:01:00.1 ofport_request=2
 
-Add test flows to forward packets betwen DPDK port 0 and port 1::
+Add test flows to forward packets between DPDK port 0 and port 1::
 
     # Clear current flows
     $ ovs-ofctl del-flows br0
@@ -543,7 +543,7 @@ ports::
     $ ovs-vsctl add-port br0 dpdkvhostuser1 \
         -- set Interface dpdkvhostuser1 type=dpdkvhostuser ofport_request=4
 
-Add test flows to forward packets betwen DPDK devices and VM ports::
+Add test flows to forward packets between DPDK devices and VM ports::
 
     # Clear current flows
     $ ovs-ofctl del-flows br0

Documentation/howto/firewalld.rst

@@ -77,7 +77,7 @@ Variations
 
 When installing the XML service files, you have the choice of copying them to
 ``/etc/firewalld/services`` or ``/usr/lib/firewalld/services``. The former is
-recommened since the latter can be overwritten if firewalld is upgraded.
+recommend since the latter can be overwritten if firewalld is upgraded.
 
 The above commands assumed your underlay network interfaces are in the
 "public" firewalld zone. If your underlay network interfaces are in a separate

Documentation/howto/lisp.rst

@@ -57,7 +57,7 @@ VMs), or have the hypervisor do proxy ARP.  In this scenario, the eth0
 interfaces need not be added to the br0 bridge in the examples below.
 
 On the receiving side, the packet arrives without the original MAC header.  The
-LISP tunneling code attaches a header with harcoded source and destination MAC
+LISP tunneling code attaches a header with hard-coded source and destination MAC
 address ``02:00:00:00:00:00``.  This address has all bits set to 0, except the
 locally administered bit, in order to avoid potential collisions with existing
 allocations.  In order for packets to reach their intended destination, the

Documentation/howto/userspace-tunneling.rst

@@ -80,7 +80,7 @@ should be running before proceeding.
 Configuration Steps
 -------------------
 
-Perform the folowing configuration on `host1`:
+Perform the following configuration on `host1`:
 
 #. Create a ``br-int`` bridge::
 

Documentation/internals/committer-responsibilities.rst

@@ -28,7 +28,7 @@ Expectations for Developers with Open vSwitch Repo Access
 Pre-requisites
 --------------
 
-Be familar with the guidlines and standards defined in
+Be familiar with the guidelines and standards defined in
 :doc:`contributing/index`.
 
 Review

Documentation/internals/contributing/backporting-patches.rst

@@ -83,7 +83,7 @@ patch, for example:
 
 If a maintainer is backporting a change to older branches and the backport is
 not a trivial cherry-pick, then the maintainer may opt to submit the backport
-for the older branch on the mailinglist for further review. This should be done
+for the older branch on the mailing list for further review. This should be done
 in the same manner as described above.
 
 Changes to Linux kernel components

Documentation/internals/contributing/coding-style-windows.rst

@@ -25,14 +25,14 @@
 Open vSwitch Windows Datapath Coding Style
 ==========================================
 
-The :doc:`coding style <coding-style>` guide gives the flexiblity for each
+The :doc:`coding style <coding-style>` guide gives the flexibility for each
 platform to use its own coding style for the kernel datapath.  This file
 describes the specific coding style used in most of the C files in the Windows
 kernel datapath of the Open vSwitch distribution.
 
 Most of the coding conventions applicable for the Open vSwitch distribution are
 applicable to the Windows kernel datapath as well.  There are some exceptions
-and new guidlines owing to the commonly followed practices in Windows
+and new guidelines owing to the commonly followed practices in Windows
 kernel/driver code.  They are noted as follows:
 
 Basics
@@ -61,7 +61,7 @@ Naming
 
 It is common practice to use camel casing for naming variables, functions and
 files in Windows.  For types, especially structures, unions and enums, using
-all upper case letters with words seprated by '_' is common. These practices
+all upper case letters with words separated by '_' is common. These practices
 can be used for OVS Windows datapath.  However, use the following guidelines:
 
 - Use lower case to begin the name of a variable.
@@ -119,7 +119,7 @@ Comments
 --------
 
 Comments should be written as full sentences that start with a capital letter
-and end with a period.  Putting two spaces between sentances is not necessary.
+and end with a period.  Putting two spaces between sentences is not necessary.
 
 ``//`` can be used for comments as long as the comment is a single line
 comment.  For block comments, use ``/* */`` comments

Documentation/internals/contributing/documentation-style.rst

@@ -411,7 +411,7 @@ vSwitch documentation. These guidelines are based on the `IBM Style Guide
      * - To create a bridge, the user runs:
        - To create a bridge, run:
 
-- Keep sentences short and consise
+- Keep sentences short and concise
 
 - Eliminate needless politeness
 

Documentation/internals/contributing/submitting-patches.rst

@@ -95,7 +95,7 @@ Where:
 
 ``<summary>``:
 
-  briefly describes the change.  Use the the imperative form,
+  briefly describes the change.  Use the imperative form,
   e.g. "Force SNAT for multiple gateway routers." or "Fix daemon exit
   for bad datapaths or flows."  Try to keep the summary short, about
   50 characters wide.
@@ -318,7 +318,7 @@ Developer's Certificate of Origin
 
 To help track the author of a patch as well as the submission chain, and be
 clear that the developer has authority to submit a patch for inclusion in
-openvswitch please sign off your work.  The sign off certifies the following:
+Open vSwitch please sign off your work.  The sign off certifies the following:
 
 ::
 
@@ -411,9 +411,9 @@ file describes the coding style used in most of Open vSwitch. Use Linux kernel
 coding style for Linux kernel code.
 
 If your code is non-datapath code, you may use the ``utilities/checkpatch.py``
-utility as a quick check for certain commonly occuring mistakes (improper
+utility as a quick check for certain commonly occurring mistakes (improper
 leading/trailing whitespace, missing signoffs, some improper formatted patch
-files).  For linux datapath code, it is a good idea to use the linux script
+files).  For Linux datapath code, it is a good idea to use the Linux script
 ``checkpatch.pl``.
 
 Example

Documentation/intro/install/debian.rst

@@ -61,7 +61,7 @@ You do not need to be the superuser to build the Debian packages.
    ``debian/control``. You can install these any way you like, e.g.  with
    ``apt-get install``.
 
-Check your work by running ``dpkg-checkbuilddeps`` in the top level of your ovs
+Check your work by running ``dpkg-checkbuilddeps`` in the top level of your OVS
 directory. If you've installed all the dependencies properly,
 ``dpkg-checkbuilddeps`` will exit without printing anything. If you forgot to
 install some dependencies, it will tell you which ones.

Documentation/intro/install/dpdk.rst

@@ -395,7 +395,7 @@ Compiler Optimizations
 
 The default compiler optimization level is ``-O2``. Changing this to more
 aggressive compiler optimization such as ``-O3 -march=native`` with
-gcc (verified on 5.3.1) can produce performance gains though not siginificant.
+gcc (verified on 5.3.1) can produce performance gains though not significant.
 ``-march=native`` will produce optimized code on local machine and should be
 used when software compilation is done on Testbed.
 

Documentation/intro/install/general.rst

@@ -337,7 +337,7 @@ modules for more than one Linux version. For example::
     $ mkdir _gcc && (cd _gcc && ./configure CC=gcc)
     $ mkdir _clang && (cd _clang && ./configure CC=clang)
 
-Under certains loads the ovsdb-server and other components perform better when
+Under certain loads the ovsdb-server and other components perform better when
 using the jemalloc memory allocator, instead of the glibc memory allocator. If
 you wish to link with jemalloc add it to LIBS::
 

Documentation/intro/install/netbsd.rst

@@ -54,7 +54,7 @@ NetBSD's ``/usr/bin/make`` is not GNU make.  GNU make is installed as
 ``/usr/pkg/bin/gmake`` by the above mentioned ``gmake`` package.
 
 As all executables installed with pkgsrc are placed in ``/usr/pkg/bin/``
-directory, it might be a good idea to add it to your PATH. Or install ovs by
+directory, it might be a good idea to add it to your PATH. Or install OVS by
 ``gmake`` and ``gmake install``.
 
 Open vSwitch on NetBSD is currently "userspace switch" implementation in the

Documentation/intro/install/windows.rst

@@ -124,13 +124,13 @@ Install Requirements
 
   We require that you don't disable the "Allow management operating system to
   share this network adapter" under 'Virtual Switch Properties' > 'Connection
-  type: External network', in the HyperV virtual network switch configuration.
+  type: External network', in the Hyper-V virtual network switch configuration.
 
 * Checksum Offloads
 
   While there is some support for checksum/segmentation offloads in software,
   this is still a work in progress. Till the support is complete we recommend
-  disabling TX/RX offloads for both the VM's as well as the HyperV.
+  disabling TX/RX offloads for both the VM's as well as the Hyper-V.
 
 Bootstrapping
 -------------
@@ -515,7 +515,7 @@ Dumping the ports should show the additional ports that were just added:
 Add virtual interfaces (VIFs)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Adding VIFs to openvswitch is a two step procedure.  The first step is to
+Adding VIFs to Open vSwitch is a two step procedure.  The first step is to
 assign a 'OVS port name' which is a unique name across all VIFs on this
 Hyper-V.  The next step is to add the VIF to the ovsdb using its 'OVS port
 name' as key.
@@ -786,7 +786,7 @@ Windows CI Service
 ------------------
 
 `AppVeyor <www.appveyor.com>`__ provides a free Windows autobuild service for
-opensource projects.  Open vSwitch has integration with AppVeyor for continuous
+open source projects.  Open vSwitch has integration with AppVeyor for continuous
 build.  A developer can build test his changes for Windows by logging into
 appveyor.com using a github account, creating a new project by linking it to
 his development repository in github and triggering a new build.
@@ -798,5 +798,5 @@ TODO
 
 * Investigate and add the feature to provide QoS.
 
-* Sign the driver & create an MSI for installing the different OpenvSwitch
+* Sign the driver & create an MSI for installing the different Open vSwitch
   components on Windows.

Documentation/topics/bonding.rst

@@ -161,7 +161,7 @@ Such network connectivity failure can be avoided if LACP can be configured on
 the OVS host before configuring the physical switch, and having the OVS host
 fall back to a bond mode (active-backup) till the physical switch LACP
 configuration is complete. An option "lacp-fallback-ab" exists to provide such
-behavior on openvswitch.
+behavior on Open vSwitch.
 
 Active Backup Bonding
 ~~~~~~~~~~~~~~~~~~~~~

Documentation/topics/dpdk/ring.rst

@@ -74,7 +74,7 @@ DPDK. However, this functionality was removed because:
 - Support for IVSHMEM was never upstreamed to QEMU and has been publicly
   rejected by the QEMU community
 
-- :doc:`vhost-user interfaces <vhost-user>` are the defacto DPDK-based path to
+- :doc:`vhost-user interfaces <vhost-user>` are the de facto DPDK-based path to
   guests
 
 .. _DPDK documentation: https://dpdk.readthedocs.io/en/v17.11/prog_guide/ring_lib.html

Documentation/topics/idl-compound-indexes.rst

@@ -117,7 +117,7 @@ the comparison functions (built-in and user provided) are FAST.
 
 Skiplists are used as the primary data structure for the implementation of
 indexes. Indexes therefore have an expected ``O(log(n))`` cost when
-inserting, deleting or modifiying a row, ``O(log(n))`` when retrieving
+inserting, deleting or modifying a row, ``O(log(n))`` when retrieving
 a row by key, and O(1) when retrieving the first or next row.
 
 Indexes are maintained incrementally in the replica as notifications of
@@ -155,7 +155,7 @@ Index Creation
 
 Each index must be created with the function ``ovsdb_idl_create_index()``.
 After an index has been created the user can add one or more columns to it,
-using ``ovsdb_idl_index_add_column``. All indexes must be created wiith all
+using ``ovsdb_idl_index_add_column``. All indexes must be created with all
 columns added BEFORE the first call to ovsdb\_idl\_run().
 
 Index Creation Example
@@ -240,7 +240,7 @@ between "from.col1 from.col2 ... from.coln" and "to.col1 to.col2 ...
 to.coln", *NOT the rows with a value in column 1 between from.col1 and
 to.col1, and so on*.
 
-The iterators are macros especific to each table. An example of the use
+The iterators are macros specific to each table. An example of the use of
 these iterators follows:
 
 ::

Documentation/topics/ovsdb-replication.rst

@@ -54,7 +54,7 @@ achieve this, the standby server acts as a client of the active server, in the
 sense that it sends a monitor request to keep up to date with the changes in
 the active server databases. When a notification from the active server
 arrives, the standby server executes the necessary set of operations so its
-databases reach the same state as the the active server databases. Below is the
+databases reach the same state as the active server databases. Below is the
 design represented as a diagram.::
 
     +--------------+    replication     +--------------+

Documentation/topics/testing.rst

@@ -101,7 +101,7 @@ using the ``check-lcov`` target::
 
     $ make check-lcov
 
-All the same options are avaiable via TESTSUITEFLAGS. For example::
+All the same options are available via TESTSUITEFLAGS. For example::
 
     $ make check-lcov TESTSUITEFLAGS='-j8 -k ovn'
 
@@ -418,7 +418,7 @@ The following Proof of Concepts are supported:
 Builders
 ++++++++
 
-This particular Proof of Concept demonsrtates integration with Debian and RPM
+This particular Proof of Concept demonstrates integration with Debian and RPM
 packaging tools:
 
     $ cd ./poc/builders
@@ -431,7 +431,7 @@ you can add them to /etc/apt/sources.list.d or /etc/yum.repos.d
 configuration files on another host to retrieve packages with yum or
 apt-get.
 
-hen you have made changes to OVS source code and want to rebuild packages run:
+When you have made changes to OVS source code and want to rebuild packages run:
     $ git commit -a
     $ vagrant rsync && vagrant provision
 

Documentation/tutorials/ovn-sandbox.rst

@@ -37,7 +37,7 @@ For some general information about ``ovs-sandbox``, see the "Getting Started"
 section of the tutorial_.
 
 ``ovs-sandbox`` does not include OVN support by default.  To enable OVN, you
-must pass the ``--ovn`` flag.  For example, if running it straight from the ovs
+must pass the ``--ovn`` flag.  For example, if running it straight from the OVS
 git tree you would run::
 
     $ make sandbox SANDBOXFLAGS="--ovn"

Documentation/tutorials/ovs-conntrack.rst

@@ -32,9 +32,9 @@ statefull and stateless protocols)
 
 This tutorial demonstrates how OVS can use the connection tracking system
 to match on the TCP segments from connection setup to connection teardown.
-It will use OVS with the linux kernel module as the datapath for this
-tutorial. (datapath which utilizes the openvswitch kernel module to do
-the packet processing in the linux kernel)
+It will use OVS with the Linux kernel module as the datapath for this
+tutorial. (The datapath that utilizes the openvswitch kernel module to do
+the packet processing in the Linux kernel)
 It was tested with the “master” branch of Open vSwitch.
 
 Definitions
@@ -44,7 +44,7 @@ Definitions
 inspection.
 
 **pipeline**: is the packet processing pipeline which is the path taken by
-the packet when traversing through the tables where the pakcet matches the
+the packet when traversing through the tables where the packet matches the
 match fields of a flow in the table and performs the actions present in
 the matched flow.
 

lib/classifier.h

@@ -236,7 +236,7 @@
  * The classifier supports versioning for two reasons:
  *
  *     1. Support for versioned modifications makes it possible to perform an
- *        arbitraty series of classifier changes as one atomic transaction,
+ *        arbitrary series of classifier changes as one atomic transaction,
  *        where intermediate versions of the classifier are not visible to any
  *        lookups.  Also, when a rule is added for a future version, or marked
  *        for removal after the current version, such modifications can be
@@ -293,7 +293,7 @@
  * ovsrcu_postpone() call to destruct the rule is called from the first RCU
  * callback that removes the rule.
  *
- * Rules that have never been visible to lookups are an exeption to the above
+ * Rules that have never been visible to lookups are an exception to the above
  * rule.  Such rules can be removed immediately, but their destruction must
  * still be RCU postponed, as the rule's visibility attribute may be examined
  * parallel to the rule's removal. */

lib/rculist.h

@@ -27,7 +27,7 @@
  * ovsrcu_postpone().
  *
  * The API is almost the same as for struct ovs_list, with the following
- * exeptions:
+ * exceptions:
  *
  * - The 'prev' pointer may not be accessed by the user.
  * - The 'next' pointer should be accessed via rculist_next() by readers, and