summaryrefslogtreecommitdiff
path: root/FAQ.md
diff options
context:
space:
mode:
Diffstat (limited to 'FAQ.md')
-rw-r--r--FAQ.md64
1 files changed, 15 insertions, 49 deletions
diff --git a/FAQ.md b/FAQ.md
index 787c67dee..5a09d1344 100644
--- a/FAQ.md
+++ b/FAQ.md
@@ -1970,55 +1970,21 @@ 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.
-
- Note that the packet buffering support is deprecated in OVS 2.6
- release, and will be removed in OVS 2.7. After the change OVS
- always sends the 'buffer_id' as 0xffffffff in "packet-in" messages
- and will send an error response if any other value of this field is
- included in "packet-out" and "flow mod" sent by a controller.
- Controllers are already expected to work properly in cases where
- the switch can not buffer packets, so this change should not affect
- existing users.
+### Q: My controller complains that OVS is not buffering packets.
+ What's going on?
+
+A: "Packet buffering" is an optional OpenFlow feature, and controllers
+ should detect how many "buffers" an OpenFlow switch implements. It
+ was recently noticed that OVS implementation of the buffering
+ feature was not compliant to OpenFlow specifications. Rather than
+ fix it and risk controller incompatibility, the buffering feature
+ is removed as of OVS 2.7. Controllers are already expected to work
+ properly in cases where the switch can not buffer packets, but
+ sends full packets in "packet-in" messages instead, so this change
+ should not affect existing users. After the change OVS always
+ sends the 'buffer_id' as 0xffffffff in "packet-in" messages and
+ will send an error response if any other value of this field is
+ included in a "packet-out" or a "flow mod" sent by a controller.
### Q: How does OVS divide flows among buckets in an OpenFlow "select" group?