Equal Queue Service Does Not Mean Equal Packet Counts

Locate the selection at one busy output

Suppose several queues hold packets for the same outgoing Ethernet port. Once packets are queued and otherwise eligible for transmission, the scheduler decides which queue receives service next. Classification has already determined their destinations within the queuing system; service selection is a further decision.

NVIDIA's Cumulus Linux 5.14 QoS guide distinguishes egress queue mapping from the egress scheduler and identifies DWRR and strict scheduling modes. Naming a class or showing that it reaches a different queue therefore leaves the service policy unresolved.

This explanation concerns contention at that output. It creates no separate physical lane and no additional outgoing capacity. The linked SL/VL article owns the different question of class-to-lane mapping in InfiniBand. Here, the missing question is how queued competitors get served.

References: [QB1]

Follow byte credit through the Linux DRR model

The DRR manual in the fixed iproute2 v6.17.0 source provides a concrete software model. DRR means Deficit Round Robin. It maintains an active list of nonempty classes, each with a deficit counter initialized to its quantum. The quantum is a byte-credit increment. Different quanta give classes different amounts of credit on replenishment.

For the class at the front, the next packet can be dequeued when its accounted size is no greater than the available deficit. If credit is insufficient, the scheduler adds a quantum and advances to the next active class. The packet waits for sufficient credit.

Linux v6.17's implementation makes the accounting explicit: serving a packet subtracts its accounted length from the deficit. An emptied class leaves the active list; becoming active again initializes its credit to the quantum. An idle class is consequently not accumulating an unlimited bank of unused turns.

These versioned Linux sources explain a software implementation. They do not establish that every switch DWRR engine uses the same list, credit rules or scheduling sequence.

References: [DQ1][K1]

Give each queue 1,500 accounted bytes of service

Consider an invented comparison with two continuously backlogged queues, A and B, sharing one output. Stipulate that neither is paused or otherwise blocked, that there is no preferred competitor, and that each receives a service opportunity covering exactly 1,500 accounted bytes. All A packets have an accounted length of 500 bytes; all B packets have an accounted length of 1,500 bytes.

A can supply three whole packets: 500 + 500 + 500 = 1,500 bytes. B can supply one whole packet: 1,500 bytes. Their accounted byte service is equal, while their packet counts are 3:1. A's larger packet total does not demonstrate that A received three times B's byte service.

Reverse the comparison by counting one packet from each queue. A then supplies 500 accounted bytes and B supplies 1,500, giving a byte ratio of 1:3. Equal packet counts would describe a different allocation from the stipulated equal-byte service.

The lengths are invented accounting inputs. The example excludes Ethernet overhead and host segmentation or aggregation offloads. A service opportunity here is an accounting comparison, not an exact ASIC cycle, timed interval or observed wire schedule. It supplies no conversion to application payload rate.

A packet can need more than one credit increment

Now make a separate, invented case using the Linux credit rules. A continuously active class has 1,500 bytes of credit, a 1,500-byte quantum and a next packet with an accounted length of 2,000 bytes. That packet initially exceeds its credit.

At this unsuccessful eligibility check, the scheduler adds the quantum, bringing credit to 3,000 bytes, and moves the class behind its active competitors. When the class is considered again, the whole 2,000-byte packet fits. Serving it leaves 1,000 bytes of credit, provided the class remains nonempty.

The quantum has not become a maximum packet length or an instruction to divide that packet into pieces. Credit can carry across visits while the class remains active. The arithmetic describes why progress is possible; it assigns no elapsed time to the intervening visits.

References: [DQ1][K1]

Strict preference changes who gets the next opportunity

The Cumulus Linux 5.14 explanation says a strict-priority queue is processed ahead of other queues. Consider the limiting case in which one preferred queue always has an eligible packet whenever the output can transmit. If that queue continually takes the next opportunity, a waiting competitor can receive no service: starvation.

This differs from the byte-credit example, which stipulated service for both competitors. A packet waiting in another queue does not itself force strict preference to yield.

RFC 3290's May 2002 Informational model lists strict priority and rate-limited strict priority as distinct service disciplines. The preference rule alone contains no bitrate cap for the favored traffic. It also specifies no latest completion time for an application operation. A supplier promising a cap or a deadline needs the additional mechanism and evidence supporting that promise; processing a queue first does not establish either outcome.

References: [QB1][R2]

Read a weighted share with its competitors and hierarchy

A weighted service statement needs the group over which the weights apply. Ask which queues are active competitors, which have traffic available to serve, and whether another level of the scheduler or a strict-priority group takes service first. A share within one group cannot automatically be read as the same share of the physical port.

In the Linux model, an empty class leaves the active list. That is why a diagram of configured classes alone does not describe the current competition. For a switch offer, obtain the corresponding explanation for its actual equipment and software; the Linux example supplies no numerical hardware-share prediction.

RFC 7806, published in April 2016 as Informational, explains why both packet sizes and the chosen service unit matter. It also distinguishes packetized service from an ideal continuously shared resource. An average service relationship therefore does not establish a fixed waiting time for each packet. The 3:1 packet count in the invented example says nothing about a particular packet's deadline.

References: [K1][R1]

Keep admission, congestion feedback and service distinct

Buffer admission concerns whether arriving traffic can occupy packet memory. Scheduling concerns which queued traffic receives output service. The Cumulus Linux 5.14 guide treats traffic-pool and buffer allocation separately from egress scheduling. A memory allocation is consequently not a transmission share.

Congestion feedback answers another question. The linked RoCE article follows priority pauses, ECN markings and receiver CNPs through their respective paths. A feedback count does not identify how many accounted bytes each competing queue was served.

For a supplier's fairness claim, request the defined output and traffic population, the byte or packet accounting rule, the relevant active competitors and the policy that serves them. Then judge the submitted result against the requirement: equal accounted bytes, a stated service share and an application completion target are different claims. An unequal packet total alone cannot settle the first two.

References: [QB1][R1]

Bring approved physical connections to the cabling inquiry

Once the equipment and network owners have approved the physical connection plan, Leviathan's Structured Cabling & Fiber Installation service can discuss agreed installation, routing, dressing, labeling, physical checks and connection records using customer-furnished or separately sourced materials. Network configuration, QoS policy and workload qualification remain with the appointed technical owners.

Use the related service and project-inquiry links to share the site, approved endpoint and assembly schedule, routes, material responsibilities, work window and required handoff records. The number of queues or packets served supplies no additional cable quantity. This article supports understanding a proposal; it supplies no field procedure or approval to change a live system.