MVTX2601
Data Sheet
24
Zarlink Semiconductor Inc.
7.4 Strict Priority and Best Effort
When strict priority is part of the scheduling algorithm, if a queue has even one frame to transmit, it goes first. Two
of our four QoS configurations include strict priority queues. The goal is for strict priority classes to be used for IETF
expedited forwarding (EF), where performance guarantees are required. As we have indicated, it is important that
strict priority traffic be either policed or implicitly bounded, so as to keep from harming other traffic classes.
When best effort is part of the scheduling algorithm, a queue only receives bandwidth when none of the other
classes have any traffic to offer. Two of our four QoS configurations include best effort queues. The goal is for best
effort classes to be used for non-essential traffic, because we provide no assurances about best effort performance.
However, in a typical network setting, much best effort traffic will indeed be transmitted and with an adequate
degree of expediency.
Because we do not provide any delay assurances for best effort traffic, we do not enforce latency by dropping best
effort traffic. Furthermore, because we assume that strict priority traffic is carefully controlled before entering the
MVTX2601, we do not enforce a fair bandwidth partition by dropping strict priority traffic. To summarize, dropping to
enforce bandwidth or delay does not apply to strict priority or best effort queues. We only drop frames from best
effort and strict priority queues when global buffer resources become scarce.
7.5 Weighted Fair Queuing
In some environments – for example, in an environment in which delay assurances are not required, but precise
bandwidth partitioning on small time scales is essential, WFQ may be preferable to a delay-bounded scheduling
discipline. The MVTX2601 provides the user with a WFQ option with the understanding that delay assurances can
not be provided if the incoming traffic pattern is uncontrolled. The user sets four WFQ “weights” such that all
weights are whole numbers and sum to 64. This provides per-class bandwidth partitioning with error within 2%.
In WFQ mode, though we do not assure frame latency, the MVTX2601 still retains a set of dropping rules that helps
to prevent congestion and trigger higher level protocol end-to-end flow control.
As before, when strict priority is combined with WFQ, we do not have special dropping rules for the strict priority
queues, because the input traffic pattern is assumed to be carefully controlled at a prior stage. However, we do
indeed drop frames from SP queues for global buffer management purposes. In addition, queue P0 for a 10/100
port are treated as best effort from a dropping perspective, though they still are assured a percentage of bandwidth
from a WFQ scheduling perspective. What this means is that these particular queues are only affected by dropping
when the global buffer count becomes low.
7.6 WRED Drop Threshold Management Support
To avoid congestion, the Weighted Random Early Detection (WRED) logic drops packets according to specified
parameters. The following table summarizes the behavior of the WRED logic.
Table 7 - WRED Drop Thresholds
Px is the total byte count, in the priority queue x. The WRED logic has three drop levels, depending on the value of
N, which is based on the number of bytes in the priority queues. If delay bound scheduling is used, N equals
P3*16+P2*4+P1. If using WFQ scheduling, N equals P3+P2+P1. Each drop level from one to three has defined
In KB (kilobytes)
P3
P2
P1
High Drop
Low Drop
Level 1
N
≥
120
P3
≥
AKB
P2
≥
AKB
P1
≥
AKB
X%
0%
Level 2
N
≥
140
Y%
Z%
Level 3
N
≥
160
100%
100%