Power Consumption Profiling for Programmable Network Devices

Introduction In-network computing moves functions such as aggregation, measurement, caching, classification, and security processing into programmable network devices. The power used by these functions is relevant when selecting a program, comparing program versions, or estimating the power cost of deploying a function across many devices. An external power meter can measure the total input power of a device. Repeating that measurement for every program and configuration is costly, and a total value does not identify which packet-processing operations account for a difference. Existing models for fixed-function switches commonly use external variables such as port configuration and traffic load. Those variables remain important, but they do not describe custom parsing, matching, and action logic. This document describes a component-oriented profiling methodology. It first builds a general functional model of programmable packet processing. It then uses controlled calibration programs and power data to derive parameters for a specific target. Once calibrated and validated, the target-specific model can estimate the power of other programs within the validated range. The methodology does not standardize one device's parameters or require disclosure of proprietary pipeline placement. It standardizes the functional decomposition, calibration process, validation conditions, and information needed to interpret a result.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Scope and Non-Goals This document applies to devices whose packet-processing behavior is defined in whole or in part by a loadable or compiled data-plane program. The primary model is a reconfigurable match-action pipeline , but the procedure can be adapted to another architecture when its processing functions can be mapped to the components in . The methodology supports:

profiling one program on one target;
comparing programs or program versions on the same target;
identifying packet-processing features associated with a power difference; and
estimating program-level power after target-specific calibration.

This document does not prescribe an energy-efficiency target, an acceptance threshold, a data-plane language, a compiler, or a single regression model. It does not assert that parameters obtained from one device, compiler, or firmware version apply to another. It also does not replace a direct measurement when a benchmark requires directly measured input power.

Terminology

Target:: The programmable device, architecture, and toolchain combination for which a power model is calibrated.
Data-plane program:: The source, intermediate, or compiled artifact that defines the packet-processing behavior loaded on the target.
Calibration program:: A controlled data-plane program constructed to expose the power behavior of one processing component or candidate factor.
Reference program:: A documented program that provides the baseline packet-processing behavior for a calibration or comparison.
Direct measurement:: A power value measured for the target under the stated program and traffic condition using an external power meter.
Tool-derived power value:: A power value produced by an implementation or design tool, such as an FPGA post-implementation power report, rather than by an external meter.
Model-derived estimate:: A value calculated by a calibrated power model for a program and traffic condition.

Profiling Framework The profiling workflow has three stages:

Construct a general functional power model by decomposing the target's packet-processing path.
Run calibration programs, collect power data, identify influential factors, and derive parameters for the target.
Extract the corresponding features of a query program and use the target-specific model to estimate its power.

The first stage is architecture-oriented. It identifies functions that are common across a class of programmable devices. The second stage is device-specific because the contribution of a function depends on the hardware, compiler, firmware, and implementation. The third stage is valid only inside the range covered by calibration and validation. Calibration requires power data for a limited set of programs. A query does not require a new direct measurement unless the estimate is being validated or the program lies outside the validated range. This distinction is the source of the method's lower measurement cost, but it also makes accurate reporting of the model boundary necessary.

Functional Power Model The total power of a target under a program and traffic condition is represented as: P_basic represents the power needed for the device's basic operation. P_operation represents the additional packet-processing activity of the loaded program. This is a functional decomposition. It does not imply that the physical hardware blocks are isolated or that every term is independently additive.

Basic Power Basic power can be decomposed as: P_idle is the target's baseline power after startup. P_port represents the contribution associated with connected and enabled ports. P_forwarding represents basic packet forwarding under the stated traffic condition. The report MUST identify the chassis, enabled and connected ports, interface types, and basic forwarding program used to derive these terms.

Packet-Processing Power For a match-action pipeline, operational power is organized as: P_parser includes parsing and deparsing. Candidate explanatory variables include parsed header widths, the number and sequence of headers, and packet rate. P_match represents the execution of match-action tables. Candidate variables include match kind, key fields or key width, configured rule capacity, populated rule count, number of tables, and packet rate. P_action represents operations executed after a match. The model distinguishes stateful operations, such as register access, from stateless operations, such as field assignment or arithmetic. Candidate variables include operation category, operation count, operand width, number of tables executing the operation, and packet rate. A calibration experiment MUST determine which candidate factors have a measurable effect on its target. A factor MUST NOT be retained in the target-specific model solely because it appears in the general functional model.

Traffic, Packet Size, and Repeated Processing Packet-processing work depends on the number of packets as well as the number of bits. A profile MUST report both packet rate and bit rate, together with the packet-size distribution. At a fixed bit rate, smaller packets increase the packet rate and can therefore increase the number of parser, table, and action executions. Recirculation causes a packet to traverse the pipeline again. If each recirculated pass performs processing equivalent to an external packet, an effective packet rate can be expressed as: Here, k is the number of recirculations per packet or a traffic-weighted average when packets have different recirculation counts. If later passes execute a different path, the passes MUST be described separately rather than represented only by r_effective. Resubmit, cloning, and multicast SHOULD be reported when they change the amount of packet processing.

Parameter Profiling and Calibration

Calibration Program Design A calibration program SHOULD isolate one candidate factor while holding unrelated factors constant. A calibration set begins with a reference program and adds a series of programs or configurations that vary a controlled parameter. Examples include varying:

connected and enabled ports;
packet rate at fixed packet size and processing behavior;
parsed header width or header count;
match kind, rule count, or table count;
stateful reads and writes;
stateless assignment or arithmetic operations; and
the number of recirculations or processing passes.

A generated program MUST be checked to confirm that the compiler did not remove the operation under test. The report SHOULD record compiler resource output when it is available. If varying one source construct changes placement or other resources, that interaction MUST be reported.

Power Data Collection For a deployed hardware target, each calibration point MUST use an external power meter. The report MUST state the meter type and accuracy, target and toolchain versions, environmental condition, stabilization interval, measurement interval, averaging method, and number of repetitions. For a target that is not available as a measurable hardware implementation, a design-tool power report MAY be used for model development. Such a value MUST be labeled tool-derived and MUST NOT be presented as an external input-power measurement. The calibration program, port state, table population, state initialization, traffic, and any control-plane updates during the measurement MUST be recorded. The packet-processing result SHOULD be checked so that a low-power value caused by unintended drops or a failed program is not accepted as a valid calibration point.

Parameter Derivation For each candidate factor, the profiler compares the power values obtained while that factor is varied. A target-specific relationship can be linear, range-based, logarithmic, or another form supported by the calibration data. This document does not prescribe the fitting method. When a factor produces no stable measurable difference over the calibrated range, the target-specific model SHOULD omit that factor or represent it as an uncertainty term. When the effect of two factors cannot be separated, the model SHOULD use a joint term rather than claiming independent component contributions. Every parameter set MUST be versioned and bound to the target, toolchain, calibration programs, traffic range, and measurement or tool-derived power-data source used to obtain it.

Program Profiling and Power Estimation To profile a query program, the profiler extracts the program features used by the target-specific model. These features can come from program analysis, compiler output, run-time configuration, or a combination of them. The query record MUST include:

program identifier and version;
compiler, target, options, SDK, firmware, and runtime versions;
parser, match-table, stateful-action, and stateless-action features required by the model;
configured and populated table state;
packet rate, bit rate, packet-size distribution, and repeated processing; and
the parameter-set version used for the estimate.

The estimated total power MUST be labeled model-derived. A profiler MAY additionally report a basic-power term and operational terms, but it MUST state whether those terms are measured, independently calibrated, or inferred from a combined model. If the query program contains a feature or traffic condition outside the calibration range, the result MUST be labeled an extrapolation. A new calibration or direct measurement is RECOMMENDED instead of extrapolation when the omitted feature can activate a different hardware resource or execution path.

Model Validation A target-specific model MUST be validated using programs or configurations that were not used to derive its parameters. Validation programs SHOULD cover different combinations of parser, table, register, action, and traffic features within the intended operating range. The validation report MUST provide:

the calibration and validation program sets;
the directly measured or tool-derived value and the estimate for each validation case;
the error definition;
a central error value and the worst observed error;
the validated ranges for traffic and program features; and
known interactions or target limitations.

A model MUST be revalidated after a change to the hardware target, compiler behavior, firmware, or another part of the toolchain that can alter pipeline mapping or power behavior.

Comparing Data-Plane Programs Two programs can be compared directly on the same target by keeping the chassis, ports, toolchain, environment, traffic, table state, stabilization interval, and measurement method unchanged. If P_A and P_B are direct power measurements, the program-associated difference is: The report MUST include P_A and P_B as well as Delta_P(A,B). If the programs implement different functions or produce different forwarding results, the report MUST describe the difference and MUST NOT present Delta_P(A,B) as an efficiency comparison for equivalent behavior. A component model can help explain the difference, but a model-derived attribution MUST be reported separately from the direct difference.

From One Device to a Network For a single device, the program and the local traffic condition are sufficient inputs to a target-specific model. For a network of programmable devices, traffic distribution and forwarding paths also affect power because they determine the packet rate processed by each device. A network-level estimate MUST identify the program and traffic rate at each device. It MUST also state whether links, transceivers, and other devices outside the programmable targets are included. Applying one device's model to every device is valid only when their targets, toolchains, configurations, and validated operating ranges are equivalent. This document does not specify a routing or traffic-engineering algorithm. It only records that network-level profiling requires the traffic distribution and forwarding strategy in addition to the per-device program model.

Reporting Summary Power Profiling Report

Group	Required information
Target	Device, architecture, compiler, SDK, firmware, runtime
Program	Identifier, version, function, compiled artifact
Basic state	Idle state, ports, interfaces, basic forwarding
Parser	Headers, widths, count or depth used by the model
Match	Match kinds, keys, rules, tables, populated state
Action	Stateful and stateless operations used by the model
Traffic	Packet rate, bit rate, sizes, recirculation or other passes
Power data	Direct measurement or tool-derived source and procedure
Model	Parameter version, calibration set and range
Validation	Cases, measured or tool-derived values, estimates, errors
Result	Direct, tool-derived, estimated, or extrapolated label

Implementation Experience The methodology is based on an implementation named Pythia. Pythia constructs an RMT-oriented power model and uses calibration programs to derive parameters for a target. On an Intel Tofino programmable switch, Pythia used an external wattmeter for calibration. It examined the effects of port state, basic forwarding, parser configuration, match-action tables, stateful and stateless actions, traffic rate, packet size, and recirculation. In that implementation, packet rate was the dominant run-time factor; several program-structure factors had only a small measurable effect on the evaluated target. The Tofino model was evaluated with 14 real-world data-plane programs covering different numbers of headers, match-action tables, registers, and action executions. For those experiments, the power range estimated by the model was reported to be within five percent of the direct measurement. Pythia was also adapted to an FPGA-based programmable switch. That evaluation focused on matching because of the available implementation resources and considered match kind, rule count, and table count. Its power values came from post-implementation reports generated by the FPGA design tool, not from an external power meter. These results support the feasibility of target-specific, component-oriented profiling. They do not establish a universal model form or accuracy guarantee. In particular, the Tofino findings about traffic rate and the FPGA findings about matching MUST NOT be assumed for another target without calibration and validation.

Applicability and Limitations The functional model maps directly to RMT-like pipelines. A non-RMT target requires a justified mapping between its execution model and the components in . If such a mapping is not available, the profiler SHOULD define a target-specific decomposition rather than forcing the target into parser, match, and action terms. Compiler placement, shared resources, standby power, memory technology, clocking, and thermal control can hide or couple component effects. A functional term is therefore an explanatory model term, not necessarily the power of a physically isolated block. A model can reduce repeated measurement cost only after the target has been calibrated. It does not eliminate the need for direct measurements during calibration and validation, and it does not make unlike targets automatically comparable.

Security Considerations Profiling SHOULD be performed in an isolated laboratory environment. Calibration programs can exhaust table or stateful memory, create high packet-processing load, or introduce a recirculation loop. A tester SHOULD validate each program at a limited rate before applying the full traffic condition and SHOULD retain a way to stop traffic or unload the program. Program source, compiler output, resource reports, and pipeline placement can contain proprietary information. A report MAY use coarse feature categories, but it MUST state which information is withheld so that readers can assess the limit on reproducibility.

IANA Considerations This document has no IANA actions.