X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;ds=sidebyside;f=vswitchd%2Fvswitch.xml;h=a3518130f1fe204aaed90a6cf0adc79bf487e2c3;hb=12eb035b810ff9d537d6ff9f1eb8ad5564c1f644;hp=d2fba341f905fa61b69777721da4da2b2ab99d0a;hpb=484c8355ded7682e2a722eb7da8782b9f9b576c5;p=sliver-openvswitch.git
diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
index d2fba341f..a3518130f 100644
--- a/vswitchd/vswitch.xml
+++ b/vswitchd/vswitch.xml
@@ -72,6 +72,22 @@
host as displayed by
+ Interval for updating statistics to the database, in milliseconds.
+ This option will affect the update of the
+ Default value is 5000 ms.
+
+ Getting statistics more frequently can be achieved via OpenFlow.
+
@@ -123,48 +139,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.
- xe host-list
.
+ statistics
+ column in the following tables: Port
, Interface
+
, Mirror
.
+
-
+ This configuration is per datapath. If you have more than one
+ software datapath (e.g. some 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 +581,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.)
+
The following modes require the upstream switch to support 802.3ad with
- successful LACP negotiation:
+ successful LACP negotiation. If LACP negotiation fails and
+ other-config:lacp-fallback-ab is true, then active-backup
+ mode is used:
off
if unset.
+ disabled, unless other-config:lacp-fallback-ab is set to true.
+ Defaults to off
if unset.
+ Determines the behavior of openvswitch bond in LACP mode. If
+ the partner switch does not support LACP, setting this option
+ to true
allows openvswitch to fallback to
+ active-backup. If the option is set to false
, the
+ bond will be disabled. In both the cases, once the partner switch
+ is configured to LACP mode, the bond will use LACP.
+
- Key-value pairs that report port statistics.
+ Key-value pairs that report port statistics. The update period
+ is controlled by in the Open_vSwitch
table.
- 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.
lisp
+ A layer 3 tunnel over the experimental, UDP-based Locator/ID + Separation Protocol (RFC 6830). +
++ Only IPv4 and IPv6 packets are supported by the protocol, and + they are sent and received without an Ethernet header. Traffic + to/from LISP ports is expected to be configured explicitly, and + the ports are not intended to participate in learning based + switching. As such, they are always excluded from packet + flooding. +
patch
Key-value pairs that report interface statistics. The current
- implementation updates these counters periodically. Future
- implementations may update them when an interface is created, when they
- are queried (e.g. using an OVSDB select
operation), and
- just before an interface is deleted due to virtual interface hot-unplug
- or VM shutdown, and perhaps at other times, but not on any regular
- periodic basis.
+ implementation updates these counters periodically. The update period
+ is controlled by in the Open_vSwitch
table.
+ Future implementations may update them when an interface is created,
+ when they are queried (e.g. using an OVSDB select
+ operation), and just before an interface is deleted due to virtual
+ interface hot-unplug or VM shutdown, and perhaps at other times, but
+ not on any regular periodic basis.
These are the same statistics reported by OpenFlow in its struct
@@ -1928,10 +1988,13 @@
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
.
@@ -2502,6 +2590,75 @@ column has no effect.
+ This string set specifies which fields should be used for + address prefix tracking. Prefix tracking allows the + classifier to skip rules with longer than necessary prefixes, + resulting in better wildcarding for datapath flows. +
++ Prefix tracking may be beneficial when a flow table contains + matches on IP address fields with different prefix lengths. + For example, when a flow table contains IP address matches on + both full addresses and proper prefixes, the full address + matches will typically cause the datapath flow to un-wildcard + the whole address field (depending on flow entry priorities). + In this case each packet with a different address gets handed + to the userspace for flow processing and generates its own + datapath flow. With prefix tracking enabled for the address + field in question packets with addresses matching shorter + prefixes would generate datapath flows where the irrelevant + address bits are wildcarded, allowing the same datapath flow + to handle all the packets within the prefix in question. In + this case many userspace upcalls can be avoided and the + overall performance can be better. +
++ This is a performance optimization only, so packets will + receive the same treatment with or without prefix tracking. +
+
+ The supported fields are: tun_id
,
+ tun_src
, tun_dst
,
+ nw_src
, nw_dst
(or aliases
+ ip_src
and ip_dst
),
+ ipv6_src
, and ipv6_dst
. (Using this
+ feature for tun_id
would only make sense if the
+ tunnel IDs have prefix structure similar to IP addresses.)
+
+ For example, prefixes=ip_dst,ip_src
instructs the
+ flow classifier to track the IP destination and source
+ addresses used by the rules in this specific flow table. To
+ set the prefix fields, the flow table record needs to exist:
+
ovs-vsctl set Bridge br0 flow_tables:0=@N1 -- --id=@N1 create Flow_Table name=table0
ovs-vsctl set Flow_Table table0 prefixes=ip_dst,ip_src
+ There is a maximum number of fields that can be enabled for any + one flow table. Currently this limit is 3. +
+Common
+ Columns
at the beginning of this document.
+
+