X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;f=FAQ;h=2912ae335d1abdb9e5ae5e39ff586a7058da7200;hb=ac60863f78e412004c5b69f5a64a49bc6f0bc46d;hp=cd3241a30a0b96d11f57f2dcdb90c90c5b3a77b9;hpb=5ea1eab089607de8f87189fe4463364e26576070;p=sliver-openvswitch.git

diff --git a/FAQ b/FAQ
index cd3241a30..2912ae335 100644
--- a/FAQ
+++ b/FAQ
@@ -418,7 +418,11 @@ A: First, why do you want to do this?  Two connected bridges are not
    ports will not work with the userspace datapath, only with the
    kernel module.
 
-Q: Why are there so many different ways to dump flows?
+
+Implementation Details
+----------------------
+
+Q: I hear OVS has a couple of kinds of flows.  Can you tell me about them?
 
 A: Open vSwitch uses different kinds of flows for different purposes:
 
@@ -434,18 +438,27 @@ A: Open vSwitch uses different kinds of flows for different purposes:
         about hidden flows.)
 
       - The Open vSwitch software switch implementation uses a second
-        kind of flow internally.  These flows, called "exact-match"
-        or "datapath" or "kernel" flows, do not support wildcards or
-        priorities and comprise only a single table, which makes them
-        suitable for caching.   OpenFlow flows and exact-match flows
+        kind of flow internally.  These flows, called "datapath" or
+        "kernel" flows, do not support priorities and comprise only a
+        single table, which makes them suitable for caching.  (Like
+        OpenFlow flows, datapath flows do support wildcarding, in Open
+        vSwitch 1.11 and later.)  OpenFlow flows and datapath flows
         also support different actions and number ports differently.
 
-        Exact-match flows are an implementation detail that is
-        subject to change in future versions of Open vSwitch.  Even
-        with the current version of Open vSwitch, hardware switch
-        implementations do not necessarily use exact-match flows.
+        Datapath flows are an implementation detail that is subject to
+        change in future versions of Open vSwitch.  Even with the
+        current version of Open vSwitch, hardware switch
+        implementations do not necessarily use this architecture.
+
+   Users and controllers directly control only the OpenFlow flow
+   table.  Open vSwitch manages the datapath flow table itself, so
+   users should not normally be concerned with it.
+
+Q: Why are there so many different ways to dump flows?
 
-  Each of the commands for dumping flows has a different purpose:
+A: Open vSwitch has two kinds of flows (see the previous question), so
+   it has commands with different purposes for dumping each kind of
+   flow:
 
       - "ovs-ofctl dump-flows <br>" dumps OpenFlow flows, excluding
         hidden flows.  This is the most commonly useful form of flow
@@ -456,7 +469,7 @@ A: Open vSwitch uses different kinds of flows for different purposes:
         including hidden flows.  This is occasionally useful for
         troubleshooting suspected issues with in-band control.
 
-      - "ovs-dpctl dump-flows [dp]" dumps the exact-match flow table
+      - "ovs-dpctl dump-flows [dp]" dumps the datapath flow table
         entries for a Linux kernel-based datapath.  In Open vSwitch
         1.10 and later, ovs-vswitchd merges multiple switches into a
         single datapath, so it will show all the flows on all your
@@ -464,8 +477,29 @@ A: Open vSwitch uses different kinds of flows for different purposes:
         useful for debugging.
 
       - "ovs-appctl dpif/dump-flows <br>", new in Open vSwitch 1.10,
-        dumps exact-match flows for only the specified bridge,
-        regardless of the type.
+        dumps datapath flows for only the specified bridge, regardless
+        of the type.
+
+
+Performance
+-----------
+
+Q: I just upgraded and I see a performance drop.  Why?
+
+A: The OVS kernel datapath may have been updated to a newer version than
+   the OVS userspace components.  Sometimes new versions of OVS kernel
+   module add functionality that is backwards compatible with older
+   userspace components but may cause a drop in performance with them.
+   Especially, if a kernel module from OVS 2.1 or newer is paired with
+   OVS userspace 1.10 or older, there will be a performance drop for
+   TCP traffic.
+
+   Updating the OVS userspace components to the latest released
+   version should fix the performance degradation.
+
+   To get the best possible performance and functionality, it is
+   recommended to pair the same versions of the kernel module and OVS
+   userspace.
 
 
 Configuration Problems