Signed-off-by: Justin Pettit <jpet...@ovn.org>
---
Documentation/howto/docker.rst | 6 +++---
Documentation/howto/dpdk.rst | 12 ++++++------
Documentation/howto/firewalld.rst | 2 +-
Documentation/howto/lisp.rst | 2 +-
Documentation/howto/userspace-tunneling.rst | 2 +-
Documentation/internals/committer-responsibilities.rst | 2 +-
Documentation/internals/contributing/backporting-patches.rst | 2 +-
.../internals/contributing/coding-style-windows.rst | 8 ++++----
Documentation/internals/contributing/documentation-style.rst | 2 +-
Documentation/internals/contributing/submitting-patches.rst | 8 ++++----
Documentation/intro/install/debian.rst | 2 +-
Documentation/intro/install/dpdk.rst | 2 +-
Documentation/intro/install/general.rst | 2 +-
Documentation/intro/install/netbsd.rst | 2 +-
Documentation/intro/install/windows.rst | 10 +++++-----
Documentation/topics/bonding.rst | 2 +-
Documentation/topics/dpdk/ring.rst | 2 +-
Documentation/topics/idl-compound-indexes.rst | 6 +++---
Documentation/topics/ovsdb-replication.rst | 2 +-
Documentation/topics/testing.rst | 6 +++---
Documentation/tutorials/ovn-sandbox.rst | 2 +-
Documentation/tutorials/ovs-conntrack.rst | 8 ++++----
lib/classifier.h | 4 ++--
lib/rculist.h | 2 +-
utilities/ovs-ofctl.8.in | 2 +-
25 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/Documentation/howto/docker.rst b/Documentation/howto/docker.rst
index ff8b708af7dc..a68b02fdb091 100644
--- a/Documentation/howto/docker.rst
+++ b/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.
diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index d717d2ebebf5..79b626c76d0d 100644
--- a/Documentation/howto/dpdk.rst
+++ b/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
diff --git a/Documentation/howto/firewalld.rst
b/Documentation/howto/firewalld.rst
index b76a4d2b7dc7..0dc455ea8895 100644
--- a/Documentation/howto/firewalld.rst
+++ b/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
diff --git a/Documentation/howto/lisp.rst b/Documentation/howto/lisp.rst
index a65a694c7fe0..f9a329efffdc 100644
--- a/Documentation/howto/lisp.rst
+++ b/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
diff --git a/Documentation/howto/userspace-tunneling.rst
b/Documentation/howto/userspace-tunneling.rst
index 6ad97daec859..d0a767bbcd0a 100644
--- a/Documentation/howto/userspace-tunneling.rst
+++ b/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::
diff --git a/Documentation/internals/committer-responsibilities.rst
b/Documentation/internals/committer-responsibilities.rst
index 954daa8a95e0..4d10c3980875 100644
--- a/Documentation/internals/committer-responsibilities.rst
+++ b/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
diff --git a/Documentation/internals/contributing/backporting-patches.rst
b/Documentation/internals/contributing/backporting-patches.rst
index 30624277ae71..e8f4f271c64f 100644
--- a/Documentation/internals/contributing/backporting-patches.rst
+++ b/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
diff --git a/Documentation/internals/contributing/coding-style-windows.rst
b/Documentation/internals/contributing/coding-style-windows.rst
index 9bd7f05639d1..1edf2285ff3c 100644
--- a/Documentation/internals/contributing/coding-style-windows.rst
+++ b/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
diff --git a/Documentation/internals/contributing/documentation-style.rst
b/Documentation/internals/contributing/documentation-style.rst
index 0e561ec23f10..9c47bd61f007 100644
--- a/Documentation/internals/contributing/documentation-style.rst
+++ b/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
diff --git a/Documentation/internals/contributing/submitting-patches.rst
b/Documentation/internals/contributing/submitting-patches.rst
index eb7e651b85a9..0ddd24502cc9 100644
--- a/Documentation/internals/contributing/submitting-patches.rst
+++ b/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
diff --git a/Documentation/intro/install/debian.rst
b/Documentation/intro/install/debian.rst
index 0bf94e4090d7..4024dc07a700 100644
--- a/Documentation/intro/install/debian.rst
+++ b/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.
diff --git a/Documentation/intro/install/dpdk.rst
b/Documentation/intro/install/dpdk.rst
index ed358d577315..2cf7cca15a6b 100644
--- a/Documentation/intro/install/dpdk.rst
+++ b/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.
diff --git a/Documentation/intro/install/general.rst
b/Documentation/intro/install/general.rst
index deba3eb08fbd..474c9e861572 100644
--- a/Documentation/intro/install/general.rst
+++ b/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::
diff --git a/Documentation/intro/install/netbsd.rst
b/Documentation/intro/install/netbsd.rst
index 0b5b5c91023f..7eb7f0cebbaf 100644
--- a/Documentation/intro/install/netbsd.rst
+++ b/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
diff --git a/Documentation/intro/install/windows.rst
b/Documentation/intro/install/windows.rst
index 4c1cd0ef43a1..6d8c746c5ed8 100644
--- a/Documentation/intro/install/windows.rst
+++ b/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.
diff --git a/Documentation/topics/bonding.rst b/Documentation/topics/bonding.rst
index 461935ae97bd..ac39fd18bfac 100644
--- a/Documentation/topics/bonding.rst
+++ b/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
~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/topics/dpdk/ring.rst
b/Documentation/topics/dpdk/ring.rst
index 8d0ede8caa22..8e8fb6088e90 100644
--- a/Documentation/topics/dpdk/ring.rst
+++ b/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
diff --git a/Documentation/topics/idl-compound-indexes.rst
b/Documentation/topics/idl-compound-indexes.rst
index 44c626b31da7..79371f9831e8 100644
--- a/Documentation/topics/idl-compound-indexes.rst
+++ b/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:
::
diff --git a/Documentation/topics/ovsdb-replication.rst
b/Documentation/topics/ovsdb-replication.rst
index fbf5a9bb25b1..950dfc9b7cde 100644
--- a/Documentation/topics/ovsdb-replication.rst
+++ b/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 +--------------+
diff --git a/Documentation/topics/testing.rst b/Documentation/topics/testing.rst
index 2538571716a6..5dcf446716a3 100644
--- a/Documentation/topics/testing.rst
+++ b/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
diff --git a/Documentation/tutorials/ovn-sandbox.rst
b/Documentation/tutorials/ovn-sandbox.rst
index d1e749f31609..56e46402da74 100644
--- a/Documentation/tutorials/ovn-sandbox.rst
+++ b/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"
diff --git a/Documentation/tutorials/ovs-conntrack.rst
b/Documentation/tutorials/ovs-conntrack.rst
index 57b342e13b20..07ea9982bd37 100644
--- a/Documentation/tutorials/ovs-conntrack.rst
+++ b/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.
diff --git a/lib/classifier.h b/lib/classifier.h
index 31d4a1b08bd2..1263afdfd1a9 100644
--- a/lib/classifier.h
+++ b/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. */
diff --git a/lib/rculist.h b/lib/rculist.h
index 7ba20e5f2415..1072b87af211 100644
--- a/lib/rculist.h
+++ b/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
diff --git a/utilities/ovs-ofctl.8.in b/utilities/ovs-ofctl.8.in
index 7649bc5c4c50..1211829d2758 100644
--- a/utilities/ovs-ofctl.8.in
+++ b/utilities/ovs-ofctl.8.in
@@ -2243,7 +2243,7 @@ The integer meter id of the meter.
When this field is specified in \fBdel-meter\fR, \fBdump-meter\fR, or
\fBmeter-stats\fR, the keyword "all" may be used to designate all meters.
.
-This field is required, exept for \fBmeter-stats\fR, which dumps all stats
+This field is required, except for \fBmeter-stats\fR, which dumps all stats
when this field is not specified.
.IP \fBkbps\fR
--
2.7.4
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
