Hardware-assisted HQoS is an alternative to traditional HQoS which is described in Scheduler QoS Policies.
This model improves reaction time and provides more accurate control of downstream bursts for aggregate rate enforcement. It is based on:
Hardware-assisted HQoS is based on hardware aggregate shapers, which provide enforcement of aggregate rates for a group of queues in the hardware. In the FP4-based chipset, hardware aggregate shapers are available at egress only. The queues are allocated in a block of eight to each hardware aggregate shaper.
Hardware aggregate shapers are controlled by three parameters:
Traffic is scheduled from the queues in a strict priority order based on the hardware scheduling priority assigned to each queue. This can be controlled using the sched-class command. There are 6 scheduling-classes available.
Hardware aggregate shapers do not need software-based HQoS to modify the oper-PIR of the queues to enforce an aggregate rate. This results in a significantly faster reaction time compared to traditional HQoS based on virtual schedulers.
The following examples show the configuration of a hardware aggregate shaper on a subscriber profile. The configuration is similar to traditional QoS configuration.
Classic
MD-CLI
Hardware-assisted HQoS introduces a new way to implement queue-weight based bandwidth distribution.
The queue hardware-enforced FIR rate is used to provide weighted fair access between queues assigned to the same hardware scheduling priority (scheduling class) within a hardware aggregate shaper, by dynamically changing the queue's hardware scheduling priority as shown in Figure 35.
Every queue in a hardware aggregate shaper is described by the following parameters:
The aggregate shaper weight algorithm operates similarly to the virtual-scheduler HQoS algorithm, meaning that the offered load of the queues at the same scheduling class is weighted against the aggregate shaper weight to determine the FIR, which then controls hardware-based scheduling.
A FIR-based algorithm is more efficient and more responsive to dynamic changes in offered load. The PIR is not adjusted, which prevents aggregate-rate underruns in case of a sudden change in an incoming load for some queues.
When hardware aggregate shapers are enabled, CIR as a queue parameter is ignored.The queue-frame-based-accounting setting is also ignored when hardware aggregate shaping is configured.
The following examples show a SAP egress policy configuration. Weight-based bandwidth distribution in this example is only between queue 1 and queue 2. These queues are both assigned to the same scheduling class (sched-class 3), while queue 3 has a higher priority scheduling-class (sched-class 5) and is served with strict priority.
Classic
MD-CLI
A hardware aggregate shaper scheduler policy is an alternative to a port scheduler. A hardware aggregate shaper policy can only be assigned at the vport level.
A virtual vport scheduler is added to implement a bandwidth-distribution software algorithm to handle traffic oversubscription by subscriber hardware aggregate shapers at a vport.
The vport represents a downstream bandwidth constraint and therefore the algorithm enforces a maximum rate, which is an Ethernet on-the-wire rate. This algorithm also implements the logic to distribute the available bandwidth at the vport to its child hardware aggregate shapers.
The algorithm performs a similar function to the existing HQoS port scheduler, however, instead of modifying the oper-PIRs of queues, policers, or schedulers, it modifies the oper-PIR of the hardware aggregate shapers connected to it, and consequently triggers recalculation of the individual queue’s FIR, if required.
Figure 36 shows the functionality of a hardware aggregate shaper scheduler, including all parameters which the user can set. This architecture allows the user full flexibility to define SLA models.
The generic design in Figure 36 can be mapped into two SLA models as shown in Figure 37. Both SLA models show two subscriber categories for simplicity, but this model can be extended to any number of subscriber categories.
The SLA model (a) in Figure 37 shows the overall vport bandwidth distribution between gold and white categories in a ratio of 8:1 regardless of the number of subscribers in either category, and assuming that traffic passing through queue 7 for both subscriber categories is delay-critical but not significant in terms of volume.
The SLA model (b) in Figure 37 guarantees that the ratio between any gold and any white subscriber is 8:1. The overall bandwidth distribution between gold and white categories, however, it depends on the number of subscribers in each category.
SLA models are a design goal and must be tested to guarantee the expected behavior. SR OS configuration allows a user to construct other models by combining concepts and parameters in other ways. The resulting behavior is subject to a specific configuration and offered load.
When alternative SLA models are configured, the following considerations apply.
The hardware aggregate scheduler policy implements a congestion threshold that is used to trigger software recalculation. If the overall offered load for a given vport is below this threshold (expressed as a percentage of the vport aggregate rate), the software recalculation of all parameters is not performed to save CPU resources because it is assumed that all offered traffic passes through.
Similarly to a port scheduler policy, a hardware aggregate rate scheduler policy supports a monitor threshold that detects congestion. The configuration and operation are identical as described in Scheduler QoS Policies.
The following example hardware aggregate shaper scheduler policy describes the SLA model from Figure 37 (a).
Classic
MD-CLI
The FP4-based chipset supports all existing QoS features including software-driven HQoS and hardware-assisted HQoS. The following sections describe how these features interact.
Hardware aggregate shapers are applicable to subscriber management only. This means that for other objects, such as SAP and queue-groups, only software-driven HQoS can be used. Hardware aggregate shapers and software-driven HQoS can coexist on the same FP.
Classic CLI
In MD-CLI, it is recommended (but not required) to execute these commands in a single commit.
After these commands are applied to a specific FP, all subscriber hosts created on this FP uses hardware aggregate shaping and any traditional HQoS-related configuration is ignored.
SAP and queue group objects always use traditional HQoS configuration whether or not they are created on the same or different ports as subscriber hosts. Any hardware aggregate shaping configuration associated with a SAP or queue group is ignored.
LAGs using link or port-fair adapt-qos modes support hardware aggregate shapers; LAGs in distribute mode do not.
When a LAG spans multiple FPs, only one set of subscriber queues is created per FP (on the elected port), consequently there is only one hardware aggregate shaper created per FP for subscribers on a LAG. Egress subscriber traffic is hashed only to the active FP for that subscriber.
In these cases, the vport bandwidth distribution algorithm only manages the hardware aggregate shaper associated with the elected LAG port on the active FP. All hardware aggregate shapers not associated with the active FP have their oper PIRs set to their admin PIRs. This eliminates the need for the vport bandwidth distribution algorithm to manage the non-active hardware aggregate shapers and reduces the processing required.
It is recommended that for LAGs spanning different FPs, all participating FPs are configured to use hardware aggregate shapers. However, there are no checks to flag a mismatch of configuration between all member FPs.
In traditional HQoS for subscribers it is possible to define the subscriber aggregate rates, which should be adjusted with respect to last-mile encapsulation using the following command:
Classic: config>subscriber-mgmt>sub-profile>egress>encap-offset type
MD-CLI: configure subscriber-mgmt sub-profile name egress qos encap-offset type
There are multiple types of encapsulations available.
This causes the offered-load measurements and operational-rate values to be normalized with respect to encap-offset and avg-frame-overhead values. Based on these values, the corresponding operational rates are calculated, and the adjustment is transparent to users.
For hardware aggregate shapers, the shapers and FIR distribution rely on hardware enforcement while the hardware aggregate shaper scheduler policy is software-based. Because of this, queue weights in FIR calculations are normalized with respect to the encap-offset value. Therefore, in show commands related to hardware aggregate shapers the queue weights may differ from the configured values due to such adjustments.
However, weights in hardware aggregate shaper scheduler policy remains as configured, because offered-load and rate calculations in software take into account last-mile overhead in the same way as in software-driven HQoS.
If no encap-offset is set for the given hardware aggregate shaper, the on-the-wire-rate is enforced. Considering that offered-rates do not account for on-the-wire Ethernet overhead, the QoS software adjusts the aggregate rate of the shaper based on the average frame overhead calculated during HQoS calculation.
The following configuration parameters are not applicable when hardware aggregate shaping is used: