datapath-windows: Allow NdisSwitchPortTypeSynthetic to be updated

[cascardo/ovs.git] / FAQ.md

diff --git a/FAQ.md b/FAQ.md
index 03e5224..21d4e7a 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
 --------
@@ -198,6 +207,7 @@ A: Support for tunnels was added to the upstream Linux kernel module
 |:--------:|:-------------:
 | GRE      |    3.11
 | VXLAN    |    3.12
+| Geneve   |    3.18
 | LISP     | <not upstream>
 
    If you are using a version of the kernel that is older than the one
@@ -207,6 +217,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 +1206,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 +1757,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?