Looks good. Thanks! --Justin
On Jan 22, 2013, at 10:15 AM, Ben Pfaff <b...@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 <b...@nicira.com> > Date: Tue, 22 Jan 2013 10:14:13 -0800 > Subject: [PATCH] FAQ: Add QoS section. > > Signed-off-by: Ben Pfaff <b...@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 b...@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 > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
