[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