I found one typo in testing:
diff --git a/FAQ b/FAQ
index ab4338e..72a1479 100644
--- a/FAQ
+++ b/FAQ
@@ -472,7 +472,7 @@ A: Suppose that you want to set up bridge br0 connected to
physical
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 \
+ --id=@newqos create qos type=linux-htb \
other-config:max-rate=1000000000 \
queues:123=@vif10queue \
queues:234=@vif20queue -- \
With that fixed, I applied this to master.
On Tue, Jan 22, 2013 at 10:20:28AM -0800, Ben Pfaff wrote:
> 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
