Open vSwitch implementation relies on the new ovs_lib OVSBridge functions:
-* create_qos_bw_limit_for_port
-* get_qos_bw_limit_for_port
-* del_qos_bw_limit_for_port
+* get_egress_bw_limit_for_port
+* create_egress_bw_limit_for_port
+* delete_egress_bw_limit_for_port
-An egress bandwidth limit is effectively configured on the port by creating a
-single QoS queue with min-rate=rule.max_kbps, max-rate=rule.max_kbps and
-burst=rule.max_burst_kbps. Then a linux-htb QoS policy is defined on the port,
-attached to the queue.
-
-HTB queues are supported at least in all 2.x versions of Open vSwitch.
-
-More details about HTB in `the blog post
-<https://virtualandy.wordpress.com/2013/04/29/deep-dive-htb-rate-limiting-qos-on-with-open-vswitch-and-xenserver/>`_.
+An egress bandwidth limit is effectively configured on the port by setting
+the port Interface parameters ingress_policing_rate and
+ingress_policing_burst.
+That approach is less flexible than linux-htb, Queues and OvS QoS profiles,
+which we may explore in the future, but which will need to be used in
+combination with openflow rules.
+ SR-IOV
+ ~~~~~~
+
+ SR-IOV bandwidth limit implementation relies on the new pci_lib function:
+
+ * set_vf_max_rate
+
+ As the name of the function suggests, the limit is applied on a Virtual
+ Function (VF).
+
+ ip link interface has the following limitation for bandwidth limit: it uses
+ Mbps as units of bandwidth measurement, not kbps, and does not support float
+ numbers. So in case the limit is set to something less than 1000 kbps, it's set
+ to 1 Mbps only. If the limit is set to something that does not divide to 1000
+ kbps chunks, then the effective limit is rounded to the nearest integer Mbps
+ value.
+
+
Configuration
=============