# A Prototyping Framework for P4-Programmable Traffic Managers

Karl La Grassa, André Béliveau, Mathieu Léonardon, Jean-Pierre David, Matthieu Arzel, Yvon Savaria

## ► To cite this version:

Karl La Grassa, André Béliveau, Mathieu Léonardon, Jean-Pierre David, Matthieu Arzel, et al. A Prototyping Framework for P4-Programmable Traffic Managers. RSP '25: 36th International Workshop on Rapid System Prototyping, Sep 2025, Taipei, Taiwan. pp.1-7, 10.1145/3768617.3770728. hal-05525884

HAL Id: hal-05525884

https://hal.science/hal-05525884v1

Submitted on 25 Feb 2026

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
<figure><img src="image_2.png" /></figure>

<figure><img src="image_3.png" /></figure>

<figure><img src="image_4.png" /></figure>

<figure><img src="image_5.png" /></figure>

<figure><img src="image_6.png" /></figure>

Latest updates: https://dl.acm.org/doi/10.1145/3768617.3770728

RESEARCH-ARTICLE

A Prototyping Framework for P4-Programmable Traffic Managers

KARL LA GRASSA, Polytechnique Montréal, Montréal, QC, Canada

ANDRÉ BÉLIVEAU

MATHIEU LÉONARDON, Laboratory of Sciences and Techniques of Information, Communication and Knowledge, Brest, Brittany, France

JEAN PIERRE DAVID, Polytechnique Montréal, Montréal, QC, Canada

MATTHIEU ARZEL, Laboratory of Sciences and Techniques of Information, Communication and Knowledge, Brest, Brittany, France

YVON SAVARIA, Polytechnique Montréal, Montréal, QC, Canada

Open Access Support provided by:

Polytechnique Montréal

Laboratory of Sciences and Techniques of Information, Communication and Knowledge

<figure><img src="image_7.png" /></figure>

PDF Download
3768617.3770728.pdf
27 February 2026
Total Citations: 0
Total Downloads: 11

Published: 11 February 2026

Citation in BibTeX format

RSP '25: 36th International Workshop on
Rapid System Prototyping
September 28 - October 3, 2025
, Taipei, Taiwan

Conference Sponsors:

SIGDA
SIGMICRO
SIGBED
# A Prototyping Framework for P4-Programmable Traffic Managers

Karl La Grassa¹,², André Béliveau, Mathieu Léonardon¹,
Jean Pierre David², Matthieu Arzel¹, Yvon Savaria²

¹IMT Atlantique, Lab-STICC, UMR CNRS 6285, F-29238 Brest, France

{karl.la-grassa, mathieu.leonardon, matthieu.arzel}@imt-atlantique.fr

{jean-pierre.david, yvon.savaria}@polymtl.ca

andrebeliveau@gmail.com

## Abstract

Traffic managers in programmable networks remain rigid and underexplored due to the lack of prototyping tools that support rapid design iteration and runtime reconfigurability. This paper presents a novel architecture and prototyping methodology for a programmable scheduler, built around lightweight nodes interconnected via a Network-on-Chip (NoC). Each node embeds a 32-bit RISC-V processor and configurable scheduling logic, allowing dynamic real-time policy updates through hot-swappable instruction memory. Our approach spans multiple abstraction levels: at the behavioral level, we extend BMv2 with a P4 interface to prototype and test scheduling policies within programmable data planes, while a SystemC model deployed with High-Level Synthesis (HLS) supports hardware refinement and FPGA deployment. The architecture enables modular, scalable, and reconfigurable traffic management by decoupling scheduling logic from fixed RTL and centralized memory. This work lays the foundation for rapidly prototyping diverse scheduling policies and exploring hardware/software co-design for adaptive data plane systems.

## CCS Concepts

* Networks → Network architectures.

## Keywords

Networks, Programmable Traffic Management, P4, Prototyping, FPGA, HLS, SystemC

## ACM Reference Format:

Karl La Grassa¹,², André Béliveau, Mathieu Léonardon¹,, Jean Pierre David², Matthieu Arzel¹, Yvon Savaria², 2025. A Prototyping Framework for P4-Programmable Traffic Managers. In *36th International Workshop on Rapid System Prototyping (RSP '25), September 28-October 3, 2025, Taipei, Taiwan*. ACM, New York, NY, USA, 7 pages. https://doi.org/10.1145/3768617.3770728

## 1 Introduction

Driven by the need to support next-generation networks, operators increasingly rely on programmable devices. ASIC-based platforms such as Tofino [10] deliver high performance and support programmability through languages such as P4 [4]. However, their rigid hardware architecture restricts the exploration of network functions that go beyond predefined capabilities.

<figure><img src="image_8.png" /></figure>

This work is licensed under a Creative Commons Attribution 4.0 International License.
RSP '25, Taipei, Taiwan

© 2025 Copyright held by the owner/author(s).
ACM ISBN 979-8-4007-2224-0/2025/09
https://doi.org/10.1145/3768617.3770728

In contrast to ASIC-centric platforms, academic frameworks such as NetFPGA [19] offer more flexible environments for prototyping and evaluating high-performance network functions, particularly within the data plane. Initiatives like P4FPGA [16] have lowered the entry barrier, allowing network developers without hardware expertise to design and test forwarding pipelines using high-level languages. However, these efforts remain focused on standard P4 architectures [9], leaving the traffic manager as a fixed-function module, deeply integrated into the hardware. At the same time, the data plane has become increasingly programmable.

As a result, researchers and network operators lack the tools needed to prototype, iterate, or evaluate new scheduling strategies in a realistic system context. In particular, the absence of a unified programming and refinement model makes it challenging to explore traffic management designs across multiple abstraction levels, from behavioral models to hardware implementations.

This challenge motivates a hardware/software co-design approach that enables both architectural exploration and implementation. We address this by proposing a P4-programmable traffic manager architecture targeting FPGAs, combining a P4-based behavioral prototype with a SystemC model designed for high-level synthesis. This approach supports rapid prototyping and progressive refinement while considering ASIC integration. Previous works such as Push-In First-Out (PIFO) [15], which orders packets by programmable ranks, and vPIFO [18], which adapts this model to hierarchical scheduling, introduced programmable abstractions for traffic management. Still, they remain tailored for ASIC pipelines and lack a P4-based control interface and a design methodology that supports an incremental transition from high-level models to deployable hardware.

State-of-the-art programmable traffic managers like vPIFO virtualize a single physical PIFO across multiple logical instances. Its hardware hypervisor time-multiplexes processing units with $O(1)$ context switching, maximizing utilization but introducing contention requiring conflict-free dispatch and starvation control [18].

In contrast, we adopt a different approach based on a distributed architecture built on a Network-on-Chip (NoC), where lightweight scheduling nodes with local memory communicate over a structured interconnect. This design reduces memory contention, enables hierarchical scheduling, and promotes modularity and scalability. Rather than designing a new NoC, we rely on established architectures from the literature, enabling us to focus on the programmable scheduling node as the core building block. Our design is agnostic to the implementation of NoC and compatible with both soft and hard NoC deployments, including those found in the Xilinx Versal devices [2].
To implement this architecture and evaluate its behavior across
abstraction levels, we follow a prototyping workflow that spans
software to hardware.

First, we prototype the entire system behavior in BMv2 [7], ex-
posing a P4-based API to configure the scheduling logic of the
nodes within the proposed architecture. Then, to bridge toward
hardware, the scheduling node is modeled with SystemC and syn-
thesized via High-Level Synthesis (HLS), enabling fast deployment
on FPGA targets. This C++-based toolchain ensures continuity be-
tween software and hardware models, streamlining development.
Each node embeds a 32-bit RISC-V core enabling programmable
scheduling and dynamic policy updates via instruction memory
reconfiguration. This layered approach enables rapid prototyping,
facilitates architectural exploration, and opens a path toward ASIC
realization. The node thus becomes a fully programmable building
block for prototyping hierarchical traffic managers.

Our paper introduces the first open-source, end-to-end frame-
work for prototyping programmable traffic managers<fnref n="1" />. Our pro-
posal is composed of three parts :

(1) a programmable and reconfigurable traffic manager architecture based on a network-on-chip of lightweight scheduling nodes,

(2) a BMv2-based behavioral prototype that demonstrates pro-
grammable scheduling logic and serves as a baseline for
hardware prototyping,

(3) a synthesizable SystemC-based architecture of a lightweight
node specialized in packet scheduling.

The remainder of this paper is structured as follows. Section 2
discusses the relevant background and previous work. Section 3
introduces the proposed architecture, while Section 4 describes the
prototyping methodology and presents our evaluation results.

2 Background

**Programmable data planes.** Platforms like Tofino [10] and lan-
guages such as P4 [4] have brought programmable data planes
into the mainstream. However, their flexibility is limited to match-
action stages of the pipeline [5], while components such as the
traffic manager remain fixed function (Fig. 1).

Architectures like the v1model [8] (Fig. 1), PSA [9] from the P4
community define standardized interfaces for parsing, matching,
and forwarding, but leave the traffic manager as a fixed-function
component. As a result, existing platforms offer little support for
expressing or modifying scheduling behavior, making it difficult
to prototype or evaluate new traffic management strategies within
these environments.

<figure><img src="image_9.png" /><figcaption>Figure 1: V1Model architecture from the P4 community [7]</figcaption></figure>

**Programmable scheduling.** To overcome the rigidity of fixed-
function traffic managers, several abstractions have been proposed
to support programmable scheduling. Push-In First-Out (PIFO)
queues [15] and their derivatives [1, 17, 18] decouple queue or-
dering from scheduling decisions, allowing network operators to
define packet rank computations. Programmable Calendar Queues
(PCQ) [14] offer an alternative based on calendar queue layouts[6],
aiming to match the expressiveness of PIFO-based approaches.

These designs support various scheduling policies and allow run-
time reconfiguration in cases such as vPIFO [18]. However, recent
FPGA implementations primarily target performance evaluation or
SmartNIC deployment rather than design exploration. They also
lack an integrated flow that unifies high-level control, behavioral
modeling, and hardware synthesis, which remains essential for
early-stage prototyping.

<figure><img src="image_10.png" /><figcaption>Figure 2: Example of two logical scheduling hierarchies, each suited to different traffic conditions. Runtime switching between hierarchies ensures that QoS requirements remain met as priorities evolve.</figcaption></figure>

Hierarchical scheduling enforces multi-level QoS, isolates traffic
classes, and aggregates flows under shared constraints. This is typi-
cally done by composing schedulers into logical trees. In dynamic
networks, however, static hierarchies fall short as traffic demands
evolve. Figure 2 shows two selectable hierarchies: The A chain
comprises the following modules: FIFO, SP, EDF, and WFQ; The B
chain uses a DRR on Port 1 and SPs on Ports 2 and 3. Switching
enables adaptation to traffic changes. vPIFO [18] addresses this via
temporal multiplexing: the hierarchy is virtualized and reconfigu-
ration is performed by updating the sequence of scheduling tasks.
Although flexible, this centralized design relies on shared memory
and sequential context switching, leading to contention and lim-
ited scalability as the load increases. We instead adopt a spatial
model, distributing lightweight nodes over a NoC. Reconfiguration
reduces to updating each node’s parent, enabling fast and scalable
adaptation.

**P4 prototyping platforms** Although programmable pipelines
can be described in P4, prototyping them on hardware requires
dedicated FPGA workflows, especially for traffic management. Aca-
demic frameworks such as NetFPGA and P4FPGA [16, 19] have
explored P4-to-hardware pipelines. NetFPGA, which is open source,
supports integrating P4 programs into a fixed hardware architec-
ture provided by the platform. P4FPGA demonstrates P4-to-RTL
generation with a custom backend, but its toolchain is not pub-
licly released. Neither framework provides a reusable or extensible
base for traffic management prototyping. Queuing and scheduling

<footnote n="1">¹https://github.com/klagrassa/prog_tm</footnote>
must be manually implemented in RTL and integrated with the P4 pipeline, an error-prone, time-consuming process, often out of reach for non-expert hardware developers.

Commercial platforms such as AMD's Vitis Networking P4 and Intel's P4 Suite offer more mature flows and runtime integration. Vitis allows RTL/HLS externs to be called from P4, and Intel supports modular pipeline composition. Yet, neither natively supports traffic management; designers must still implement it manually. These platforms inherit the same prototyping challenges as academic tools, with additional licensing barriers that hinder adoption and reproducibility.

**Network-on-Chips.** Network-on-Chip (NoC) architectures provide scalable, structured interconnects commonly used in SoCs and embedded systems. While open-source NoC generators such as FlooNoC [12] and Proteus [3] offer synthesizable, FPGA-friendly designs, their potential in programmable traffic management remains underexplored. Integrating our scheduling nodes into a NoC (Fig. 3) enables modular and hierarchical traffic control. The spatial layout supports flow isolation, and regular topologies like 2D meshes allow flexible mapping of scheduling hierarchies, making NoC-based designs suitable for dynamic environments. We selected FlooNoC for its simplicity of implementation and solid performance on FPGA targets.

<figure><img src="image_11.png" /><figcaption>Figure 3: 2x2 2D NoC mesh representation. Routers transmit packets based on x,y coordinates. Network interfaces (NI) bridges communications between routers and processing elements (PE).</figcaption></figure>

**Prototyping and co-design challenges.** Although SystemC and HLS tools accelerate prototyping in embedded systems, no equivalent flow exists for traffic management. Scheduling logic remains tied to low-level RTL, making iteration slow and error-prone. Academic and commercial platforms lack extensibility and require developers to manually implement queuing and scheduling, limiting exploration and slowing design iteration. Table 1 summarizes key features across platforms, with our framework distinguished by support for traffic manager prototyping.

<table><caption>Table 1: Feature comparison between our framework, P4FPGA, and commercial platforms (Intel P4, Vitis P4).</caption><thead><tr><th>Feature</th><th>Our work</th><th>P4FPGA</th><th>Commercial</th></tr></thead><tbody><tr><td>Sched. customization</td><td>✓</td><td>✗</td><td>✗</td></tr><tr><td>Hierarchical QoS</td><td>✓</td><td>✗</td><td>✗</td></tr><tr><td>Reconfigurable TM</td><td>✓</td><td>✗</td><td>✗</td></tr></tbody></table>

# 3 A NoC-Centric Architecture for Programmable Traffic Management

## 3.1 Hierarchical Composition of Scheduling Nodes

We propose a NoC-based architecture of lightweight, programmable scheduling nodes arranged in a 2D mesh (Fig. 4). Nodes operate independently and can form logical hierarchies to enforce multi-level QoS, enabling flow isolation, traffic shaping, and efficient resource sharing.

Nodes are arranged using an N:1 child-to-parent model: each parent node receives traffic from one or more children, forming a directed tree overlay on the mesh. Nodes at the top of the hierarchy are called root nodes, while those forwarding upward traffic are considered leaves. These hierarchies support recursive scheduling policies, allowing the system to enforce Service Level Agreements (SLAs) or isolate flows at various levels. The physical 2D mesh interconnect supports this abstraction without enforcing a rigid layout, allowing designers to map logical structures onto physical topology. Figure 4 illustrates an example of this configuration in practice based on topology present in Fig. 2.

<figure><img src="image_12.png" /><figcaption>Figure 4: Logical mapping of a directed tree onto the NoC structure. The greyed-out nodes are inactive in the current configuration. Red paths indicate the route followed by packet descriptors through the traffic manager. Grid size is 3x3, ingress and egress are directly connected to inputs and outputs of the NoC.</figcaption></figure>

This mapping between logical hierarchy and physical topology provides high flexibility. Each node stores the (x, y) coordinates of its parent, allowing designers to build arbitrary logical trees without modifying the NoC. Reconfiguring the hierarchy only updates this pointer, letting the architecture adapt to changing workloads while keeping runtime reconfiguration lightweight.
However, hardware resources are limited, and the implementa-
tion is constrained by the available memory and computational
capacity of the hosting device. Operators must carefully balance the
complexity of the hierarchy against the total number of nodes it can
support. Larger hierarchies offer greater flexibility and enable more
effective SLA enforcement by accommodating diverse QoS policies.
In contrast, smaller configurations are more resource-efficient but
come at the expense of reduced flexibility in traffic management.
Ultimately, the logical structure of the hierarchy is bounded by the
physical constraints of the underlying NoC, which dictates how
nodes can be connected and scaled.

Overall, this architecture introduces a scalable and reconfig-
urable foundation to explore traffic management strategies. It em-
powers operators to prototype complex scheduling hierarchies
while controlling resource usage, performance, and QoS semantics.

## 3.2 Scheduling Node: Building Block of the Architecture

Each node acts as an independent scheduling unit, providing a modular and reusable foundation for composing hierarchical traffic management systems. To reduce memory footprint, nodes operate on packet descriptors rather than full packet data, and carry only minimal metadata required for scheduling decisions.

To support rapid prototyping and progressive refinement, we
model each node at two abstraction levels: a high-level behav-
ioral model, implemented in software using BMv2 and P4, and a
hardware-oriented simulation model described in SystemC and
synthesized via HLS. This layered approach facilitates early experi-
mentation and smooth transition toward deployable hardware.

### 3.2.1 Behavioral, high-level software prototype.
At the behavioral level, each node is modeled as a software entity within BMv2, exposing programmable scheduling functionality through a P4 interface. This abstraction enables early validation of scheduling strategies and architecture-wide logic without requiring hardware synthesis. The nodes in this model are built around three core components:

(1) **Scheduling logic:** This logic is the core component of the node. It determines the departure time of the packet descriptors using ranks. The operator selects and configures the scheduler using a P4-like runtime configuration file. The scheduling logic must be described using a rank calculation primitive, which can be described using P4 in our BMv2 model or as a C function for the SystemC level. We limit programmability at rank calculation for prototyping purposes and always dequeue the minimal packet rank.

(2) **Packet descriptor buffer:** Each node includes a local buffer temporarily storing incoming packet descriptors. Rather than enforcing a fixed structure, we keep the buffer design generic to allow users to integrate their own queueing primitives during system design. This enables the use of custom or state-of-the-art memory layouts depending on application needs, which will help expressing a wide variety of packet scheduling.

(3) **Task runner:** This function handles enqueue, dequeue, and re-enqueue operations as they occur. Tasks arrive in a structure that holds the packet descriptor and the type of task to be executed.

<figure><img src="image_13.png" /><figcaption>Figure 5: Representation of a node</figcaption></figure>

Figure 5 illustrates the node structure. Packet descriptors flow from 1 to 4:

(1) **Task Processing:** The task runner processes a task encapsulating the packet descriptor with the task type (enqueue, dequeue, or re-enqueue). The descriptor is then transmitted to the scheduling logic.

(2) **Scheduling Logic:** The scheduling algorithm determines a priority and assigns it to the packet descriptor. Then it is moved to the packet descriptor buffer for storage.

(3) **Packet descriptor buffer:** The packet descriptor is stored in a buffer according to the given rank in the appropriate position.

(4) **Final Processing:** Two scenarios can occur:

(a) If the parent is a node, the current node must wait until the parent is ready to accept the packet descriptor.

(b) When the parent is the traffic manager egress, and the egress port is ready for transmission, a dequeue task is initiated at the first node containing this packet descriptor. The task propagates through the hierarchy until completion. The packet descriptor then exits the traffic manager.

### 3.2.2 SystemC/HLS approach.
We implemented each node in SystemC with High-Level Synthesis (HLS) support to refine the behavioral prototype into a hardware-oriented model. Since both environments are C++-based, this choice provides a natural extension of the BMv2 model. Using SystemC ensures continuity across the toolchain, allows behavioral logic reuse, and supports functional and timing-accurate simulation.

More importantly, this approach enables early validation of the proposed architecture's hardware feasibility. It allows us to simulate the behavior of scheduling logic, buffer interactions, and node coordination under hardware constraints while maintaining a high level of modularity. This is a critical step toward proving that the flexible scheduling semantics expressed in P4 can be carried over to an efficient and synthesizable implementation.

Our SystemC description of the node contains:

(1) **RISC-V 32 bits:** The core scheduling logic is executed by a 32-bit RISC-V CPU, implemented using the DRIM4HLS [13]
<figure><img src="image_14.png" /><figcaption>**Figure 6:** SystemC-level architecture of the scheduling node. Green components represent runtime-accessible elements (e.g., modifiable data), while purple blocks are fixed at runtime. The instruction memory and parent ID register together define the programmable scheduling behavior and logical hierarchical placement of the node.</figcaption></figure>

processor. We chose DRIM4HLS because it is fully compatible with the Siemens Catapult HLS toolchain, allowing for seamless integration into a high-level synthesis workflow. Scheduling policies are written in C and compiled into instruction memory, which is loaded at initialization and can be updated at runtime. This mechanism mirrors the behavioral prototype, where P4 actions define rank computations. Here, the RISC-V CPU evaluates ranks on packet descriptors and stores the result to a specific data memory address, which is later read by the node.

(2) **Packet descriptor buffer:** As in the behavioral model, only packet descriptors are stored locally. The SystemC node exposes a standard interface for memory primitives to be integrated. In our prototype, metadata is preloaded into memory, and each scheduling decision involves processing a single packet descriptor by the RISC-V core. This mirrors the software model and enables early validation while remaining compatible with future runtime integration.

(3) **Node orchestration logic:** In the SystemC model, the top-level module replaces the task runner by coordinating metadata injection, triggering rank computation, and managing packet dequeues. It interfaces with the NoC and ensures proper sequencing without added control logic. This simplifies the hardware while preserving the behavioral model's flow.

# 4 Prototyping and Validation

We evaluate our architecture using a two-stage validation flow bridging software prototyping and hardware refinement. At the software level, we extend BMv2 with a programmable traffic manager to validate dynamic scheduling using P4. This serves as a baseline for node logic and runtime updates. At the hardware level, we develop a SystemC model compatible with high-level synthesis, focusing on a standalone scheduling node. The node features modular interfaces for NoC integration and exposes a memory interface to support queueing primitives.

## 4.1 Behavioral Model

To validate the programmability of our architecture at a high level, we extend the simple_switch target from BMv2 [7], a widely adopted software switch in the P4 research community. This environment enables rapid prototyping of programmable data plane architectures and serves as the foundation for our behavioral evaluation. Our modified version introduces a dedicated Traffic Manager stage (Fig. 7) that exposes scheduling control, provides registers to store parameters and stateful values within the P4 program, and supports dynamic policy reconfiguration at runtime. The key extensions to the BMv2 target include:

* A Traffic Manager block positioned between the ingress and egress stages.

* Native support for scheduling primitives within P4, expressed as actions for rank calculation, predicate evaluation, and dequeue triggering.

* A runtime configuration interface that allows network operators to update scheduling policies without recompilation or redeployment.

<figure><img src="image_15.png" /><figcaption>**Figure 7:** Pipeline of our BMv2 proof-of-concept target</figcaption></figure>

<figure><img src="image_16.png" /><figcaption>**Listing 1:** Strict priority P4 code using basic P4 actions inside ingress. This code will be called by scheduling nodes when enqueuing a packet.</figcaption></figure>

### 4.1.1 Implementation of scheduling policies.
We illustrate the expressiveness of our architecture by implementing a basic Strict-Priority scheduling policy using P4 primitives. In our convention, lower numerical values correspond to higher priority levels. An example implementation of the Strict-Priority scheduling algorithm is given in listing 1. The functions defined in listing 1 are loaded into the nodes at initialization or runtime, depending on the operating context. A straightforward setup was established, with our switch target directly connected to the terminals exchanging data. The
<figure><img src="image_17.png" /><figcaption>**Figure 8:** Strict Priority scheduling: packet entrance (a) vs exit (b). On (b) higher-priority packets (0) are queued first, while lower-priority packets (2) experience increased waiting times. Backpressure was applied to the switch to have a more pronounced effect on packet reordering.</figcaption></figure>

<figure><img src="image_18.png" /></figure>

details of this setup are explained in the next section. We used a calendar queue structure in BMv2, both to ease implementation and to provide a simple primitive for expressing and testing scheduling policy descriptions.

To simplify the representation of priority levels, we assigned specific days to each category: day 0 for high-priority packets, day 1 for medium-priority packets, and day 2 for low-priority packets, ensuring a clear and structured mapping.

Lines 15–17 in Listing 1 show how the P4 program interacts with the scheduler via a traffic manager API. It scans for the next non-empty day, starting from the highest priority, and selects the lowest-rank packet. If no packets are found, a null predicate is set.

This design enables operators to define a wide range of scheduling policies, from simple rank-based selection to more complex behaviors. While rank comparisons integrate naturally with the architecture, supporting richer semantics may require dedicated memory primitives or extending the node to enforce more advanced queueing logic.

### 4.1.2 Test environment.
We evaluated our P4-programmable traffic manager using a controlled testbed composed of two hosts connected to a modified BMv2 switch.

We configured the traffic manager as a single-node system to simplify the evaluation, focusing on core functionalities without added hierarchical complexities. Bulk TCP traffic was generated with iperf, while Scapy produced lightweight flows with random DSCP values mapped to priorities (0 = highest). Logs at ingress and egress confirmed correct priority scheduling, as shown in Fig. 8.

We implemented hotswapping of scheduling policies via a network socket. When a new configuration is received, it is parsed and applied once all packets in the queue have been processed. Enqueuing is paused during this phase to ensure consistency. As shown in Fig. 9, reconfiguration causes a brief spike in inter-departure times at the 15th packet.

Modifying the scheduling behavior of the standard BMv2 target requires restarting the software with the updated P4 program, a process that takes significantly longer than the proposed configuration hot-swap (unmodified BMv2 startup time ranges between 80-100ms for a simple forwarding P4 program on our testbench). In contrast, our approach eliminates the need for a reboot and significantly reduces the impact of configuration changes. As shown

<figure><img src="image_19.png" /><figcaption>**Figure 9:** Impact of runtime reconfiguration on packet inter-departure times. The plot compares our modified BMv2 target (P4TM) with the standard version. P4TM shows brief, controlled fluctuations, while the standard target incurs a long restart. Horizontal bars indicate the stable variance range.</figcaption></figure>

in Fig. 9, the BMv2 restart time has a much greater impact than our solution.

## 4.2 Bridging Software Prototyping and HLS

To bridge toward hardware, we refine the scheduling node model into a SystemC description for high-level synthesis. SystemC allows us to simulate the architecture in a hardware-oriented context while preserving modularity and programmability. More importantly, it provides early validation of hardware feasibility, as the resulting design is compatible with FPGA synthesis workflows using the Siemens Catapult HLS toolchain.

Our SystemC implementation remains closely aligned with the behavioral logic described in the BMv2 prototype. The sequence of operations, including metadata injection and rank computation, is preserved with bit-level accuracy, ensuring that the SystemC model acts as a hardware-consistent refinement of the original behavioral specification. Before rank calculation, The prototype preloads packet metadata into the CPU's local data memory (DMEM). The RISC-V processor computes the rank and writes the result back to
<table><caption>**Table 2: Synthesis results and clock frequencies for CPU and coordination logic.**</caption><thead><tr><th>Metric</th><th>RISC-V32 CPU</th><th>Node coordination logic</th></tr></thead><tbody><tr><td>Frequency (MHz)</td><td>145</td><td>400*</td></tr><tr><td colspan="3">Post-Synthesis Resource Usage</td></tr><tr><td>LUTs</td><td>6485</td><td>404</td></tr><tr><td>FFs</td><td>4728</td><td>698</td></tr><tr><td>DSPs</td><td>4</td><td>0</td></tr><tr><td>Total (per node)</td><td>6889 LUTs (0.4%), 5426 FFs (0.15%), 4 DSPs (0.03%)</td><td></td></tr></tbody></table>

*Node's frequency is dominated by the CPU; coordination logic has minimal impact. The lightweight footprint allows instantiating over 500 nodes without buffering; scalability is mainly constrained by packet descriptor memory.

<table><caption>**Table 3: Execution times of selected schedulers on the CPU from the node.**</caption><thead><tr><th>Scheduler</th><th>Cycles</th><th>Latency on CPU* (ns)</th></tr></thead><tbody><tr><td>Strict Priority</td><td>35</td><td>242</td></tr><tr><td>Weighted Fair Queueing</td><td>91</td><td>628</td></tr><tr><td>Deficit Round-Robin RB [11]</td><td>185</td><td>1276.5</td></tr></tbody></table>

*Scheduling latencies are based on CPU timing, as it is the performance bottleneck.

DMEM. The node then retrieves the updated metadata and prepares for the next task in the scheduling sequence.

To assess hardware cost, we synthesized a single node on a Xilinx Alveo U250 FPGA. The synthesis includes the DRIM4HLS 32-bit RISC-V core, coordination logic, and data memory access, excluding buffer logic to isolate scheduling functionality. Table 2 summarizes the post-synthesis resource usage.

Table 3 illustrates the trade-off between policy complexity and execution cost. Simple strategies like strict priority complete in few cycles, while more advanced algorithms (e.g., DRR, WFQ) require additional logic and state tracking. This range lets operators balance responsiveness and control granularity based on application needs. Our framework enables rapid evaluation of traffic management hierarchies, first in a P4-based behavioral model and then on a cycle-accurate FPGA prototype, supporting the design of programmable traffic managers for diverse conditions and improved QoS.

## 5 Conclusion

This paper proposes a fully open-source prototyping flow for programmable traffic managers. The design leverages a Network-on-Chip composed of lightweight scheduling nodes, each integrating a RISC-V processor—an architectural approach not previously investigated for programmable packet scheduling. Combining P4 programmability, BMv2 modeling, and SystemC/HLS synthesis, it supports dynamic scheduling, runtime reconfiguration, and rapid design-space exploration. Unlike specialized hardware schedulers built around a PIFO abstraction, embedding a RISC-V core in each node provides software-like programmability and significantly faster design-space exploration. This allows policies to be written in C, reloaded at runtime, and iterated without hardware redesign. This work lays the foundation for future research on programmable hierarchical queuing, scalable deployments, and accessible prototyping of programmable traffic management systems.

## References

[1] Albert Gran Alcoz, Alexander Dietmüller, and Laurent Vanbever. 2020. SP-PIFO: Approximating Push-In First-Out Behaviors using Strict-Priority Queues. In *17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20)*. USENIX Association, Santa Clara, CA, 59–76. https://www.usenix.org/conference/nsdi20/presentation/alcoz

[2] AMD. 2025. AMD Versal Adaptive SoCs. https://www.amd.com/en/products/adaptive-socs-and-fpgas/versal.html. [Accessed 15-07-2025].

[3] Abhimanyu Rajeshkumar Bambhaniya, Yangyu Chen, Anshuman, Rohan Banerjee, and Tushar Krishna. 2023. Proteus: HLS-based NoC Generator and Simulator. In *2023 Design, Automation Test in Europe Conference Exhibition (DATE)*. 1–6. doi:10.23919/DATE56975.2023.10137173

[4] Pat Bosshart, Dan Daly, Glen Gibb, Martin Izzard, Nick McKeown, Jennifer Rexford, Cole Schlesinger, Dan Talayco, Amin Vahdat, George Varghese, and David Walker. 2014. P4: Programming Protocol-Independent Packet Processors. *ACM SIGCOMM Computer Communication Review* 44, 3 (July 2014), 87–95. doi:10.1145/2656877.2656890

[5] Pat Bosshart, Glen Gibb, Hun-Seok Kim, George Varghese, Nick McKeown, Martin Izzard, Fernando Mujica, and Mark Horowitz. 2013. Forwarding Metamorphosis: Fast Programmable Match-Action Processing in Hardware for SDN. (2013).

[6] R. Brown. 1988. Calendar Queues: A Fast 0(1) Priority Queue Implementation for the Simulation Event Set Problem. *Commun. ACM* 31, 10 (Oct. 1988), 1220–1227. doi:10.1145/63039.63045

[7] P4 Consortium. 2015. *Behavioral Model version 2*.

[8] P4 Consortium. 2022. V1Model P4 definition. https://github.com/p4lang/p4c/blob/master/p4include/v1model.p4. [Accessed 15-07-2025].

[9] P4 Language Consortium. 2021. P4 Portable Switch Architecture. https://p4.org/p4-spec/docs/PSA.html.

[10] Intel Corporation. 2018. Intel Tofino 2, 12.8 Tbps. https://www.intel.com/content/www/us/en/products sku/218648/intel-tofino-2-12-8-tbps-20-stage-4-pipelines.

[11] Mostafa Elbediwy, Bill Pontikakis, Jean-Pierre David, and Yvon Savaria. 5555. Enabling Rank-Based P4 Programmable Schedulers: Requirements, Implementation, and Evaluation on BMv2 Switches. *IEEE Transactions on Networking* 01 (Oct. 5555), 1–12. doi:10.1109/TNET.2024.3481152

[12] Tim Fischer, Michael Rogenmoser, Thomas Benz, Frank K. Gürkaynak, and Luca Benini. 2025. FlooNoC: A 645-Gb/s/Link 0.15-pJ/B/Hop Open-Source NoC With Wide Physical Links and End-to-End AXI4 Parallel Multistream Support. *IEEE Transactions on Very Large Scale Integration (VLSI) Systems* 33, 4 (April 2025), 1094–1107. doi:10.1109/TVLSI.2025.3527225

[13] Democritus University of Thrace. 2022. DRIM4HLS: DUTH RISC V Microprocessor for High Level Synthesis. https://github.com/ic-lab-duth/DRIM4HLS. [Accessed 15-07-2025].

[14] Naveen Kr. Sharma, Chenxingyu Zhao, Ming Liu, Pravein G Kannan, Changhoon Kim, Arvind Krishnamurthy, and Anirudh Sivaraman. 2020. Programmable Calendar Queues for High-speed Packet Scheduling. In *17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20)*. USENIX Association, Santa Clara, CA, 685–699. https://www.usenix.org/conference/nsdi20/presentation/sharma

[15] Anirudh Sivaraman, Suvinay Subramanian, Mohammad Alizadeh, Sharad Chole, Shang-Tse Chuang, Anurag Agrawal, Hari Balakrishnan, Tom Edsall, Sachin Katti, and Nick McKeown. 2016. Programmable Packet Scheduling at Line Rate. In *Proceedings of the 2016 ACM SIGCOMM Conference*. ACM, Florianopolis Brazil, 44–57. doi:10.1145/2934872.2934899

[16] Han Wang, Robert Soulé, Huynh Tu Dang, Ki Suh Lee, Vishal Shrivastav, Nate Foster, and Hakim Weatherspoon. 2017. P4FPGA: A Rapid Prototyping Framework for P4. In *Proceedings of the Symposium on SDN Research*. ACM, Santa Clara CA USA, 122–135. doi:10.1145/3050220.3050234

[17] Zhuolong Yu, Chuheng Hu, Jingfeng Wu, Xiao Sun, Vladimir Braverman, Mosharaf Chowdhury, Zhenhua Liu, and Xin Jin. 2021. Programmable Packet Scheduling with a Single Queue. In *Proceedings of the 2021 ACM SIGCOMM 2021 Conference*. ACM, Virtual Event USA, 179–193. doi:10.1145/3452296.3472887

[18] Zhiyu Zhang, Shili Chen, Ruyi Yao, Ruoshi Sun, Hao Mei, Hao Wang, Zixuan Chen, Gaojian Fang, Yibo Fan, Wanxin Shi, Sen Liu, and Yang Xu. 2024. vPIFO: Virtualized Packet Scheduler for Programmable Hierarchical Scheduling in High-Speed Networks. In *Proceedings of the ACM SIGCOMM 2024 Conference*. ACM, Sydney NSW Australia, 983–999. doi:10.1145/3651890.3672270

[19] Noa Zilberman, Yury Audzevich, Georgina Kalogeridou, Neelakandan Manihatty-Bojan, Jingyun Zhang, and Andrew Moore. 2015. NetFPGA: Rapid Prototyping of Networking Devices in Open Source. In *Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication*. ACM, London United Kingdom, 363–364. doi:10.1145/2785956.2790029