X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;f=vswitchd%2Fvswitch.xml;h=7f2fd587d754afc469964b1111935851a2e01854;hb=0ef165ecb57943e17a8ee8270df68ffb8d032e29;hp=fe176ffa5c5c46e9a10a1ff7cf410978cfc60751;hpb=13751fd88c4b7464f9453c03659201c10b3b87a0;p=sliver-openvswitch.git diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml index fe176ffa5..7f2fd587d 100644 --- a/vswitchd/vswitch.xml +++ b/vswitchd/vswitch.xml @@ -123,48 +123,45 @@
-- A number of flows as a nonnegative integer. This sets number of - flows at which eviction from the datapath flow table will be - triggered. If there are a large number of flows then increasing this - value to around the number of flows present can result in reduced CPU - usage and packet loss. + 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.
- The default is 2500. Values below 100 will be rounded up to 100. + The default is 200000.
- Specifies userspace behaviour for handling flow misses. This takes - precedence over flow-eviction-threshold. + 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.
-
auto
with-facets
without-facets
system
bridges and some
+ netdev
bridges), then the total number of threads is
+ n-handler-threads
times the number of software
+ datapaths.
Specifies the number of threads for software datapaths to use for
- handling new flows. The default is two less than the number of
- online CPU cores (but at least 1).
+ 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 n-handler-threads
is
+ set, the default changes to the number of cpu cores minus the number
+ of handler threads.
This configuration is per datapath. If you have more than one @@ -568,9 +565,22 @@
OpenFlow10
will be used if this column is empty.
+ + List of OpenFlow protocols that may be used when negotiating + a connection with a controller. OpenFlow 1.0, 1.1, 1.2, and + 1.3 are enabled by default if this column is empty. +
+ +
+ The current implementation of OpenFlow 1.4 support is not safe:
+ ovs-vswitchd
will abort when certain unimplemented
+ features are tested. Thus, for now it is suitable only for
+ experimental use. For this reason, OpenFlow 1.4 is supported only
+ if, in addition to specifying OpenFlow14
in this field,
+ ovs-vswitchd
is invoked with the
+ --enable-of14
option. (When support becomes safe, this
+ option will be removed.)
+
- Open vSwitch currently assigns the OpenFlow port number for an - interface once, when the client first adds the interface. It does - not change the port number later if the client sets or changes or - clears . Therefore, to ensure that - takes effect, the client should set - it in the same database transaction that creates the interface. - (Future versions of Open vSwitch might honor changes to .) + A client should ideally set this column's value in the same + database transaction that it uses to create the interface. Open + vSwitch version 2.1 and later will honor a later request for a + specific port number, althuogh it might confuse some controllers: + OpenFlow does not have a way to announce a port number change, so + Open vSwitch represents it over OpenFlow as a port deletion + followed immediately by a port addition. +
+ ++ If is set or changed to some other + port's automatically assigned port number, Open vSwitch chooses a + new port number for the latter port.
true
, traffic received on the
+ is used to indicate the capability of packet
+ I/O. BFD control packets are still transmitted and received. At
+ least one BFD control packet must be received every 100 * amount of time. Otherwise, even if
+ traffic are received, the
+ will be false
.
00:23:20:00:00:01
.
169.254.1.0
.
+ 169.254.1.1
.
+ + A Maintenance Point ID (MPID) uniquely identifies each endpoint + within a Maintenance Association. The MPID is used to identify this + endpoint to other Maintenance Points in the MA. Each end of a link + being monitored should have a different MPID. Must be configured to + enable CFM on this . +
++ According to the 802.1ag specification, MPIDs can only range between + [1, 8191]. However, extended mode (see ) supports eight byte MPIDs. +
cfm_interval
configuration parameter by breaking wire
- compatibility with 802.1ag compliant implementations. Defaults to
- false
.
+ compatibility with 802.1ag compliant implementations. And extended
+ mode allows eight byte MPIDs. Defaults to false
.
@@ -2596,6 +2632,13 @@ one flow table. Currently this limit is 3.
Common
+ Columns
at the beginning of this document.
+
+