From deee2d348f03634128a160ebbe086fab1ed936ba Mon Sep 17 00:00:00 2001 From: Bernard Cafarelli Date: Tue, 28 Jun 2016 18:23:30 +0200 Subject: [PATCH] Fix some typos Change-Id: I5317006ca91c76833f54fd23a5742b42780b3022 --- api-ref/README.rst | 2 +- doc/source/devref/openvswitch_agent.rst | 12 ++++++------ doc/source/devref/quality_of_service.rst | 2 +- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/api-ref/README.rst b/api-ref/README.rst index 185091881d7..6f4a84c3af1 100644 --- a/api-ref/README.rst +++ b/api-ref/README.rst @@ -1,2 +1,2 @@ -Networking API referennce is maintained in the neutron-lib repo. +Networking API reference is maintained in the neutron-lib repo. See api-ref in the neutron-lib repository. diff --git a/doc/source/devref/openvswitch_agent.rst b/doc/source/devref/openvswitch_agent.rst index 2035572b2bb..9f54dd21267 100644 --- a/doc/source/devref/openvswitch_agent.rst +++ b/doc/source/devref/openvswitch_agent.rst @@ -151,7 +151,7 @@ taken into account: platform's point of view discerning which tagged packets are meant to be treated 'transparently' and which ones are meant to be used for demultiplexing (in order to reach the right destination). - The outcome might only be predicatble if two layers of vlan tags + The outcome might only be predictable if two layers of vlan tags are stacked up together, making guest support even more crucial for the combined use case. @@ -233,7 +233,7 @@ are: and ports participating a trunk with no ability to convert from one to the other (and vice versa), no migration is required. This is done at a cost of some loss of flexibility - and maintainance complexity. + and maintenance complexity. * Design reusability: a solution to support vlan trunking for the Linux Bridge mech driver will still be required to avoid widening the gap with Open vSwitch (e.g. OVS has DVR but @@ -254,7 +254,7 @@ are: To summarize: * VLAN interfaces (A) are compelling because will lead to a relatively - contained engineering cost at the expenses of performance. The Open + contained engineering cost at the expense of performance. The Open vSwitch community will need to be involved in order to deliver vlan transparency. Irrespective of whether this strategy is chosen for Open vSwitch or not, this is still the only viable approach for Linux @@ -263,7 +263,7 @@ To summarize: strategy for OVS deployments that are unable to adopt DPDK. * Open Flow (B) is compelling because it will allow Neutron to unlock - the full potential of Open vSwitch, at the expenses of development + the full potential of Open vSwitch, at the expense of development and operations effort. The development is confined within the boundaries of the Neutron community in order to address vlan awareness and transparency (as two distinct use cases, ie. to be adopted @@ -275,7 +275,7 @@ To summarize: * Trunk Bridges (C) tries to bring the best of option A and B together as far as OVS development and performance are concerned, but it - comes at the expenses of maintainance complexity and loss of flexibility. + comes at the expense of maintenance complexity and loss of flexibility. A Linux Bridge solution would still be required and, QinQ support will still be needed to address vlan transparency. @@ -295,7 +295,7 @@ plane performance improvement is hindered by the extra use of kernel resources, this option is not at all appealing in the long term. Embracing option (B) in the long run may be complicated by the adoption of -option (C). The development and maintainance complexity involved in Option +option (C). The development and maintenance complexity involved in Option (C) and (B) respectively poses the existential question as to whether investing in the agent-based architecture is an effective strategy, especially if the end result would look a lot like other maturing diff --git a/doc/source/devref/quality_of_service.rst b/doc/source/devref/quality_of_service.rst index 291e00bec80..5ab9b21e1db 100644 --- a/doc/source/devref/quality_of_service.rst +++ b/doc/source/devref/quality_of_service.rst @@ -362,7 +362,7 @@ The Linux bridge implementation relies on the new tc_lib functions: The ingress bandwidth limit is configured on the tap port by setting a simple `tc-tbf `_ queueing discipline (qdisc) on the port. It requires a value of HZ parameter configured in kernel on the host. -This value is neccessary to calculate the minimal burst value which is set in +This value is necessary to calculate the minimal burst value which is set in tc. Details about how it is calculated can be found in `here `_. This solution is similar to Open vSwitch implementation.