dp-packet: Remove ofpbuf dependency.
[cascardo/ovs.git] / FAQ.md
diff --git a/FAQ.md b/FAQ.md
index 458e07a..5ee529c 100644 (file)
--- a/FAQ.md
+++ b/FAQ.md
@@ -122,7 +122,7 @@ A: All official releases have been through a comprehensive testing
    LTS release, we will provide an updated release that includes the
    fix.  Releases that are not LTS may not be fixed and may just be
    supplanted by the next major release.  The current LTS release is
-   1.9.x.
+   2.3.x.
 
 ### Q: What Linux kernel versions does each Open vSwitch release work with?
 
@@ -147,6 +147,7 @@ A: The following table lists the Linux kernel versions against which the
 |    2.0.x     | 2.6.32 to 3.10
 |    2.1.x     | 2.6.32 to 3.11
 |    2.3.x     | 2.6.32 to 3.14
+|    2.4.x     | 2.6.32 to 3.19
 
    Open vSwitch userspace should also work with the Linux kernel module
    built into Linux 3.3 and later.
@@ -215,8 +216,9 @@ A: Tunnel virtual ports are not supported, as described in the
 
 ### Q: What Linux kernel versions does IPFIX flow monitoring work with?
 
-A: IPFIX flow monitoring requires the Linux kernel module from Open
-   vSwitch version 1.10.90 or later.
+A: IPFIX flow monitoring requires the Linux kernel module from Linux
+   3.10 or later, or the out-of-tree module from Open vSwitch version
+   1.10.90 or later.
 
 ### Q: Should userspace or kernel be upgraded first to minimize downtime?
 
@@ -750,6 +752,26 @@ A: It's an expected behaviour.
        ovs-vsctl add-port br0 p1 -- \
            set interface p1 type=internal
 
+### Q: I want to add thousands of ports to an Open vSwitch bridge, but
+   it takes too long (minutes or hours) to do it with ovs-vsctl.  How
+   can I do it faster?
+
+A: If you add them one at a time with ovs-vsctl, it can take a long
+   time to add thousands of ports to an Open vSwitch bridge.  This is
+   because every invocation of ovs-vsctl first reads the current
+   configuration from OVSDB.  As the number of ports grows, this
+   starts to take an appreciable amount of time, and when it is
+   repeated thousands of times the total time becomes significant.
+
+   The solution is to add the ports in one invocation of ovs-vsctl (or
+   a small number of them).  For example, using bash:
+
+       ovs-vsctl add-br br0
+       cmds=; for i in {1..5000}; do cmds+=" -- add-port br0 p$i"; done
+       ovs-vsctl $cmds
+
+   takes seconds, not minutes or hours, in the OVS sandbox environment.
+
 Quality of Service (QoS)
 ------------------------
 
@@ -1162,9 +1184,9 @@ A: VXLAN stands for Virtual eXtensible Local Area Network, and is a means
    to solve the scaling challenges of VLAN networks in a multi-tenant
    environment. VXLAN is an overlay network which transports an L2 network
    over an existing L3 network. For more information on VXLAN, please see
-   the IETF draft available here:
+   RFC 7348:
 
-   http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-03
+   http://tools.ietf.org/html/rfc7348
 
 ### Q: How much of the VXLAN protocol does Open vSwitch currently support?
 
@@ -1622,6 +1644,47 @@ A: Reconfiguring your bridge can change your bridge's datapath-id because
 
       ovs-vsctl set bridge br0 other-config:datapath-id=0123456789abcdef
 
+### Q: My controller is getting errors about "buffers".  What's going on?
+
+A: When a switch sends a packet to an OpenFlow controller using a
+   "packet-in" message, it can also keep a copy of that packet in a
+   "buffer", identified by a 32-bit integer "buffer_id".  There are
+   two advantages to buffering.  First, when the controller wants to
+   tell the switch to do something with the buffered packet (with a
+   "packet-out" OpenFlow request), it does not need to send another
+   copy of the packet back across the OpenFlow connection, which
+   reduces the bandwidth cost of the connection and improves latency.
+   This enables the second advantage: the switch can optionally send
+   only the first part of the packet to the controller (assuming that
+   the switch only needs to look at the first few bytes of the
+   packet), further reducing bandwidth and improving latency.
+
+   However, buffering introduces some issues of its own.  First, any
+   switch has limited resources, so if the controller does not use a
+   buffered packet, the switch has to decide how long to keep it
+   buffered.  When many packets are sent to a controller and buffered,
+   Open vSwitch can discard buffered packets that the controller has
+   not used after as little as 5 seconds.  This means that
+   controllers, if they make use of packet buffering, should use the
+   buffered packets promptly.  (This includes sending a "packet-out"
+   with no actions if the controller does not want to do anything with
+   a buffered packet, to clear the packet buffer and effectively
+   "drop" its packet.)
+
+   Second, packet buffers are one-time-use, meaning that a controller
+   cannot use a single packet buffer in two or more "packet-out"
+   commands.  Open vSwitch will respond with an error to the second
+   and subsequent "packet-out"s in such a case.
+
+   Finally, a common error early in controller development is to try
+   to use buffer_id 0 in a "packet-out" message as if 0 represented
+   "no buffered packet".  This is incorrect usage: the buffer_id with
+   this meaning is actually 0xffffffff.
+
+   ovs-vswitchd(8) describes some details of Open vSwitch packet
+   buffering that the OpenFlow specification requires implementations
+   to document.
+
 
 Development
 -----------