FAQ: Add QoS section.

Signed-off-by: Ben Pfaff <blp@nicira.com>

FAQ

@@ -455,6 +455,110 @@ A: In version 1.9.0, OVS switched to using a single datapath that is
    commands provide similar functionality that is scoped by the bridge.
 
 
+Quality of Service (QoS)
+------------------------
+
+Q: How do I configure Quality of Service (QoS)?
+
+A: Suppose that you want to set up bridge br0 connected to physical
+   Ethernet port eth0 (a 1 Gbps device) and virtual machine interfaces
+   vif1.0 and vif2.0, and that you want to limit traffic from vif1.0
+   to eth0 to 10 Mbps and from vif2.0 to eth0 to 20 Mbps.  Then, you
+   could configure the bridge this way:
+
+       ovs-vsctl -- \
+           add-br br0 -- \
+	   add-port br0 eth0 -- \
+	   add-port br0 vif1.0 -- set interface vif1.0 ofport_request=5 -- \
+	   add-port br0 vif2.0 -- set interface vif2.0 ofport_request=6 -- \
+	   set port eth0 qos=@newqos -- \
+	   --id=@newqos create qos type=linux-htb \
+               other-config:max-rate=1000000000 \
+	       queues:123=@vif10queue \
+	       queues:234=@vif20queue -- \
+           --id=@vif10queue create queue other-config:max-rate=10000000 -- \
+           --id=@vif20queue create queue other-config:max-rate=20000000
+
+   At this point, bridge br0 is configured with the ports and eth0 is
+   configured with the queues that you need for QoS, but nothing is
+   actually directing packets from vif1.0 or vif2.0 to the queues that
+   we have set up for them.  That means that all of the packets to
+   eth0 are going to the "default queue", which is not what we want.
+
+   We use OpenFlow to direct packets from vif1.0 and vif2.0 to the
+   queues reserved for them:
+
+       ovs-ofctl add-flow br0 in_port=5,actions=set_queue:123,normal
+       ovs-ofctl add-flow br0 in_port=6,actions=set_queue:234,normal
+
+   Each of the above flows matches on the input port, sets up the
+   appropriate queue (123 for vif1.0, 234 for vif2.0), and then
+   executes the "normal" action, which performs the same switching
+   that Open vSwitch would have done without any OpenFlow flows being
+   present.  (We know that vif1.0 and vif2.0 have OpenFlow port
+   numbers 5 and 6, respectively, because we set their ofport_request
+   columns above.  If we had not done that, then we would have needed
+   to find out their port numbers before setting up these flows.)
+
+   Now traffic going from vif1.0 or vif2.0 to eth0 should be
+   rate-limited.
+
+   By the way, if you delete the bridge created by the above commands,
+   with:
+
+       ovs-vsctl del-br br0
+
+   then that will leave one unreferenced QoS record and two
+   unreferenced Queue records in the Open vSwich database.  One way to
+   clear them out, assuming you don't have other QoS or Queue records
+   that you want to keep, is:
+
+       ovs-vsctl -- --all destroy QoS -- --all destroy Queue
+
+Q: I configured Quality of Service (QoS) in my OpenFlow network by
+   adding records to the QoS and Queue table, but the results aren't
+   what I expect.
+
+A: Did you install OpenFlow flows that use your queues?  This is the
+   primary way to tell Open vSwitch which queues you want to use.  If
+   you don't do this, then the default queue will be used, which will
+   probably not have the effect you want.
+
+   Refer to the previous question for an example.
+
+Q: I configured QoS, correctly, but my measurements show that it isn't
+   working as well as I expect.
+
+A: With the Linux kernel, the Open vSwitch implementation of QoS has
+   two aspects:
+
+       - Open vSwitch configures a subset of Linux kernel QoS
+         features, according to what is in OVSDB.  It is possible that
+         this code has bugs.  If you believe that this is so, then you
+         can configure the Linux traffic control (QoS) stack directly
+         with the "tc" program.  If you get better results that way,
+         you can send a detailed bug report to bugs@openvswitch.org.
+
+         It is certain that Open vSwitch cannot configure every Linux
+         kernel QoS feature.  If you need some feature that OVS cannot
+         configure, then you can also use "tc" directly (or add that
+         feature to OVS).
+
+       - The Open vSwitch implementation of OpenFlow allows flows to
+         be directed to particular queues.  This is pretty simple and
+         unlikely to have serious bugs at this point.
+
+   However, most problems with QoS on Linux are not bugs in Open
+   vSwitch at all.  They tend to be either configuration errors
+   (please see the earlier questions in this section) or issues with
+   the traffic control (QoS) stack in Linux.  The Open vSwitch
+   developers are not experts on Linux traffic control.  We suggest
+   that, if you believe you are encountering a problem with Linux
+   traffic control, that you consult the tc manpages (e.g. tc(8),
+   tc-htb(8), tc-hfsc(8)), web resources (e.g. http://lartc.org/), or
+   mailing lists (e.g. http://vger.kernel.org/vger-lists.html#netdev).
+
+
 VLANs
 -----