@@ -1,6 +1,5 @@
docs += \
- Documentation/group-selection-method-property.txt \
- Documentation/OVSDB-replication.rst
+ Documentation/group-selection-method-property.txt
EXTRA_DIST += \
Documentation/_static/logo.png \
@@ -22,6 +21,16 @@ EXTRA_DIST += \
Documentation/intro/install/xenserver.rst \
Documentation/tutorials/index.rst \
Documentation/topics/index.rst \
+ Documentation/topics/bonding.rst \
+ Documentation/topics/datapath.rst \
+ Documentation/topics/design.rst \
+ Documentation/topics/dpdk.rst \
+ Documentation/topics/high-availability.rst \
+ Documentation/topics/integration.rst \
+ Documentation/topics/openflow.rst \
+ Documentation/topics/ovsdb-replication.rst \
+ Documentation/topics/porting.rst \
+ Documentation/topics/windows.rst \
Documentation/howto/index.rst \
Documentation/howto/docker.rst \
Documentation/howto/kvm.rst \
@@ -58,8 +67,7 @@ SPHINXBUILDDIR = $(srcdir)/Documentation/_build
# Internal variables.
PAPEROPT_a4 = -D latex_paper_size=a4
PAPEROPT_letter = -D latex_paper_size=letter
-# TODO(stephenfin): Add '-W' flag here once we've integrated required docs
-ALLSPHINXOPTS = -d $(SPHINXBUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) $(SPHINXSRCDIR)
+ALLSPHINXOPTS = -W -d $(SPHINXBUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) $(SPHINXSRCDIR)
.PHONY: htmldocs
htmldocs:
@@ -45,10 +45,10 @@ example.
* When VM-A is created on a hypervisor, its VIF gets added to the Open vSwitch
integration bridge. This creates a row in the Interface table of the
- ``Open_vSwitch`` database. As explained in the `integration guide`, the
- vif-id associated with the VM network interface gets added in the
- ``external_ids:iface-id`` column of the newly created row in the Interface
- table.
+ ``Open_vSwitch`` database. As explained in the :doc:`integration guide
+ </topics/integration>`, the vif-id associated with the VM network interface
+ gets added in the ``external_ids:iface-id`` column of the newly created row
+ in the Interface table.
* Since VM-A belongs to a logical network, it gets an IP address. This IP
address is used to spawn containers (either manually or through container
@@ -58,4 +58,4 @@ 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.
Open vSwitch on NetBSD is currently "userspace switch" implementation in the
-sense described in :doc:`userspace` and the `porting guide`.
+sense described in :doc:`userspace` and :doc:`/topics/porting`.
similarity index 94%
rename from vswitchd/INTERNALS.rst
rename to Documentation/topics/bonding.rst
@@ -21,21 +21,9 @@
Avoid deeper levels because they do not render well.
-======================
-ovs-vswitchd Internals
-======================
-
-This document describes some of the internals of the ovs-vswitchd process. It
-is not complete. It tends to be updated on demand, so if you have questions
-about the vswitchd implementation, ask them and perhaps we'll add some
-appropriate documentation here.
-
-Most of the ovs-vswitchd implementation is in ``vswitchd/bridge.c``, so code
-references below should be assumed to refer to that file except as otherwise
-specified.
-
+=======
Bonding
--------
+=======
Bonding allows two or more interfaces (the "slaves") to share network traffic.
From a high-level point of view, bonded interfaces act like a single port, but
@@ -55,8 +43,15 @@ Ethernet source address. This is useful only if the traffic over the bond has
multiple Ethernet source addresses, for example if network traffic from
multiple VMs are multiplexed over the bond.
+.. note::
+
+ Most of the ovs-vswitchd implementation is in ``vswitchd/bridge.c``, so code
+ references below should be assumed to refer to that file except as otherwise
+ specified.
+
+
Enabling and Disabling Slaves
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
When a bond is created, a slave is initially enabled or disabled based on
whether carrier is detected on the NIC (see ``iface_create()``). After that, a
@@ -86,7 +81,7 @@ connected to a physical switch; vswitchd should probably provide a way to
disable or configure it in other scenarios.)
Bond Packet Input
-~~~~~~~~~~~~~~~~~
+-----------------
Bonding accepts unicast packets on any bond slave. This can occasionally cause
packet duplication for the first few packets sent to a given MAC, if the
@@ -118,7 +113,7 @@ remaining slave whose interface name is first alphabetically, but this is by no
means guaranteed.
Bond Packet Output
-~~~~~~~~~~~~~~~~~~
+------------------
When a packet is sent out a bond port, the bond slave actually used is selected
based on the packet's source MAC and VLAN tag (see ``choose_output_iface()``).
@@ -143,12 +138,12 @@ Currently, "significantly more loaded" means that H must carry at least 1 Mbps
more traffic, and that traffic must be at least 3% greater than L's.
Bond Balance Modes
-~~~~~~~~~~~~~~~~~~
+------------------
Each bond balancing mode has different considerations, described below.
LACP Bonding
-++++++++++++
+~~~~~~~~~~~~
LACP bonding requires the remote switch to implement LACP, but it is otherwise
very simple in that, after LACP negotiation is complete, there is no need for
@@ -169,7 +164,7 @@ configuration is complete. An option "lacp-fallback-ab" exists to provide such
behavior on openvswitch.
Active Backup Bonding
-+++++++++++++++++++++
+~~~~~~~~~~~~~~~~~~~~~
Active Backup bonds send all traffic out one "active" slave until that slave
becomes unavailable. Since they are significantly less complicated than SLB
@@ -178,7 +173,7 @@ the only bond mode which supports attaching each slave to a different upstream
switch.
SLB Bonding
-+++++++++++
+~~~~~~~~~~~
SLB bonding allows a limited form of load balancing without the remote switch's
knowledge or cooperation. The basics of SLB are simple. SLB assigns each
@@ -241,4 +236,3 @@ SLB bonding has the following complications:
for a MAC+VLAN from which a gratuitous ARP was received from a non-SLB bond
port. For 5 seconds, a locked MAC learning table entry will not be updated
based on a gratuitous ARP received on a SLB bond.
-
similarity index 100%
rename from datapath/README.rst
rename to Documentation/topics/datapath.rst
similarity index 100%
rename from DESIGN.rst
rename to Documentation/topics/design.rst
new file mode 100644
@@ -0,0 +1,28 @@
+..
+ Licensed under the Apache License, Version 2.0 (the "License"); you may
+ not use this file except in compliance with the License. You may obtain
+ a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+ WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ License for the specific language governing permissions and limitations
+ under the License.
+
+ Convention for heading levels in Open vSwitch documentation:
+
+ ======= Heading 0 (reserved for the title in a document)
+ ------- Heading 1
+ ~~~~~~~ Heading 2
+ +++++++ Heading 3
+ ''''''' Heading 4
+
+ Avoid deeper levels because they do not render well.
+
+================
+DPDK Integration
+================
+
+**TODO**
similarity index 100%
rename from ovn/OVN-GW-HA.rst
rename to Documentation/topics/high-availability.rst
@@ -32,3 +32,18 @@ that way.
.. toctree::
:maxdepth: 2
+
+ design
+ datapath
+ integration
+ porting
+ openflow
+ bonding
+ ovsdb-replication
+ dpdk
+ windows
+
+.. toctree::
+ :maxdepth: 2
+
+ high-availability
similarity index 89%
rename from IntegrationGuide.rst
rename to Documentation/topics/integration.rst
@@ -28,10 +28,10 @@ Integration Guide for Centralized Control
This document describes how to integrate Open vSwitch onto a new platform to
expose the state of the switch and attached devices for centralized control.
(If you are looking to port the switching components of Open vSwitch to a new
-platform, please see the PORTING document.) The focus of this guide is on
-hypervisors, but many of the interfaces are useful for hardware switches, as
-well. The XenServer integration is the most mature implementation, so most of
-the examples are drawn from it.
+platform, refer to :doc:`porting`) The focus of this guide is on hypervisors,
+but many of the interfaces are useful for hardware switches, as well. The
+XenServer integration is the most mature implementation, so most of the
+examples are drawn from it.
The externally visible interface to this integration is platform-agnostic. We
encourage anyone who integrates Open vSwitch to use the same interface, because
@@ -204,11 +204,11 @@ contents. At all times, the data can be transacted only from the active server.
When the active server dies for some reason, entire OVN operations will be
stalled.
-`Pacemaker <http://clusterlabs.org/pacemaker.html>`_ is a cluster resource
+`Pacemaker <http://clusterlabs.org/pacemaker.html>`__ is a cluster resource
manager which can manage a defined set of resource across a set of clustered
nodes. Pacemaker manages the resource with the help of the resource agents.
-One among the resource agent is
-`OCF <http://www.linux-ha.org/wiki/OCF_Resource_Agents>`_
+One among the resource agent is `OCF
+<http://www.linux-ha.org/wiki/OCF_Resource_Agents>`__
OCF is nothing but a shell script which accepts a set of actions and returns an
appropriate status code.
@@ -217,48 +217,41 @@ With the help of the OCF resource agent ovn/utilities/ovndb-servers.ocf, one
can defined a resource for the pacemaker such that pacemaker will always
maintain one running active server at any time.
-After creating a pacemaker cluster, use the following commands to create
-one active and multiple backup servers for OVN databases.
+After creating a pacemaker cluster, use the following commands to create one
+active and multiple backup servers for OVN databases::
-::
-
- pcs resource create ovndb_servers ocf:ovn:ovndb-servers \
+ $ pcs resource create ovndb_servers ocf:ovn:ovndb-servers \
master_ip=x.x.x.x \
ovn_ctl=<path of the ovn-ctl script> \
op monitor interval="10s" \
op monitor role=Master interval="15s"
-
- pcs resource master ovndb_servers-master ovndb_servers \
+ $ pcs resource master ovndb_servers-master ovndb_servers \
meta notify="true"
-The `master_ip` and `ovn_ctl` are the parameters that will be used by the
-OCF script. `ovn_ctl` is optional, if not given, it assumes a default value of
+The `master_ip` and `ovn_ctl` are the parameters that will be used by the OCF
+script. `ovn_ctl` is optional, if not given, it assumes a default value of
/usr/share/openvswitch/scripts/ovn-ctl. `master_ip` is the IP address on which
the active database server is expected to be listening.
-Whenever the active server dies, pacemaker is responsible to promote one of
-the backup servers to be active. Both ovn-controller and ovn-northd needs the
+Whenever the active server dies, pacemaker is responsible to promote one of the
+backup servers to be active. Both ovn-controller and ovn-northd needs the
ip-address at which the active server is listening. With pacemaker changing the
node at which the active server is run, it is not efficient to instruct all the
ovn-controllers and the ovn-northd to listen to the latest active server's
ip-address.
This problem can be solved by using a native ocf resource agent
-`ocf:heartbeat:IPaddr2`. The IPAddr2 resource agent is just a resource with an
-ip-address. When we colocate this resource with the active server, pacemaker
+``ocf:heartbeat:IPaddr2``. The IPAddr2 resource agent is just a resource with
+an ip-address. When we colocate this resource with the active server, pacemaker
will enable the active server to be connected with a single ip-address all the
time. This is the ip-address that needs to be given as the parameter while
creating the `ovndb_servers` resource.
Use the following command to create the IPAddr2 resource and colocate it
-with the active server.
+with the active server::
-::
-
- pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=x.x.x.x \
+ $ pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=x.x.x.x \
op monitor interval=30s
-
- pcs constraint order VirtualIP then ovndb_servers-master
-
- pcs constraint colocation add master ovndb_servers-master with VirtualIP \
+ $ pcs constraint order VirtualIP then ovndb_servers-master
+ $ pcs constraint colocation add master ovndb_servers-master with VirtualIP \
score=INFINITY
similarity index 93%
rename from OPENFLOW.rst
rename to Documentation/topics/openflow.rst
@@ -395,21 +395,25 @@ How to contribute
If you plan to contribute code for a feature, please let everyone know on
ovs-dev before you start work. This will help avoid duplicating work.
-Please consider the following:
+Consider the following:
-* Testing. Please test your code.
+* Testing.
-* Unit tests. Please consider writing some. The tests directory has many
- examples that you can use as a starting point.
+ Please test your code.
-* ovs-ofctl. If you add a feature that is useful for some ovs-ofctl command
- then you should add support for it there.
+* Unit tests.
-* Documentation. If you add a user-visible feature, then you should document
- it in the appropriate manpage and mention it in NEWS as well.
+ Consider writing some. The tests directory has many examples that you can
+ use as a starting point.
-* Coding style (see the `coding style guide <CodingStyle.rst>`__ file at the top
- of the source tree).
+* ovs-ofctl.
-* The `patch submission guidelines <CONTRIBUTING.rst>`__. I recommend using
- "git send-email", which automatically follows a lot of those guidelines.
+ If you add a feature that is useful for some ovs-ofctl command then you
+ should add support for it there.
+
+* Documentation.
+
+ If you add a user-visible feature, then you should document it in the
+ appropriate manpage and mention it in NEWS as well.
+
+Refer to :doc:`/internals/contributing/index` for more information.
similarity index 100%
rename from Documentation/OVSDB-replication.rst
rename to Documentation/topics/ovsdb-replication.rst
similarity index 98%
rename from PORTING.rst
rename to Documentation/topics/porting.rst
@@ -141,14 +141,11 @@ Porting Strategies
After a netdev provider has been implemented for a system's network devices,
you may choose among three basic porting strategies.
-.. TODO(stephenfin): Update the link to the installation guide when this is
- moved
-
The lowest-effort strategy is to use the "userspace switch" implementation
built into Open vSwitch. This ought to work, without writing any more code, as
long as the netdev provider that you implemented supports receiving packets.
It yields poor performance, however, because every packet passes through the
-ovs-vswitchd process. See the `userspace installation guide` for instructions
+ovs-vswitchd process. Refer to :doc:`/intro/install/userspace` for instructions
on how to configure a userspace switch.
If the userspace switch is not the right choice for your port, then you will
similarity index 100%
rename from datapath-windows/DESIGN.rst
rename to Documentation/topics/windows.rst
@@ -79,8 +79,9 @@ Q: Does Open vSwitch only work on Linux?
Q: What's involved with porting Open vSwitch to a new platform or switching ASIC?
- A: The `porting document <PORTING.rst>`__ describes how one would go about
- porting Open vSwitch to a new operating system or hardware platform.
+ A: The `porting document <Documentation/development-guide/porting.rst>`__
+ describes how one would go about porting Open vSwitch to a new operating
+ system or hardware platform.
Q: Why would I use Open vSwitch instead of the Linux bridge?
@@ -1588,9 +1589,10 @@ Q: What versions of OpenFlow does Open vSwitch support?
(Open vSwitch 2.2 had an experimental implementation of OpenFlow 1.4 that
could cause crashes. We don't recommend enabling it.)
- The `OpenFlow guide <OPENFLOW.rst>`__ tracks support for OpenFlow 1.1 and
- later features. When support for OpenFlow 1.4 and 1.5 is solidly
- implemented, Open vSwitch will enable those version by default.
+ The `OpenFlow guide <Documentation/development-guide/openflow.rst>`__
+ tracks support for OpenFlow 1.1 and later features. When support for
+ OpenFlow 1.4 and 1.5 is solidly implemented, Open vSwitch will enable those
+ version by default.
Q: Does Open vSwitch support MPLS?
@@ -1651,8 +1653,8 @@ going through.
greater than 65535 (the maximum priority that can be set with
OpenFlow).
- The DESIGN file at the top level of the Open vSwitch source
- distribution describes the in-band model in detail.
+ The ``Documentation/topics/design`` doc describes the in-band model in
+ detail.
If your controllers are not actually in-band (e.g. they are on
localhost via 127.0.0.1, or on a separate network), then you should
@@ -68,12 +68,8 @@ PYCOV_CLEAN_FILES = build-aux/check-structs,cover
docs = \
AUTHORS.rst \
CONTRIBUTING.rst \
- DESIGN.rst \
FAQ.rst \
- IntegrationGuide.rst \
MAINTAINERS.rst \
- OPENFLOW.rst \
- PORTING.rst \
README.rst \
WHY-OVS.rst
EXTRA_DIST = \
@@ -109,8 +109,8 @@ implementation or a hardware switch.
There are many ongoing efforts to port Open vSwitch to hardware chipsets. These
include multiple merchant silicon chipsets (Broadcom and Marvell), as well as a
-number of vendor-specific platforms. (The PORTING file discusses how one would
-go about making such a port.)
+number of vendor-specific platforms. The "Porting" section in the documentation
+discusses how one would go about making such a port.
The advantage of hardware integration is not only performance within
virtualized environments. If physical switches also expose the Open vSwitch
@@ -1,5 +1,4 @@
EXTRA_DIST += \
- datapath-windows/DESIGN.rst \
datapath-windows/Package/package.VcxProj \
datapath-windows/Package/package.VcxProj.user \
datapath-windows/include/OvsDpInterfaceExt.h \
@@ -45,9 +45,6 @@ openvswitch_headers = \
vport-internal_dev.h \
vport-netdev.h
-openvswitch_extras = \
- README.rst
-
dist_sources = $(foreach module,$(dist_modules),$($(module)_sources))
dist_headers = $(foreach module,$(dist_modules),$($(module)_headers))
dist_extras = $(foreach module,$(dist_modules),$($(module)_extras))
@@ -158,8 +158,8 @@ enum {
* NXAST_SET_TUNNEL64. In these cases, if the "struct ofpact" originated
* from OpenFlow, then we want to make sure that, if it gets translated
* back to OpenFlow later, it is translated back to the same action type.
- * (Otherwise, we'd violate the promise made in DESIGN, in the "Action
- * Reproduction" section.)
+ * (Otherwise, we'd violate the promise made in the topics/design doc, in
+ * the "Action Reproduction" section.)
*
* For such actions, the 'raw' member should be the "enum ofp_raw_action"
* originally extracted from the OpenFlow action. (If the action didn't
@@ -282,7 +282,7 @@ enum ofputil_flow_mod_flags {
/* Protocol-independent flow_mod.
*
* The handling of cookies across multiple versions of OpenFlow is a bit
- * confusing. See DESIGN for the details. */
+ * confusing. See the topics/design doc for the details. */
struct ofputil_flow_mod {
struct ovs_list list_node; /* For queuing flow_mods. */
@@ -818,7 +818,7 @@ struct ofputil_table_features {
* supported, otherwise 0. For other versions, they are decoded as -1 and
* ignored for encoding.
*
- * See the section "OFPTC_* Table Configuration" in DESIGN.rst for more
+ * Search for "OFPTC_* Table Configuration" in the documentation for more
* details of how OpenFlow has changed in this area.
*/
enum ofputil_table_miss miss_config; /* OF1.1 and 1.2 only. */
@@ -113,9 +113,8 @@
*
* In Open vSwitch userspace, "struct flow" is the typical way to describe
* a flow, but the datapath interface uses a different data format to
- * allow ABI forward- and backward-compatibility. datapath/README.rst
- * describes the rationale and design. Refer to OVS_KEY_ATTR_* and
- * "struct ovs_key_*" in include/odp-netlink.h for details.
+ * allow ABI forward- and backward-compatibility. Refer to OVS_KEY_ATTR_*
+ * and "struct ovs_key_*" in include/odp-netlink.h for details.
* lib/odp-util.h defines several functions for working with these flows.
*
* - A "mask" that, for each bit in the flow, specifies whether the datapath
@@ -410,9 +410,9 @@ update_learning_table__(struct mac_learning *ml, struct eth_addr src,
* reflected packets, so we lock each entry for which a gratuitous ARP
* packet was received over a non-bond interface and refrain from
* learning from gratuitous ARP packets that arrive over bond
- * interfaces for this entry while the lock is in effect. See
- * vswitchd/INTERNALS.rst for more in-depth discussion on this
- * topic. */
+ * interfaces for this entry while the lock is in effect. Refer to the
+ * 'ovs-vswitch Internals' document for more in-depth discussion on
+ * this topic. */
if (!is_bond) {
mac_entry_set_grat_arp_lock(mac);
} else if (mac_entry_is_grat_arp_locked(mac)) {
@@ -46,8 +46,8 @@
*
* Second, the implementation has the ability to "lock" a MAC table entry
* updated by a gratuitous ARP. This is a simple feature but the rationale for
- * it is complicated. Please refer to the description of SLB bonding in
- * vswitchd/INTERNALS.rst for an explanation.
+ * it is complicated. Refer to the description of SLB bonding in the
+ * 'ovs-vswitchd Internals' guide for an explanation.
*
* Third, the implementation expires entries that are idle for longer than a
* configurable amount of time. This is implemented by keeping all of the
@@ -30,7 +30,7 @@ extern "C" {
*
* Every port on a switch must have a corresponding netdev that must minimally
* support a few operations, such as the ability to read the netdev's MTU.
- * The PORTING file at the top of the source tree has more information in the
+ * The Porting section of the documentation has more information in the
* "Writing a netdev Provider" section.
*
* Thread-safety
@@ -5679,7 +5679,7 @@ ofputil_encode_table_config(enum ofputil_table_miss miss,
enum ofp_version version)
{
uint32_t config = 0;
- /* See the section "OFPTC_* Table Configuration" in DESIGN.rst for more
+ /* Search for "OFPTC_* Table Configuration" in the documentation for more
* information on the crazy evolution of this field. */
switch (version) {
case OFP10_VERSION:
@@ -1520,7 +1520,7 @@ ofconn_receives_async_msg(const struct ofconn *ofconn,
ovs_assert((unsigned int) type < OAM_N_TYPES);
/* Keep the following code in sync with the documentation in the
- * "Asynchronous Messages" section in DESIGN. */
+ * "Asynchronous Messages" section in 'topics/design' */
if (ofconn->type == OFCONN_SERVICE && !ofconn->miss_send_len) {
/* Service connections don't get asynchronous messages unless they have
@@ -71,8 +71,7 @@ EXTRA_DIST += ovn/ovn-architecture.7.xml
DISTCLEANFILES += ovn/ovn-architecture.7
EXTRA_DIST += \
- ovn/TODO.rst \
- ovn/OVN-GW-HA.rst
+ ovn/TODO.rst
# Version checking for ovn-nb.ovsschema.
ALL_LOCAL += ovn/ovn-nb.ovsschema.stamp
@@ -731,8 +731,7 @@ pinctrl_recv(const struct ofp_header *oh, enum ofptype type)
if (type == OFPTYPE_ECHO_REQUEST) {
queue_msg(make_echo_reply(oh));
} else if (type == OFPTYPE_GET_CONFIG_REPLY) {
- /* Enable asynchronous messages (see "Asynchronous Messages" in
- * DESIGN.rst for more information). */
+ /* Enable asynchronous messages */
struct ofputil_switch_config config;
ofputil_decode_get_config_reply(oh, &config);
@@ -341,8 +341,8 @@
controller (over a Unix domain socket) instead of a remote controller.
It's possible, however, for some other bridge in the same system to have
an in-band remote controller, and in that case this suppresses the flows
- that in-band control would ordinarily set up. See <code>In-Band
- Control</code> in <code>DESIGN.rst</code> for more information.
+ that in-band control would ordinarily set up. Refer to the documentation
+ for more information.
</dd>
</dl>
@@ -481,7 +481,7 @@ fi
%{_mandir}/man8/ovs-vswitchd.8*
%{_mandir}/man8/ovs-parse-backtrace.8*
%{_mandir}/man8/ovs-testcontroller.8*
-%doc COPYING DESIGN.rst NOTICE README.rst WHY-OVS.rst
+%doc COPYING NOTICE README.rst WHY-OVS.rst
%doc FAQ.rst NEWS rhel/README.RHEL.rst
/var/lib/openvswitch
/var/log/openvswitch
@@ -248,7 +248,7 @@ exit 0
/usr/share/openvswitch/scripts/sysconfig.template
/usr/share/openvswitch/vswitch.ovsschema
/usr/share/openvswitch/vtep.ovsschema
-%doc COPYING DESIGN.rst NOTICE README.rst WHY-OVS.rst FAQ.rst NEWS
+%doc COPYING NOTICE README.rst WHY-OVS.rst FAQ.rst NEWS
%doc rhel/README.RHEL.rst
/var/lib/openvswitch
/var/log/openvswitch
@@ -2476,7 +2476,7 @@ AT_CHECK([echo "$tcp_flags" | ovs-ofctl parse-oxm OpenFlow15], [0],
AT_CLEANUP
dnl Check all of the patterns mentioned in the "VLAN Matching" section
-dnl in the DESIGN file at top level.
+dnl in the topics/design doc
AT_SETUP([ovs-ofctl check-vlan])
AT_KEYWORDS([VLAN])
@@ -787,7 +787,7 @@ When \fBipv6\fR or \fBdl_type=0x86dd\fR is specified, matches IPv6
header type \fIproto\fR, which is specified as a decimal number between
0 and 255, inclusive (e.g. 58 to match ICMPv6 packets or 6 to match
TCP). The header type is the terminal header as described in the
-\fBDESIGN\fR document.
+\fBtopics/design\fR document.
.IP
When \fBarp\fR or \fBdl_type=0x0806\fR is specified, matches the lower
8 bits of the ARP opcode. ARP opcodes greater than 255 are treated as
@@ -16,7 +16,6 @@ vswitchd_ovs_vswitchd_LDADD = \
lib/libsflow.la \
lib/libopenvswitch.la
vswitchd_ovs_vswitchd_LDFLAGS = $(AM_LDFLAGS) $(DPDK_vswitchd_LDFLAGS)
-EXTRA_DIST += vswitchd/INTERNALS.rst
MAN_ROOTS += vswitchd/ovs-vswitchd.8.in
# vswitch schema and IDL
There are many docs that don't need to kept at the top level, along with many more hidden in random folders. Move them all. This also allows us to add the '-W' flag to Sphinx, ensuring unindexed docs result in build failures. Signed-off-by: Stephen Finucane <stephen@that.guru> --- Documentation/automake.mk | 16 +++++-- Documentation/howto/openstack-containers.rst | 8 ++-- Documentation/intro/install/netbsd.rst | 2 +- .../topics/bonding.rst | 38 +++++++---------- .../topics/datapath.rst | 0 DESIGN.rst => Documentation/topics/design.rst | 0 Documentation/topics/dpdk.rst | 28 +++++++++++++ .../topics/high-availability.rst | 0 Documentation/topics/index.rst | 15 +++++++ .../topics/integration.rst | 49 ++++++++++------------ OPENFLOW.rst => Documentation/topics/openflow.rst | 28 +++++++------ .../ovsdb-replication.rst} | 0 PORTING.rst => Documentation/topics/porting.rst | 5 +-- .../DESIGN.rst => Documentation/topics/windows.rst | 0 FAQ.rst | 16 +++---- Makefile.am | 4 -- WHY-OVS.rst | 4 +- datapath-windows/automake.mk | 1 - datapath/Modules.mk | 3 -- include/openvswitch/ofp-actions.h | 4 +- include/openvswitch/ofp-util.h | 4 +- lib/dpif.h | 5 +-- lib/mac-learning.c | 6 +-- lib/mac-learning.h | 4 +- lib/netdev.h | 2 +- lib/ofp-util.c | 2 +- ofproto/connmgr.c | 2 +- ovn/automake.mk | 3 +- ovn/controller/pinctrl.c | 3 +- ovn/ovn-architecture.7.xml | 4 +- rhel/openvswitch-fedora.spec.in | 2 +- rhel/openvswitch.spec.in | 2 +- tests/ovs-ofctl.at | 2 +- utilities/ovs-ofctl.8.in | 2 +- vswitchd/automake.mk | 1 - 35 files changed, 147 insertions(+), 118 deletions(-) rename vswitchd/INTERNALS.rst => Documentation/topics/bonding.rst (94%) rename datapath/README.rst => Documentation/topics/datapath.rst (100%) rename DESIGN.rst => Documentation/topics/design.rst (100%) create mode 100644 Documentation/topics/dpdk.rst rename ovn/OVN-GW-HA.rst => Documentation/topics/high-availability.rst (100%) rename IntegrationGuide.rst => Documentation/topics/integration.rst (89%) rename OPENFLOW.rst => Documentation/topics/openflow.rst (93%) rename Documentation/{OVSDB-replication.rst => topics/ovsdb-replication.rst} (100%) rename PORTING.rst => Documentation/topics/porting.rst (98%) rename datapath-windows/DESIGN.rst => Documentation/topics/windows.rst (100%)