+
+ <column name="other_config" key="flow-restore-wait"
+ type='{"type": "boolean"}'>
+ <p>
+ When <code>ovs-vswitchd</code> starts up, it has an empty flow table
+ and therefore it handles all arriving packets in its default fashion
+ according to its configuration, by dropping them or sending them to
+ an OpenFlow controller or switching them as a standalone switch.
+ This behavior is ordinarily desirable. However, if
+ <code>ovs-vswitchd</code> is restarting as part of a ``hot-upgrade,''
+ then this leads to a relatively long period during which packets are
+ mishandled.
+ </p>
+ <p>
+ This option allows for improvement. When <code>ovs-vswitchd</code>
+ starts with this value set as <code>true</code>, it will neither
+ flush or expire previously set datapath flows nor will it send and
+ receive any packets to or from the datapath. When this value is
+ later set to <code>false</code>, <code>ovs-vswitchd</code> will
+ start receiving packets from the datapath and re-setup the flows.
+ </p>
+ <p>
+ Thus, with this option, the procedure for a hot-upgrade of
+ <code>ovs-vswitchd</code> becomes roughly the following:
+ </p>
+ <ol>
+ <li>
+ Stop <code>ovs-vswitchd</code>.
+ </li>
+ <li>
+ Set <ref column="other_config" key="flow-restore-wait"/>
+ to <code>true</code>.
+ </li>
+ <li>
+ Start <code>ovs-vswitchd</code>.
+ </li>
+ <li>
+ Use <code>ovs-ofctl</code> (or some other program, such as an
+ OpenFlow controller) to restore the OpenFlow flow table
+ to the desired state.
+ </li>
+ <li>
+ Set <ref column="other_config" key="flow-restore-wait"/>
+ to <code>false</code> (or remove it entirely from the database).
+ </li>
+ </ol>
+ <p>
+ The <code>ovs-ctl</code>'s ``restart'' and ``force-reload-kmod''
+ functions use the above config option during hot upgrades.
+ </p>
+ </column>
+
+ <column name="other_config" key="flow-limit"
+ type='{"type": "integer", "minInteger": 0}'>
+ <p>
+ The maximum
+ number of flows allowed in the datapath flow table. Internally OVS
+ will choose a flow limit which will likely be lower than this number,
+ based on real time network conditions.
+ </p>
+ <p>
+ The default is 200000.
+ </p>
+ </column>
+
+ <column name="other_config" key="n-handler-threads"
+ type='{"type": "integer", "minInteger": 1}'>
+ <p>
+ Specifies the number of threads for software datapaths to use for
+ handling new flows. The default the number of online CPU cores minus
+ the number of revalidators.
+ </p>
+ <p>
+ This configuration is per datapath. If you have more than one
+ software datapath (e.g. some <code>system</code> bridges and some
+ <code>netdev</code> bridges), then the total number of threads is
+ <code>n-handler-threads</code> times the number of software
+ datapaths.
+ </p>
+ </column>
+
+ <column name="other_config" key="n-revalidator-threads"
+ type='{"type": "integer", "minInteger": 1}'>
+ <p>
+ Specifies the number of threads for software datapaths to use for
+ revalidating flows in the datapath. Typically, there is a direct
+ correlation between the number of revalidator threads, and the number
+ of flows allowed in the datapath. The default is the number of cpu
+ cores divided by four plus one. If <code>n-handler-threads</code> is
+ set, the default changes to the number of cpu cores minus the number
+ of handler threads.
+ </p>
+ <p>
+ This configuration is per datapath. If you have more than one
+ software datapath (e.g. some <code>system</code> bridges and some
+ <code>netdev</code> bridges), then the total number of threads is
+ <code>n-handler-threads</code> times the number of software
+ datapaths.
+ </p>
+ </column>