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

Ben Pfaff blp at nicira.com
Tue Jan 22 18:20:28 UTC 2013


Thanks.  I think I ought to test it before I commit it, so it probably
won't go in before afternoon.

On Tue, Jan 22, 2013 at 10:17:16AM -0800, Justin Pettit wrote:
> Looks good.  Thanks!
> 
> --Justin
> 
> 
> On Jan 22, 2013, at 10:15 AM, Ben Pfaff <blp at nicira.com> wrote:
> 
> > 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