Quality of Service in Contrail

Features of Fabric Interfaces

Fabric interfaces, unlike other interfaces, are always shared. Therefore, fabric interfaces are common property. Consequently, traffic classes and QoS marking on the fabric must be controlled by the system administrator. The administrator might choose to provision different classes of service on the fabric.

In Contrail, classes of service are determined by both of the following:

• Queueing on the fabric interface, including queues, scheduling of queues, and drop policies, and

• forwarding class, a method of marking that controls how packets are sent to the fabric, including marking and identifying which queue to use.

Tenants can define which forwarding class their traffic can use, deciding which packets use which forwarding class. The Contrail QoS configuration object has a mapping table, mapping the incoming DSCP or 802.1p value to the forwarding class mapping.

The QoS configuration can also be applied to a virtual network, an interface, or a network policy.

Testbed.py Parameters

Testbed.py can be used for provisioning Contrail through Releases 3.x.x. Starting with Contrail 4.0, testbed.py can only be used if you are provsioning with SM-Lite. Use parameters in this section if you are using testbed.py for provisioning.

For QoS, the hardware queues (NIC queues) are mapped to logical queues in the agent, using the following keys:

• hardware_q_id—Identifier for the hardware queue.

• logical_queue— Defines the logical queues to map to each hardware queue.

• default—Defines the default hardware queue for QoS when set to True.

Options to define a default hardware queue:

• Set the queue as default, without any logical queue mapping.

  {'hardware_q_id': '1', 'default': 'True'}

• Set the hardware queue as default with logical queue mapping.

  {'hardware_q_id': '6', 'logical_queue':['17-20'], 'default': 'True'}

  content_copy zoom_out_map

           env.qos = {host4: [ {'hardware_q_id': '3', 'logical_queue':['1', '6-10', '12-15']},
                      {'hardware_q_id': '5', 'logical_queue':['2']},
                      {'hardware_q_id': '8', 'logical_queue':['3-5']},
                      {'hardware_q_id': '1', 'default': 'True'}],
             host5: [ {'hardware_q_id': '2', 'logical_queue':['1', '3-8', '10-15']},
                      {'hardware_q_id': '6', 'logical_queue':['17-20'], 'default': 'True'}]
            }
  

The following are the keys for defining QoS priority groups.

• priority_id—Priority group for QoS.

• scheduling—Defines the scheduling algorithm used for the priority group, strict or roundrobin (rr).

• bandwidth—Total hardware queue bandwidth used by priority group.

  Bandwidth cannot be specified if strict scheduling is used for priority group, so set it to 0.

Example: QoS Priority Group

env.qos_niantic = {host4:[
         { 'priority_id': '1', 'scheduling': 'strict', 'bandwidth': '0'},
         { 'priority_id': '2', 'scheduling': 'rr', 'bandwidth': '20'},
         { 'priority_id': '3', 'scheduling': 'rr', 'bandwidth': '10'}],
             host5:[
         { 'priority_id': '1', 'scheduling': 'strict', 'bandwidth': '0'},
         { 'priority_id': '1', 'scheduling': 'rr', 'bandwidth': '30'}]
                  }

QoS Features by Release

QoS features are introduced in the following Contrail releases:

• 3.1—QoS configuration and forwarding classes

• 3.2—queuing

• Not planned—egress marking and queuing

Traffic Originated by a Virtual Machine Interface

• If a VM interface sends an IP packet to another VM in a remote compute node, the DSCP value in the IP header is used to look into the qos-config table, and the tunnel header is marked with DSCP, 802.1p, and MPLS EXP bits as specified by the forwarding class.

• If a VM sends a Layer 2 non-IP packet with an 802.1p value, the 802.1p value is used to look into the qos-config table, and the corresponding forwarding class DSCP, 802.1p, and MPLS EXP value is written to the tunnel header.

• If a VM sends an IP packet to a VM in the same compute node, the DSCP value in the IP header is matched in the qos-config table, and the corresponding forwarding class is used to overwrite the IP header with new DSCP and 802.1p values.

Traffic Destined to a Virtual Machine Interface

For traffic destined to a VMI, if a tunneled packet is received, the tunnel headers are stripped off and the packet is sent to the interface. No marking is done from the outer packet to inner packet.

Traffic from a vhost Interface

The QoS configuration can be applied on IP traffic coming from a vhost interface. The DSCP value in the packet is used to look into the qos-config object specified on the vhost, and the corresponding forwarding class DSCP and 802.1p values are overwritten on the packet.

Traffic from fabric interface

The QoS configuration can be applied while receiving the packet on an Ethernet interface of a compute node, and the corresponding forwarding class DSCP and 802.1p values are overwritten on the packet.

QoS Configuration Priority by Level

The QoS configuration can be specified at different levels.

The levels that can be configured with QoS and their order of priority:

1. in policy

2. on virtual-network

3. on virtual-machine-interface

Hardware Queueing in Linux kernel based vRouter

If Xmit-Packet-Steering (XPS) is enabled, the kernel chooses the queue, from those available in a list of queues. If the kernel selects the queue, packets will not be sent to the vRouter-specified queue.

To disable this mapping:

• have a kernel without CONFIG_XPS option

• write zeros to the mapping file in /sys/class/net//queues/tx-X/xps_cpus .

When this mapping is disabled, the kernel will send packets to the specific hardware queue.

To verify:

See individual queue statistics in the output of 'ethtool -S ' command.