Port QoS¶
https://blueprints.launchpad.net/dragonflow/+spec/qos-app
This spec describes the design of port QoS of DragonFlow.
Problem Description¶
The QoS of neutron provides a way to attach QoS policies to neutron ports and networks. So we need to develop this feature to support it, but in this patch we only support applying QoS policies to ports.
Proposed Change¶
DragonFlow defines an object called QoS to implement the port QoS. The QoS object has some attributes listed in the followed table:
| Attribute Name | Description |
|---|---|
| id | identify |
| type | type of QoS |
| tenant_id | tenant ID of QoS object owner |
| description | QoS description |
| qos_policy | QoS policy object |
The qos_policy includes some attributes listed in the followed table:
| Attribute Name | Description |
|---|---|
| tx_averateLimit | bandwidth limit of egress direction |
| tx_burstSize | burst size of egress direction |
| rx_averateLimit | bandwidth limit of ingress direction |
| rx_burstSize | burst size of ingress direction |
| dscp | Differentiated Services Code Point |
The egress and ingress directions are from the VM’s point of view.
The type of QoS includes “all” and “dscp”. Besides the basic attributes id, type, etc, the QoS may have all of the attributes in the qos_policy when the type of QoS is “all” and only have the dscp attribute in the qos_policy when the type of QoS is “dscp”.
QoS Notification Driver¶
QoS plugin uses “message_queue” as default notification driver. Dragonflow will add a new notification driver named “qos_notification_driver” to deal with the CRUD operations of QoS policies.
If you want to use ML2 as core plugin and use dragonflow as ML2 mech driver, you should edit neutron.conf file to configure “notification_drivers = df_notification_driver” in [QoS] section.
You can see the implement of qos_notification_driver in patch: https://review.openstack.org/#/c/331932/
ML2 Mechanism Driver¶
When port updates related to a QoS, the DragonFlow ML2 driver will save the relationship of port and QoS in DF DB. When port detaches from a QoS, it will delete the relationship.
QoS App¶
The QoS app is a module of local controller which implements the logic of QoS. The app concerns about the QoS updated and port updated northbound events and also cares about the southbound port events which include port created and port removed.
Port Created¶
When the QoS app receives the port created event, it will get the QoS attached to the port from the DB store, then set the tx_burstSize and tx_averateLimit of the QoS to ingress_policing_bust and ingress_policing_rate of the corresponding interface on the OVS for limiting the bandwidth of egress traffic of the port. In addition, the QoS app creates a queue attached to the port and sets the rx_averateLimit and dscp of QoS to other_config and dscp of the queue on the OVS for limiting the bandwidth of ingress traffic of the port.
Port Removed¶
When the QoS app receives the port removed event, it will delete the corresponding QoS configuration of the removed port on the local host, for example, delete the QoS and queue attached to the removed port on the OVS.
Port Updated¶
The port updated event can show three scenarios:
- port applies a QoS
- port applies a new QoS
- port applies no QoS
For scenario 1, the QoS app will set the corresponding configuration of the QoS for the port, the configuration is similar with the description in “Port Created” section above.
For scenario 2, the QoS app will update the configuration according to the new QoS object.
For scenario 3, the QoS app will delete the configuration for the port.
QoS Object Delete¶
It is not permitted to delete the QoS object attached to some ports. If no ports apply the QoS, it can be deleted from the DragonFlow DB.
QoS Object Update¶
When updating the QoS object, the new value of bandwidth will be propagated to all the ports which apply the QoS object.