[ovs-dev] [PATCH] FAQ: Add QoS section.

Ben Pfaff blp at nicira.com
Tue Jan 22 18:15:44 UTC 2013


On Tue, Jan 22, 2013 at 10:06:12AM -0800, Justin Pettit wrote:
> I hope you had this section queued up for review, and not that you
> whipped it up in the minute since you responded to that QoS question
> on ovs-discuss.  I already feel inadequate enough.

It took me about half an hour to write it this morning.  I hope that it
will save me more than half an hour in 2013.

> > +A: Suppose that you want to set up bridge br0 connected to physical
> > +   Ethernet port eth0 (a 1 Gbps device) and virtual machine interface
> 
> s/interface/interfaces/

Thanks, fixed.

> > +   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=1 -- \
> > +	   add-port br0 vif2.0 -- set interface vif2.0 ofport_request=2 -- \
> 
> I haven't run the commands either, but I think these ports you
> requested may have been given to br0 and eth0 already, since we try to
> allocate from 1.  (If you update these ones, there are a couple of
> places later on that also reference these OpenFlow port numbers.)

I would think that explicit requests should take precedence over
defaults, but I think the actual implementation may be weak in that
regard.

I changed them to 5 and 6.  (I'm trying to use numbers that are not
close to 1.0 or 2.0 (or 10 or 20) to keep readers from thinking that the
actual numbers are significant.)

Here's a revised version, still not tested.

--8<--------------------------cut here-------------------------->8--

From: Ben Pfaff <blp at nicira.com>
Date: Tue, 22 Jan 2013 10:14:13 -0800
Subject: [PATCH] FAQ: Add QoS section.

Signed-off-by: Ben Pfaff <blp at nicira.com>
---
 FAQ |  104 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 104 insertions(+)

diff --git a/FAQ b/FAQ
index ab1c1cc..ab4338e 100644
--- a/FAQ
+++ b/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=linus-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 at 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
 -----
 
-- 
1.7.10.4




More information about the dev mailing list