BugBot
Original Text
Context from Zulip thread "Community Help Chat > CPU Affinity question":
- Trendal originally asked why a CPU with only a small number of nodes/circuits was often pegged at 100%.
- The thread moved into how LibreQoS handles CPU/root shaper allocation for full trees with a top-level shaper, such as a 10G upstream feeding several backhauls.
- Herbert noted that accurate top-level limiting is currently awkward until mq-htb matures; the existing approach effectively allocates the "default" level to each core because there is no clean way to limit between them. A Sandwich branch exists but hurts performance.
- Daniel proposed an alternate planner/scheduler mode: take the configured top-level/default capacity, divide it among root branches according to each branch's typical traffic ratio, and cap each branch by the configured backhaul speed. Example: a 10G upstream with a branch that typically carries 33% would get min(10G * 0.33, configured backhaul speed).
- Daniel also suggested this could be updated regularly with hitless or near-hitless changes.
- Herbert said this could be done, but should be an option rather than the default because changing behavior on upgrade would surprise existing installs.
Suggested behavior:
Add an optional mode that computes root branch shaper capacities from the top-level/default capacity, per-root traffic ratios, and configured backhaul capacities.
Possible algorithm:
- Determine each root branch's typical or recent share of aggregate traffic.
- Compute candidate capacity as top_level_capacity * branch_ratio.
- Cap candidate capacity by the branch/backhaul configured speed.
- Apply the computed capacities to root shapers.
- Recompute periodically and apply changes hitlessly or near-hitlessly where possible.
Why optional:
This changes shaping semantics for existing deployments. It should be opt-in so upgrades do not unexpectedly redistribute capacity.
Impact:
This could provide a more useful approximation for multi-branch trees while true accurate top-level limiting remains blocked by kernel/qdisc limitations.
BugBot
Original Text
Context from Zulip thread "Community Help Chat > CPU Affinity question":
Suggested behavior:
Add an optional mode that computes root branch shaper capacities from the top-level/default capacity, per-root traffic ratios, and configured backhaul capacities.
Possible algorithm:
Why optional:
This changes shaping semantics for existing deployments. It should be opt-in so upgrades do not unexpectedly redistribute capacity.
Impact:
This could provide a more useful approximation for multi-branch trees while true accurate top-level limiting remains blocked by kernel/qdisc limitations.