diff options
35 files changed, 147 insertions, 118 deletions
diff --git a/Documentation/automake.mk b/Documentation/automake.mk index 04afdcf9c..24ba1c9ea 100644 --- a/Documentation/automake.mk +++ b/Documentation/automake.mk @@ -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: diff --git a/Documentation/howto/openstack-containers.rst b/Documentation/howto/openstack-containers.rst index f10f60e14..692fe25e5 100644 --- a/Documentation/howto/openstack-containers.rst +++ b/Documentation/howto/openstack-containers.rst @@ -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 diff --git a/Documentation/intro/install/netbsd.rst b/Documentation/intro/install/netbsd.rst index 2b52eaf08..b32da2008 100644 --- a/Documentation/intro/install/netbsd.rst +++ b/Documentation/intro/install/netbsd.rst @@ -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`. diff --git a/vswitchd/INTERNALS.rst b/Documentation/topics/bonding.rst index 95c00f227..2f67cbbf6 100644 --- a/vswitchd/INTERNALS.rst +++ b/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. - diff --git a/datapath/README.rst b/Documentation/topics/datapath.rst index 47e0e23e9..47e0e23e9 100644 --- a/datapath/README.rst +++ b/Documentation/topics/datapath.rst diff --git a/DESIGN.rst b/Documentation/topics/design.rst index adc407ac9..adc407ac9 100644 --- a/DESIGN.rst +++ b/Documentation/topics/design.rst diff --git a/Documentation/topics/dpdk.rst b/Documentation/topics/dpdk.rst new file mode 100644 index 000000000..74e02661e --- /dev/null +++ b/Documentation/topics/dpdk.rst @@ -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** diff --git a/ovn/OVN-GW-HA.rst b/Documentation/topics/high-availability.rst index 5b21b6469..5b21b6469 100644 --- a/ovn/OVN-GW-HA.rst +++ b/Documentation/topics/high-availability.rst diff --git a/Documentation/topics/index.rst b/Documentation/topics/index.rst index 33f157718..30f74fe59 100644 --- a/Documentation/topics/index.rst +++ b/Documentation/topics/index.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 diff --git a/IntegrationGuide.rst b/Documentation/topics/integration.rst index 11e77baf3..e3c2092e4 100644 --- a/IntegrationGuide.rst +++ b/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 diff --git a/OPENFLOW.rst b/Documentation/topics/openflow.rst index b62c5be81..a2c22a8f4 100644 --- a/OPENFLOW.rst +++ b/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. diff --git a/Documentation/OVSDB-replication.rst b/Documentation/topics/ovsdb-replication.rst index fbf5a9bb2..fbf5a9bb2 100644 --- a/Documentation/OVSDB-replication.rst +++ b/Documentation/topics/ovsdb-replication.rst diff --git a/PORTING.rst b/Documentation/topics/porting.rst index bae8cd9cd..b327b2b0d 100644 --- a/PORTING.rst +++ b/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 diff --git a/datapath-windows/DESIGN.rst b/Documentation/topics/windows.rst index 81c1da5f7..81c1da5f7 100644 --- a/datapath-windows/DESIGN.rst +++ b/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 diff --git a/Makefile.am b/Makefile.am index 3579ac18a..427ac07eb 100644 --- a/Makefile.am +++ b/Makefile.am @@ -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 = \ diff --git a/WHY-OVS.rst b/WHY-OVS.rst index 5cfd7213e..e73066a76 100644 --- a/WHY-OVS.rst +++ b/WHY-OVS.rst @@ -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 diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk index 0f2bb22bf..88aa50ae6 100644 --- a/datapath-windows/automake.mk +++ b/datapath-windows/automake.mk @@ -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 \ diff --git a/datapath/Modules.mk b/datapath/Modules.mk index 2ffab2b2f..21f04a0ea 100644 --- a/datapath/Modules.mk +++ b/datapath/Modules.mk @@ -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)) diff --git a/include/openvswitch/ofp-actions.h b/include/openvswitch/ofp-actions.h index 29992614e..946beafeb 100644 --- a/include/openvswitch/ofp-actions.h +++ b/include/openvswitch/ofp-actions.h @@ -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 diff --git a/include/openvswitch/ofp-util.h b/include/openvswitch/ofp-util.h index 8703d2a3a..91ff0c293 100644 --- a/include/openvswitch/ofp-util.h +++ b/include/openvswitch/ofp-util.h @@ -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. */ diff --git a/lib/dpif.h b/lib/dpif.h index e69087dee..40ffe29e7 100644 --- a/lib/dpif.h +++ b/lib/dpif.h @@ -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 diff --git a/lib/mac-learning.c b/lib/mac-learning.c index 57b81f418..44c49622b 100644 --- a/lib/mac-learning.c +++ b/lib/mac-learning.c @@ -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)) { diff --git a/lib/mac-learning.h b/lib/mac-learning.h index e42781500..ee14185d9 100644 --- a/lib/mac-learning.h +++ b/lib/mac-learning.h @@ -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 diff --git a/lib/netdev.h b/lib/netdev.h index bad28c4c1..a667fe35f 100644 --- a/lib/netdev.h +++ b/lib/netdev.h @@ -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 diff --git a/lib/ofp-util.c b/lib/ofp-util.c index 899cfe388..b9efd32ee 100644 --- a/lib/ofp-util.c +++ b/lib/ofp-util.c @@ -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: diff --git a/ofproto/connmgr.c b/ofproto/connmgr.c index 4b927d64b..1f135a423 100644 --- a/ofproto/connmgr.c +++ b/ofproto/connmgr.c @@ -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 diff --git a/ovn/automake.mk b/ovn/automake.mk index 7465f8ed2..1257ef49d 100644 --- a/ovn/automake.mk +++ b/ovn/automake.mk @@ -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 diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c index db9e44161..673d65cb3 100644 --- a/ovn/controller/pinctrl.c +++ b/ovn/controller/pinctrl.c @@ -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); diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml index 95cba984d..d96e4b141 100644 --- a/ovn/ovn-architecture.7.xml +++ b/ovn/ovn-architecture.7.xml @@ -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> diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/openvswitch-fedora.spec.in index d70934a48..d9befe066 100644 --- a/rhel/openvswitch-fedora.spec.in +++ b/rhel/openvswitch-fedora.spec.in @@ -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 diff --git a/rhel/openvswitch.spec.in b/rhel/openvswitch.spec.in index 95375b3b7..2f99dcc0a 100644 --- a/rhel/openvswitch.spec.in +++ b/rhel/openvswitch.spec.in @@ -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 diff --git a/tests/ovs-ofctl.at b/tests/ovs-ofctl.at index f2ee97009..8bc6239db 100644 --- a/tests/ovs-ofctl.at +++ b/tests/ovs-ofctl.at @@ -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]) diff --git a/utilities/ovs-ofctl.8.in b/utilities/ovs-ofctl.8.in index 96135eac8..af1eb2b7b 100644 --- a/utilities/ovs-ofctl.8.in +++ b/utilities/ovs-ofctl.8.in @@ -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 diff --git a/vswitchd/automake.mk b/vswitchd/automake.mk index 94a027216..895625be2 100644 --- a/vswitchd/automake.mk +++ b/vswitchd/automake.mk @@ -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 |