updated to new rx_recv semantics
[sliver-openvswitch.git] / FAQ
diff --git a/FAQ b/FAQ
index df7b6ef..a08d65c 100644 (file)
--- a/FAQ
+++ b/FAQ
@@ -173,22 +173,17 @@ Q: Should userspace or kernel be upgraded first to minimize downtime?
 Q: What features are not available in the Open vSwitch kernel datapath
    that ships as part of the upstream Linux kernel?
 
-A: The kernel module in upstream Linux 3.3 and later does not include
-   tunnel virtual ports, that is, interfaces with type "gre",
-   "ipsec_gre", "gre64", "ipsec_gre64", "vxlan", or "lisp".  It is
-   possible to create tunnels in Linux and attach them to Open vSwitch
-   as system devices.  However, they cannot be dynamically created
-   through the OVSDB protocol or set the tunnel ids as a flow action.
-
-   Work is in progress in adding tunnel virtual ports to the upstream
-   Linux version of the Open vSwitch kernel module.  For now, if you
-   need these features, use the kernel module from the Open vSwitch
+A: The kernel module in upstream Linux does not include support for
+   LISP. Work is in progress to add support for LISP to the upstream
+   Linux version of the Open vSwitch kernel module. For now, if you
+   need this feature, use the kernel module from the Open vSwitch
    distribution instead of the upstream Linux kernel module.
 
-   The upstream kernel module does not include patch ports, but this
-   only matters for Open vSwitch 1.9 and earlier, because Open vSwitch
-   1.10 and later implement patch ports without using this kernel
-   feature.
+   Certain features require kernel support to function or to have
+   reasonable performance. If the ovs-vswitchd log file indicates that
+   a feature is not supported, consider upgrading to a newer upstream
+   Linux release or using the kernel module paired with the userspace
+   distribution.
 
 Q: What features are not available when using the userspace datapath?
 
@@ -646,6 +641,17 @@ A: In version 1.9.0, OVS switched to using a single datapath that is
    shared by all bridges of that type.  The "ovs-appctl dpif/*"
    commands provide similar functionality that is scoped by the bridge.
 
+Q: I created a GRE port using ovs-vsctl so why can't I send traffic or
+   see the port in the datapath?
+
+A: On Linux kernels before 3.11, the OVS GRE module and Linux GRE module
+   cannot be loaded at the same time. It is likely that on your system the
+   Linux GRE module is already loaded and blocking OVS (to confirm, check
+   dmesg for errors regarding GRE registration). To fix this, unload all
+   GRE modules that appear in lsmod as well as the OVS kernel module. You
+   can then reload the OVS module following the directions in INSTALL,
+   which will ensure that dependencies are satisfied.
+
 
 Quality of Service (QoS)
 ------------------------
@@ -723,6 +729,19 @@ A: Did you install OpenFlow flows that use your queues?  This is the
 
    Refer to the previous question for an example.
 
+Q: I'd like to take advantage of some QoS feature that Open vSwitch
+   doesn't yet support.  How do I do that?
+
+A: Open vSwitch does not implement QoS itself.  Instead, it can
+   configure some, but not all, of the QoS features built into the
+   Linux kernel.  If you need some QoS feature that OVS cannot
+   configure itself, then the first step is to figure out whether
+   Linux QoS supports that feature.  If it does, then you can submit a
+   patch to support Open vSwitch configuration for that feature, or
+   you can use "tc" directly to configure the feature in Linux.  (If
+   Linux QoS doesn't support the feature you want, then first you have
+   to add that support to Linux.)
+
 Q: I configured QoS, correctly, but my measurements show that it isn't
    working as well as I expect.
 
@@ -1074,7 +1093,7 @@ A: Open vSwitch 1.9 and earlier support only OpenFlow 1.0 (plus
 
        ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow12,OpenFlow13
 
-   Open vSwitch version 1.12 and later will have experimental support
+   Open vSwitch version 2.0 and later will have experimental support
    for OpenFlow 1.1, 1.2, and 1.3.  On these versions of Open vSwitch,
    the following command enables OpenFlow 1.0, 1.1, 1.2, and 1.3 on
    bridge br0:
@@ -1092,6 +1111,27 @@ A: Open vSwitch 1.9 and earlier support only OpenFlow 1.0 (plus
    When support for a given OpenFlow version is solidly implemented,
    Open vSwitch will enable that version by default.
 
+Q: Does Open vSwitch support MPLS?
+
+A: Before version 1.11, Open vSwitch did not support MPLS.  That is,
+   these versions can match on MPLS Ethernet types, but they cannot
+   match, push, or pop MPLS labels, nor can they look past MPLS labels
+   into the encapsulated packet.
+
+   Open vSwitch versions 1.11, 2.0, and 2.1 have very minimal support
+   for MPLS.  With the userspace datapath only, these versions can
+   match, push, or pop a single MPLS label, but they still cannot look
+   past MPLS labels (even after popping them) into the encapsulated
+   packet.  Kernel datapath support is unchanged from earlier
+   versions.
+
+   Open vSwitch version 2.2 will be able to match, push, or pop up to
+   3 MPLS labels.  Looking past MPLS labels into the encapsulated
+   packet will still be unsupported.  Both userspace and kernel
+   datapaths will be supported, but MPLS processing always happens in
+   userspace either way, so kernel datapath performance will be
+   disappointing.
+
 Q: I'm getting "error type 45250 code 0".  What's that?
 
 A: This is a Open vSwitch extension to OpenFlow error codes.  Open