Source-linked AI summary

Towards Signal Processing In Networks: Multiplierless Block Transforms in Data Plane

Shota Ono, Marika Morikawa, Kazuma Kaneko, Junya Hara, Hiroshi Higashi, Shigenori Tani, Yuichi Tanaka

arXiv:2610.13324v1eess.SP

TL;DR

Raw-stream processing at edge or cloud servers consumes bandwidth and increases latency, motivating signal processing on the forwarding path. The paper proposes SPIN and implements a multiplierless block transform on programmable switches; it reports compiler-level hardware feasibility and improved classification performance for in-network machine learning.

  • Problem

    Processing raw sensor streams at edge or cloud servers consumes bandwidth, increases end-to-end latency, and scales server load with the number of sensors.

    Source: §I · p. 1
  • Method

    SPIN performs signal processing on programmable switches along the forwarding path, using a binDCT-based block transform mapped to feed-forward switch stages.

    Source: §I · p. 2, B. Block Transforms for SPIN · p. 4
  • Results

    The implementation satisfies Intel Tofino2 hardware constraints at compiler level and runs at line rate, while the block transform improves subsequent in-network machine-learning classification performance.

    Source: §I · p. 2, §V · p. 8
  • Takeaways & Limitations

    The evaluation supports the feasibility of implementing signal-processing preprocessing within programmable-switch resource constraints.

    Source: §V · p. 8

Abstract

from arXiv · show

In this paper, we propose a signal processing concept, signal processing in networks (SPIN), that executes signal processing tasks directly on programmable switches. Traditionally, signal processing tasks, such as denoising, decomposition, and dimensionality reduction, are performed on edge or cloud servers, i.e., raw streams are transmitted from sensors. This imposes a heavy processing load on edge/cloud servers and requires substantial bandwidth. SPIN addresses this problem by performing signal processing on the forwarding path. As an initial realization of SPIN, we implement a DCT-based block transform on a programmable switch. We redesign its computation using a lifting-based lattice structure, multiplierless approximation, and pipeline partitioning across stages in a programmable switch. We verify at the compiler level that the proposed implementation satisfies the strict hardware constraints of the Intel Tofino2--specifically regarding pipeline stages, packet header vector, and ternary content-addressable memory usage--and therefore enables line-rate processing. We further quantify the per-packet latency of the ingress match-action pipeline. The SPIN-oriented preprocessing adds 46 cycles (approximately 31 ns at 1.5 GHz). The total ingress match-action unit latency is approximately 87 ns, which remains consistent with the low-latency operation targeted by SPIN. Furthermore, we implement the proposed block transform on a BMv2 switch using P4 and evaluate it as preprocessing for in-network machine learning. Experimental results demonstrate that the proposed method improves classification performance over unfiltered baselines.

I. INTRODUCTION

The paper proposes signal processing in networks (SPIN), performing lightweight signal processing on programmable switches along the forwarding path. It implements a block transform and reports hardware feasibility and improved classification performance for subsequent in-network machine learning.

I. INTRODUCTION

  • Sending raw sensor streams to edge or cloud servers consumes bandwidth, increases end-to-end latency, and scales their processing load with the number of sensors.These costs motivate the question of where signal processing should be performed.Source: §I · p. 1
  • Existing in-network computing mainly targets network functions or task-specific inference, while noisy or redundant sensor streams motivate signal processing on the forwarding path before in-network logic or downstream nodes.The paper positions signal processing of observed sensor streams as a gap in this work.Source: §I · p. 2
  • SPIN performs lightweight signal processing directly on programmable switches to complement cloud- or edge-side computing before data reaches downstream nodes.The paper's initial realization is a block transform redesigned with lifting-based lattice operations, multiplierless approximation, and pipeline partitioning to satisfy switch constraints.Source: §I · p. 2
  • The implementation satisfies Intel Tofino2 hardware constraints at compiler level, runs at line rate, and improves classification performance for subsequent in-network machine learning.Added ingress match-action latency is approximately 31 ns and total ingress match-action latency approximately 87 ns under a 1.5-GHz pipeline clock assumption.Source: §I · p. 2

II. Preliminaries

The preliminaries describe the RMT packet-processing pipeline and the constraints that make direct implementations of conventional signal-processing algorithms infeasible on programmable switches.

A. RMT Architecture and Its Constraints

  • RMT processes packets through ingress and egress pipelines, and this work places SPIN processing entirely in the ingress pipeline.The ingress pipeline processes packets before the traffic manager; the egress pipeline processes them after queueing.Source: A. RMT Architecture and Its Constraints · p. 3
  • RMT is a multistage feed-forward pipeline whose stages have limited operations, so computations must be partitioned across stages.Each stage forwards intermediate results to the next stage.Source: A. RMT Architecture and Its Constraints · p. 3
  • RMT constrains control flow, stage and PHV capacity, ALU lanes, and arithmetic; floating-point operations and variable multiplication or division are unsupported.The PHV is the sole register carrying stateless-computation data between stages, and live variables must fit its bounded capacity.Source: A. RMT Architecture and Its Constraints · p. 3

II. Preliminaries

  • These constraints make direct implementation of conventional signal-processing algorithms infeasible, requiring reformulation or approximation to reduce computational complexity.The section introduces the DCT and binDCT as preliminaries for the design.Source: A. RMT Architecture and Its Constraints · p. 3, §II · p. 3

B. DCT and binDCT

The paper positions SPIN as signal processing on programmable switches and develops a multiplierless, feed-forward block-transform realization suited to the RMT pipeline.

B. DCT and binDCT

  • The binDCT is a lifting-based multiplierless DCT approximation that replaces irrational rotations with dyadic fractions implementable by shifts and additions.The eight-point binDCT uses 30 additions and 13 bit shifts.Source: B. DCT and binDCT · p. 3

A. SPIN Standpoint

  • SPIN performs lightweight signal processing at line rate on the forwarding path and offers programmable-switch reconfigurability, unlike in-sensor processing.The paper distinguishes this mapping challenge from VLSI design, which can tailor its datapath to the algorithm.Source: A. SPIN Standpoint · p. 3

B. Block Transforms for SPIN

  • The block transform maps an input block of N samples to an output block of K coefficients, with each row of H corresponding to an analysis filter.The block transform is represented as a matrix operation.Source: B. Block Transforms for SPIN · p. 4
  • A dense block-transform matrix product is impractical in RMT because it requires O(NK) multiplications that the pipeline does not support.The proposed alternative approximates H as a product of sparse, switch-executable operators built from supported operations.Source: B. Block Transforms for SPIN · p. 4
  • The binDCT factorization realizes the transform through butterfly and lifting steps using additions, subtractions, and bit shifts rather than general multiplication.This adopts lifting steps with dyadic-rational coefficients to express rotations.Source: B. Block Transforms for SPIN · p. 4
  • Because the binDCT is acyclic and feed-forward, it satisfies the control-flow constraint; pipeline partitioning addresses the remaining resource and arithmetic constraints.The paper's section overview describes partitioning the signal-flow graph across switch stages.Source: §III · p. 3, B. Block Transforms for SPIN · p. 4

C. Pipeline Partitioning for Programmable Switches

The binDCT signal-flow graph is redesigned as a stage-by-stage switch pipeline, respecting per-stage arithmetic and PHV limits while preserving the transform apart from intermediate rounding.

C. Pipeline Partitioning for Programmable Switches

  • Dyadic-coefficient operations are decomposed into shifts and additions, then assigned to pipeline stages to fit the switch’s per-stage capacity.The redesign schedules elementary operations rather than changing the transform itself.Source: C. Pipeline Partitioning for… · p. 4
  • At most two intermediate values remain live at once, with PHV slots reused after each value’s last use.The redesigned graph shows the two temporary-slot contents across stages.Source: Figure 2 · p. 4, C. Pipeline Partitioning for… · p. 5
  • The redesigned schedule is functionally equivalent to the original binDCT, but fixed-point rounding differs because decomposition changes when intermediate values are truncated.The execution schedule changes; the transform does not.Source: C. Pipeline Partitioning for… · p. 5
  • Partitioning the computation across pipeline stages enables the programmable switch to execute the processing at line rate.Table 2 reports the number of stages required for each frequency-domain coefficient.Source: C. Pipeline Partitioning for… · p. 5, Table 2 · p. 5

A. Dataset

The evaluation uses Wafer sensor measurements to classify wafer states from short waveform segments, with each segment handled as an independent packet-level task.

A. Dataset

  • The Wafer dataset contains sensor measurements recorded during silicon-wafer processing in semiconductor manufacturing.The dataset is used to evaluate SPIN filtering for in-network machine learning.Source: A. Dataset · p. 5
  • Each 152-step time series represents a normal-or-abnormal classification task based on its waveform.Source: A. Dataset · p. 5
  • Because binDCT has fixed input and output length 8, each signal is segmented into length-8 subsequences carried and classified independently in packets.This reformulates the sequence-level task as packet-level classification.Source: A. Dataset · p. 5
  • Abnormal samples make up 10.7% of training data and 12.1% of test data, so the study accounts for class imbalance in training and evaluation.Source: A. Dataset · p. 5

B. Testbed Setup

The testbed maps tree classifiers to BMv2 and compares raw-feature classification with binDCT preprocessing; inputs and outputs are shifted to meet integer constraints, while the switch implementation omits inverse DCT.

B. Testbed Setup

  • Planter maps pre-trained tree models to the BMv2 match-action pipeline; Encode-Based mapping encodes feature intervals before a final table predicts the label.A separate match-action table compares each feature with tree split thresholds.Source: B. Testbed Setup · p. 5

1) Comparison Methods

  • The comparison includes quantized raw inputs, all-coefficient binDCT outputs, and filtered binDCT outputs with selected coefficients zeroed before shifting.The resulting features are fed to the INML classifier.Source: 1) Comparison Methods · p. 6, Figure 3 · p. 6

2) Bit Shift

  • Raw sensor values are preprocessed as non-negative integers for the switch, and the binDCT coefficients are shifted before being passed to INML’s non-negative-integer input.Switches do not support floating-point arithmetic, while wide integers can be handled natively.Source: 2) Bit Shift · p. 6
  • The switch computes the forward binDCT but omits IDCT because the inverse transform would consume additional pipeline stages.The server-side comparison uses floating-point arithmetic, whereas the switch uses integer arithmetic.Source: 2) Bit Shift · p. 6

3) Feature Selection and Hyperparameters

Feature configurations are selected using validation-set MCC, and their pipeline depth depends on coefficient dependency paths as well as how many coefficients are retained.

3) Feature Selection and Hyperparameters

  • The INML evaluation uses a decision tree capped at depth six, class-frequency weighting, and training, validation, and test splits.The predefined Wafer training set is split 80:20 for training and validation.Source: 3) Feature Selection and Hyperparameters · p. 6
  • The Selected configuration uses X[1], X[2], X[5], X[6], and X[7] for INML, while the server selects X[1], X[3], X[4], X[5], X[6], and X[7] using validation-set MCC.The Baseline configuration uses all eight coefficients.Source: 3) Feature Selection and Hyperparameters · p. 6
  • Selected requires 10 pipeline stages, while Low-frequency requires 12 despite using only four coefficients, because X[3] has the longest dependency path.Source: 3) Feature Selection and Hyperparameters · p. 6
  • Pipeline depth is determined by the longest dependency path among retained coefficients, not simply by their number.The butterfly and lifting operation order constrains stage assignment.Source: 3) Feature Selection and Hyperparameters · p. 6

4) Evaluation

The evaluation measures SPIN’s hardware feasibility through compiler-checked resource use and ingress latency, and its effectiveness through INML classification metrics.

Evaluation

  • The study assesses SPIN from two perspectives: hardware feasibility and INML classification effectiveness.Feasibility covers resource consumption and latency; effectiveness uses the listed classification metrics.Source: 4) Evaluation · pp. 6–7
  • Open P4 Studio compilation against Tofino2 Native Architecture constraints, including stage count, PHV allocation, and TCAM capacity, is the feasibility test.Successful compilation is treated as evidence that the implementation fits the hardware constraints.Source: 4) Evaluation · pp. 6–7
  • Per-packet ingress latency is measured in pipeline clock cycles and converted to nanoseconds assuming an approximately 1.5-GHz pipe clock.Cycle counts come from the Open P4 Studio compiler.Source: 4) Evaluation · p. 7
  • Classification is evaluated with MCC, PR-AUC_cls0, F1_cls0, Precision_cls0, and Recall_cls0, where cls0 is the minority abnormal class.PR-AUC_cls0 is used for its robustness to true-negative counts; F1_cls0 balances precision and recall at a threshold.Source: 4) Evaluation · p. 7

C. Feasibility

The feasibility results show that filtering fits within the compiler-checked hardware constraints, with lower TCAM use but greater pipeline depth and PHV use than raw INML. The latency analysis attributes the added processing time to match-dependent lookup stages.

C. Feasibility

  • Filtering increases pipeline depth from 2 to 13 stages and PHV usage by 56 bits, while reducing TCAM usage from 8 to 5 units; the design still compiles within hardware constraints.Table 4 summarizes resource consumption.Source: Table 4 · p. 7, C. Feasibility · p. 7
  • The 13 stages comprise 10 for binDCT, 1 for the INML input shift, and 2 for decision-tree inference, making binDCT the dominant contributor.Two 32-bit temporary variables add 64 PHV bits, while reducing INML features from eight to five saves one 8-bit PHV container.Source: C. Feasibility · p. 7
  • Coefficient masking reduces pipeline depth from 15 to 13 stages and cuts TCAM from 8 to 5 units and PHV use from 624 to 616 bits.The masked and unmasked binDCT configurations both require 130 cycles because they have the same number of match-dependent stages.Source: C. Feasibility · p. 7, D. Latency Analysis · p. 8

D. Latency Analysis

  • At 1.5 GHz, binDCT raises ingress MAU latency from 84 cycles (56.0 ns) to 130 cycles (86.7 ns), a 46-cycle increase.The increase comes from two additional match-dependent stages; the offset additions precede the corresponding INML lookups.Source: D. Latency Analysis · p. 7, Figure 4 · p. 8
  • Figure 4 reports latency in cycles and corresponding nanoseconds for three configurations, decomposing it into match-dependent and other stages.The nanosecond axis assumes a 1.5-GHz MAU clock.Source: Figure 4 · p. 8

E. Effectiveness

On the Wafer dataset, filtering improves several INML classification metrics, and filtered binDCT reaches the server-side MCC. The IIR extension analysis identifies an atomic state-update operation that current Tofino-style stateful ALUs do not support.

E. Effectiveness

  • Compared with INML (binDCT), INML (filtered binDCT) improves PR-AUC_cls0, MCC, F1_cls0, and Precision_cls0.The authors report that filtering mitigates performance degradation associated with switch-side quantization.Source: E. Effectiveness · p. 8
  • For INML, filtered binDCT yields MCC 0.42, matching the server-side 0.42; without filtering, switch-side binDCT MCC is 0.35 versus server-side 0.41, with quantized integer inputs.Source: E. Effectiveness · p. 8

F. Extension to an IIR Filter

  • An IIR filter’s feedback requires the data plane to preserve a filtered value across packets and use it when the next packet reaches the pipeline.The section illustrates this challenge with a first-order EWMA recurrence.Source: F. Extension to an IIR Filter · p. 8
  • Restricting EWMA’s smoothing coefficient to α = 1−2^-i makes its products implementable as right shifts, but the state update still requires a fused read–shift–add–write.Current Tofino-style stateful ALUs do not support that atomic operation, so this EWMA filter cannot be realized on current programmable switches.Source: F. Extension to an IIR Filter · p. 8
  • A stateful-ALU extension that fuses shift and addition could execute the EWMA update atomically in one stage after earlier stages precompute the current-packet term.The cited extension was verified through synthesis and shown to meet timing.Source: F. Extension to an IIR Filter · p. 8

V. Conclusion

The paper presents SPIN, which executes signal processing directly on programmable switches, and validates it with a binDCT-based block transform for in-network machine learning. Switch-side filtering improves classification performance, and the implementation meets programmable-switch hardware resource constraints.

  • Programmable-switch filtering improves classification performance in machine-learning tasks.Source: §V · p. 8
  • The proposed logic fits programmable-switch hardware resource constraints.Source: §V · p. 8
  • A binDCT-based block transform serves as preprocessing for in-network machine learning.Source: §V · p. 8
  • SPIN executes signal processing directly on a programmable switch.Source: §V · p. 8
Loading 2610.13324v1…