datapath: stt compatibility for RHEL7

[cascardo/ovs.git] / FAQ.md

diff --git a/FAQ.md b/FAQ.md
index 03e5224..ff9f932 100644 (file)
--- a/FAQ.md
+++ b/FAQ.md
@@ -110,6 +110,15 @@ A: You can start by joining the mailing lists and helping to answer
 
    http://openvswitch.org/mlists/
 
+### Q: Why can I no longer connect to my OpenFlow controller or OVSDB
+manager?
+
+A: Starting in OVS 2.4, we switched the default ports to the
+   IANA-specified port numbers for OpenFlow (6633->6653) and OVSDB
+   (6632->6640).  We recommend using these port numbers, but if you
+   cannot, all the programs allow overriding the default port.  See the
+   appropriate man page.
+
 
 Releases
 --------
@@ -164,14 +173,23 @@ A: The following table lists the Linux kernel versions against which the
 
    What should I do?
 
-A: If there is a newer version of Open vSwitch, consider building that
-   one, because it may support the kernel that you are building
-   against.  (To find out, consult the table in the previous answer.)
+A: You have the following options:
+
+   - Use the Linux kernel module supplied with the kernel that you are
+     using.  (See also the following FAQ.)
+
+   - If there is a newer released version of Open vSwitch, consider
+     building that one, because it may support the kernel that you are
+     building against.  (To find out, consult the table in the
+     previous FAQ.)
+
+   - The Open vSwitch "master" branch may support the kernel that you
+     are using, so consider building the kernel module from "master".
 
-   Otherwise, use the Linux kernel module supplied with the kernel
-   that you are using.  All versions of Open vSwitch userspace are
-   compatible with all versions of the Open vSwitch kernel module, so
-   this will also work.  See also the following question.
+  All versions of Open vSwitch userspace are compatible with all
+  versions of the Open vSwitch kernel module, so you do not have to
+  use the kernel module from one source along with the userspace
+  programs from the same source.
 
 ### Q: What features are not available in the Open vSwitch kernel datapath that ships as part of the upstream Linux kernel?
 
@@ -198,7 +216,9 @@ A: Support for tunnels was added to the upstream Linux kernel module
 |:--------:|:-------------:
 | GRE      |    3.11
 | VXLAN    |    3.12
+| Geneve   |    3.18
 | LISP     | <not upstream>
+| STT      | <not upstream>
 
    If you are using a version of the kernel that is older than the one
    listed above, it is still possible to use that tunnel protocol. However,
@@ -207,6 +227,14 @@ A: Support for tunnels was added to the upstream Linux kernel module
    persist after doing this, check to make sure that the module that is
    loaded is the one you expect.
 
+### Q: Why are UDP tunnel checksums not computed for VXLAN or Geneve?
+
+A: Generating outer UDP checksums requires kernel support that was not
+   part of the initial implementation of these protocols. If using the
+   upstream Linux Open vSwitch module, you must use kernel 4.0 or
+   newer. The out-of-tree modules from Open vSwitch release 2.4 and later
+   support UDP checksums.
+
 ### Q: What features are not available when using the userspace datapath?
 
 A: Tunnel virtual ports are not supported, as described in the
@@ -1188,7 +1216,7 @@ A: The configuration for VLANs in the Open vSwitch database (e.g. via
    tags, like this:
 
        ovs-vsctl add-br br0
-       ovs-vsctl set-controller br0 tcp:192.168.0.10:6633
+       ovs-vsctl set-controller br0 tcp:192.168.0.10:6653
        ovs-vsctl add-port br0 eth0
        ovs-vsctl add-port br0 tap0 tag=9
        ovs-vsctl add-port br0 tap1 tag=10
@@ -1739,11 +1767,25 @@ A: Add your new message to "enum ofpraw" and "enum ofptype" in
 
 A: Add new members for your field to "struct flow" in lib/flow.h, and
    add new enumerations for your new field to "enum mf_field_id" in
-   lib/meta-flow.h, following the existing pattern.  Then recompile
-   and fix all of the new warnings, implementing new functionality for
-   the new field or header as needed.  (If you configure with
-   --enable-Werror, as described in [INSTALL.md], then it is
-   impossible to miss any warnings.)
+   lib/meta-flow.h, following the existing pattern.  Also, add support
+   to miniflow_extract() in lib/flow.c for extracting your new field
+   from a packet into struct miniflow.  Then recompile and fix all of
+   the new warnings, implementing new functionality for the new field
+   or header as needed.  (If you configure with --enable-Werror, as
+   described in [INSTALL.md], then it is impossible to miss any
+   warnings.)
+
+   If you want kernel datapath support for your new field, you also
+   need to modify the kernel module for the operating systems you are
+   interested in.  This isn't mandatory, since fields understood only
+   by userspace work too (with a performance penalty), so it's
+   reasonable to start development without it.  If you implement
+   kernel module support for Linux, then the Linux kernel "netdev"
+   mailing list is the place to submit that support first; please read
+   up on the Linux kernel development process separately.  The Windows
+   datapath kernel module support, on the other hand, is maintained
+   within the OVS tree, so patches for that can go directly to
+   ovs-dev.
 
 ### Q: How do I add support for a new OpenFlow action?