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 <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
