Power management
Forwarding workers poll their NICs continuously, so each worker core reads 100% in the OS regardless of traffic — and burns the matching power at idle. Adaptive polling lets an idle worker nap briefly instead of hot-spinning.
Commands
Set from the system view and staged like any other config change: commit applies live, save persists to system.conf so the setting survives a restart. Nap length is in microseconds, from 1 to 5000, defaulting to 50.
power adaptive enable|disable power nap <1-5000> # microseconds, default 50 power # live runtime state commit ; save show power adaptive enable nap-us 50 naps 1843201 state idle workers nap (power proportional to load) worker 0 naps 921605 worker 1 naps 921596
Opt-in, and why
It is off by default: with it off the data plane is byte-identical to the validated hot-poll baseline. The nap is timer-based, so after an idle gap the first packet sees a wake latency about the length of the nap; there is no cost under load, because the nap never fires while traffic is flowing. For latency-strict deployments leave it off or use a small nap value. Available on every platform; the deeper power backends — RX-interrupt sleep and CPU frequency scaling — are Linux bare-metal roadmap items.
Software PPPoE RSS
A related opt-in toggle, staged the same way. On a NIC that cannot RSS inside PPPoE — the X520, for instance — all upstream PPPoE lands on worker 0. The software dispatcher makes worker 0 hash each upstream PPPoE frame by subscriber IP and fan it out to the other workers. It evens the load but does not scale past one dispatcher core, because worker 0 still parses every upstream packet. For PPPoE at production scale use a NIC with hardware PPPoE RSS such as the E810, and leave this off.
dispatch enable|disable dispatch # live state commit ; save show health # confirm the spread