ofproto: Handle flow installation and eviction in upcall.
[sliver-openvswitch.git] / vswitchd / vswitch.xml
index fe176ff..5fd82fc 100644 (file)
         </p>
       </column>
 
-      <column name="other_config" key="flow-eviction-threshold"
+      <column name="other_config" key="flow-limit"
               type='{"type": "integer", "minInteger": 0}'>
         <p>
-          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.
         </p>
         <p>
-          The default is 2500.  Values below 100 will be rounded up to 100.
+          The default is 200000.
         </p>
       </column>
 
               type='{"type": "integer", "minInteger": 1}'>
         <p>
           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).
+          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
          </p>
 
          <p>
-           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 <ref column="ofport_request"/>.  Therefore, to ensure that
-           <ref column="ofport_request"/> 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 <ref
-           column="ofport_request"/>.)
+           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.
+         </p>
+
+         <p>
+           If <ref column="ofport_request"/> is set or changed to some other
+           port's automatically assigned port number, Open vSwitch chooses a
+           new port number for the latter port.
          </p>
        </column>
       </group>
       </p>
 
       <column name="cfm_mpid">
-        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 <ref table="Interface"/>.
+        <p>
+          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 <ref table="Interface"/>.
+        </p>
+        <p>
+          According to the 802.1ag specification, MPIDs can only range between
+          [1, 8191].  However, extended mode (see <ref column="other_config"
+          key="cfm_extended"/>) supports eight byte MPIDs.
+        </p>
       </column>
 
       <column name="cfm_flap_count">
         with compliant implementations which may be running concurrently on the
         network. Furthermore, extended mode increases the accuracy of the
         <code>cfm_interval</code> configuration parameter by breaking wire
-        compatibility with 802.1ag compliant implementations.  Defaults to
-        <code>false</code>.
+        compatibility with 802.1ag compliant implementations.  And extended
+        mode allows eight byte MPIDs.  Defaults to <code>false</code>.
       </column>
 
       <column name="other_config" key="cfm_demand" type='{"type": "boolean"}'>