| Internet-Draft | Programmable Power Profiling | July 2026 |
| Chen, et al. | Expires 28 January 2027 | [Page] |
A programmable network device can execute different packet-processing programs on the same hardware. Device-level power measurements show the total input power but do not explain the power associated with a program's parser, match-action tables, and stateful or stateless actions. Models designed for fixed-function switches do not directly describe these program-dependent operations.¶
This document describes a power profiling methodology for programmable network devices. The methodology decomposes packet processing into functional components, uses controlled calibration programs to derive target-specific parameters, and estimates the power of a data-plane program from its processing features and traffic. It also specifies validation and reporting requirements that distinguish direct measurements from model-derived estimates. The methodology is based on implementation experience with an ASIC programmable switch and an FPGA-based programmable switch.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 28 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 [RMT], but the procedure can be adapted to another architecture when its processing functions can be mapped to the components in Section 6.¶
The methodology supports:¶
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.¶
The profiling workflow has three stages:¶
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.¶
The total power of a target under a program and traffic condition is represented as:¶
P_total = P_basic + P_operation
¶
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 can be decomposed as:¶
P_basic = P_idle + P_port + P_forwarding
¶
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.¶
For a match-action pipeline, operational power is organized as:¶
P_operation = P_parser + P_match + P_action
¶
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.¶
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:¶
r_effective = r_external * (1 + k)
¶
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.¶
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:¶
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.¶
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.¶
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.¶
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:¶
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.¶
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:¶
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.¶
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:¶
Delta_P(A,B) = P_B - P_A
¶
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.¶
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.¶
| 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 |
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.¶
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 Section 6. 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.¶
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.¶
This document has no IANA actions.¶