Documentation/faq/qos.rst

   1 ..
   2       Licensed under the Apache License, Version 2.0 (the "License"); you may
   3       not use this file except in compliance with the License. You may obtain
   4       a copy of the License at
   5
   6           http://www.apache.org/licenses/LICENSE-2.0
   7
   8       Unless required by applicable law or agreed to in writing, software
   9       distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
  10       WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
  11       License for the specific language governing permissions and limitations
  12       under the License.
  13
  14       Convention for heading levels in Open vSwitch documentation:
  15
  16       =======  Heading 0 (reserved for the title in a document)
  17       -------  Heading 1
  18       ~~~~~~~  Heading 2
  19       +++++++  Heading 3
  20       '''''''  Heading 4
  21
  22       Avoid deeper levels because they do not render well.
  23
  24 ========================
  25 Quality of Service (QoS)
  26 ========================
  27
  28 Q: Does OVS support Quality of Service (QoS)?
  29
  30     A: Yes.  For traffic that egresses from a switch, OVS supports traffic
  31     shaping; for traffic that ingresses into a switch, OVS support policing.
  32     Policing is a simple form of quality-of-service that simply drops packets
  33     received in excess of the configured rate.  Due to its simplicity, policing
  34     is usually less accurate and less effective than egress traffic shaping,
  35     which queues packets.
  36
  37     Keep in mind that ingress and egress are from the perspective of the
  38     switch.  That means that egress shaping limits the rate at which traffic is
  39     allowed to transmit from a physical interface, but not the rate at which
  40     traffic will be received on a virtual machine's VIF.  For ingress policing,
  41     the behavior is the opposite.
  42
  43 Q: How do I configure egress traffic shaping?
  44
  45     A: Suppose that you want to set up bridge br0 connected to physical
  46     Ethernet port eth0 (a 1 Gbps device) and virtual machine interfaces vif1.0
  47     and vif2.0, and that you want to limit traffic from vif1.0 to eth0 to 10
  48     Mbps and from vif2.0 to eth0 to 20 Mbps.  Then, you could configure the
  49     bridge this way::
  50
  51         $ ovs-vsctl -- \
  52           add-br br0 -- \
  53           add-port br0 eth0 -- \
  54           add-port br0 vif1.0 -- set interface vif1.0 ofport_request=5 -- \
  55           add-port br0 vif2.0 -- set interface vif2.0 ofport_request=6 -- \
  56           set port eth0 qos=@newqos -- \
  57           --id=@newqos create qos type=linux-htb \
  58               other-config:max-rate=1000000000 \
  59               queues:123=@vif10queue \
  60               queues:234=@vif20queue -- \
  61           --id=@vif10queue create queue other-config:max-rate=10000000 -- \
  62           --id=@vif20queue create queue other-config:max-rate=20000000
  63
  64     At this point, bridge br0 is configured with the ports and eth0 is
  65     configured with the queues that you need for QoS, but nothing is actually
  66     directing packets from vif1.0 or vif2.0 to the queues that we have set up
  67     for them.  That means that all of the packets to eth0 are going to the
  68     "default queue", which is not what we want.
  69
  70     We use OpenFlow to direct packets from vif1.0 and vif2.0 to the queues
  71     reserved for them::
  72
  73         $ ovs-ofctl add-flow br0 in_port=5,actions=set_queue:123,normal
  74         $ ovs-ofctl add-flow br0 in_port=6,actions=set_queue:234,normal
  75
  76     Each of the above flows matches on the input port, sets up the appropriate
  77     queue (123 for vif1.0, 234 for vif2.0), and then executes the "normal"
  78     action, which performs the same switching that Open vSwitch would have done
  79     without any OpenFlow flows being present.  (We know that vif1.0 and vif2.0
  80     have OpenFlow port numbers 5 and 6, respectively, because we set their
  81     ofport_request columns above.  If we had not done that, then we would have
  82     needed to find out their port numbers before setting up these flows.)
  83
  84     Now traffic going from vif1.0 or vif2.0 to eth0 should be rate-limited.
  85
  86     By the way, if you delete the bridge created by the above commands, with::
  87
  88         $ ovs-vsctl del-br br0
  89
  90     then that will leave one unreferenced QoS record and two unreferenced Queue
  91     records in the Open vSwich database.  One way to clear them out, assuming
  92     you don't have other QoS or Queue records that you want to keep, is::
  93
  94         $ ovs-vsctl -- --all destroy QoS -- --all destroy Queue
  95
  96     If you do want to keep some QoS or Queue records, or the Open vSwitch you
  97     are using is older than version 1.8 (which added the ``--all`` option),
  98     then you will have to destroy QoS and Queue records individually.
  99
 100 Q: How do I configure ingress policing?
 101
 102     A: A policing policy can be configured on an interface to drop packets that
 103     arrive at a higher rate than the configured value.  For example, the
 104     following commands will rate-limit traffic that vif1.0 may generate to
 105     10Mbps:
 106
 107         $ ovs-vsctl set interface vif1.0 ingress_policing_rate=10000
 108         $ ovs-vsctl set interface vif1.0 ingress_policing_burst=8000
 109
 110     Traffic policing can interact poorly with some network protocols and can
 111     have surprising results.  The "Ingress Policing" section of
 112     ovs-vswitchd.conf.db(5) discusses the issues in greater detail.
 113
 114 Q: I configured Quality of Service (QoS) in my OpenFlow network by adding
 115 records to the QoS and Queue table, but the results aren't what I expect.
 116
 117     A: Did you install OpenFlow flows that use your queues?  This is the
 118     primary way to tell Open vSwitch which queues you want to use.  If you
 119     don't do this, then the default queue will be used, which will probably not
 120     have the effect you want.
 121
 122     Refer to the previous question for an example.
 123
 124 Q: I'd like to take advantage of some QoS feature that Open vSwitch doesn't yet
 125 support.  How do I do that?
 126
 127     A: Open vSwitch does not implement QoS itself.  Instead, it can configure
 128     some, but not all, of the QoS features built into the Linux kernel.  If you
 129     need some QoS feature that OVS cannot configure itself, then the first step
 130     is to figure out whether Linux QoS supports that feature.  If it does, then
 131     you can submit a patch to support Open vSwitch configuration for that
 132     feature, or you can use "tc" directly to configure the feature in Linux.
 133     (If Linux QoS doesn't support the feature you want, then first you have to
 134     add that support to Linux.)
 135
 136 Q: I configured QoS, correctly, but my measurements show that it isn't working
 137 as well as I expect.
 138
 139     A: With the Linux kernel, the Open vSwitch implementation of QoS has two
 140     aspects:
 141
 142     - Open vSwitch configures a subset of Linux kernel QoS features, according
 143       to what is in OVSDB.  It is possible that this code has bugs.  If you
 144       believe that this is so, then you can configure the Linux traffic control
 145       (QoS) stack directly with the "tc" program.  If you get better results
 146       that way, you can send a detailed bug report to bugs@openvswitch.org.
 147
 148       It is certain that Open vSwitch cannot configure every Linux kernel QoS
 149       feature.  If you need some feature that OVS cannot configure, then you
 150       can also use "tc" directly (or add that feature to OVS).
 151
 152     - The Open vSwitch implementation of OpenFlow allows flows to be directed
 153       to particular queues.  This is pretty simple and unlikely to have serious
 154       bugs at this point.
 155
 156     However, most problems with QoS on Linux are not bugs in Open vSwitch at
 157     all.  They tend to be either configuration errors (please see the earlier
 158     questions in this section) or issues with the traffic control (QoS) stack
 159     in Linux.  The Open vSwitch developers are not experts on Linux traffic
 160     control.  We suggest that, if you believe you are encountering a problem
 161     with Linux traffic control, that you consult the tc manpages (e.g. tc(8),
 162     tc-htb(8), tc-hfsc(8)), web resources (e.g. http://lartc.org/), or mailing
 163     lists (e.g. http://vger.kernel.org/vger-lists.html#netdev).
 164
 165 Q: Does Open vSwitch support OpenFlow meters?
 166
 167     A: Open vSwitch 2.0 added OpenFlow protocol support for OpenFlow meters.
 168     Open vSwitch 2.7 implemented meters in the userspace datapath.  Open
 169     vSwitch 2.10 implemented meters in the Linux kernel datapath.