Generic XDP Under Embedded SoC Constraints: A Lightweight L2 Data Plane with Cost Decomposition Analysis

Abstract

With the proliferation of edge computing and the Internet of Things (IoT), embedded SoC devices are increasingly expected to provide data-plane functions such as network access, data aggregation, and Layer-2 forwarding. On resource-constrained platforms, however, the conventional Linux Bridge forwarding path traverses a relatively long protocol stack and bridging pipeline, incurring a high per-packet processing cost and making the system prone to CPU saturation under small-packet and high-concurrency workloads. Meanwhile, high-performance forwarding solutions designed for server environments often rely on specific hardware and driver capabilities; most legacy NICs in embedded deployments only support XDP in generic mode, making direct reuse of these solutions difficult. To address these challenges, this paper designs and implements a lightweight Layer-2 data-plane system based on XDP generic, tailored for embedded SoC constraints. The system performs minimal forwarding decisions early in the kernel receive path and streamlines the data-path structure via direct redirection, thereby reducing the structural overhead caused by repeated protocol-stack traversal. To provide a unified explanation for performance evolution across packet sizes, we further decompose the forwarding cost under the dual upper bounds of CPU capacity and link bandwidth. This framework characterizes the cost differences between XDP generic and Linux Bridge across workload regimes and elucidates the mechanism by which the bottleneck shifts from CPU-bound to bandwidth-bound operation. Experimental results on an RK3588 platform show that, under embedded generic-XDP constraints, the proposed design exhibits reproducible structural advantages over Linux Bridge in the CPU-bound small-packet and high-PPS regime, while the gap naturally narrows as the bottleneck shifts toward the link-bandwidth limit. These results indicate that, even under the strong constraints of XDP generic—where copy operations and sk_buff-related overheads remain—the forwarding path can still benefit from structural simplification in embedded environments. The study therefore provides empirical support for both the source of benefit and its applicability boundary and offers an explanatory framework for understanding lightweight Layer-2 forwarding on resource-constrained edge devices.

1. Introduction

1.1. Background

In recent years, the rapid growth of IoT endpoints and the downward shift of edge computing have driven network functions to migrate from centralized clouds toward the network edge. As a result, embedded SoC edge nodes are required not only to provide data access and aggregation but also to support fundamental data-plane capabilities such as Layer-2 forwarding [1]. Traditional Linux Bridge is mature and widely adopted; however, under small-packet and high-concurrency workloads where packet rate (PPS) dominates, it is more likely to become CPU-bound, thereby limiting the achievable throughput and inducing latency jitter [2]. By executing packet-processing logic early in the receive path, eBPF/XDP has the potential to shorten the data path and reduce the per-packet overhead. In many deployed embedded devices, however, XDP is often available only in generic mode and remains coupled with the overhead of the general-purpose network stack, making its performance gains and their boundaries in need of mechanistic explanation and validation. Motivated by these observations, this paper focuses on designing a lightweight Layer-2 data plane under the combined constraints of embedded SoCs and XDP generic and develops an explanatory framework that characterizes performance evolution across packet sizes and workload regimes.

As shown in Figure 1, the Linux Bridge data path is longer and is therefore more likely to become CPU-bound under small-packet and high-PPS workloads; while XDP generic can execute earlier in the receive path and shorten the critical path, it remains coupled with the general-purpose network stack. The achievable forwarding performance of the system is jointly bounded by the upper limits of CPU processing capacity and link bandwidth.

Figure 1. Simplified illustration of L2 forwarding at an embedded edge node.

1.2. Related Work

1.2.1. Deployment Modes of XDP/eBPF: Native, Generic, and Userspace/AF_XDP

eBPF/XDP moves programmable logic to an early stage of the kernel receive path to reduce the protocol-stack traversal and improve the packet-processing capability at high packet rates. The existing studies are commonly grouped into three categories: (i) native XDP, which relies on driver support and provides a shorter path; (ii) XDP generic, which offers broad deployability on legacy devices but executes later in the path; and (iii) userspace/AF_XDP, which pursues peak performance via user-space I/O and shared-memory rings [3,4,5,6,7,8].

Limitation. Prior discussions predominantly focus on native or userspace paths, while mechanistic explanations and reproducible quantitative evidence remain limited for embedded/legacy platforms that only support XDP generic.

1.2.2. Profiling and Measurement Methodologies: Throughput, Latency, and Cost Attribution

Evaluations of in-kernel data planes are typically characterized using metrics such as throughput (Mbps/PPS), latency/jitter, packet loss rate, and CPU utilization, and microbenchmarks across packet sizes and load configurations are used to distinguish CPU-bound and bandwidth/IO-bound regimes [2,9,10,11]. To support attribution analysis, both research and engineering practice often combine kernel/hardware counters with performance tools to localize bottlenecks [12].

Limitation. While these methods can reveal performance differences, a unified and transferable organizational framework is still lacking to explain the sources of the differences and the bottleneck-shift mechanism in generic mode, where fixed overheads remain unavoidable.

1.2.3. Constrained Platforms and Embedded Practice: Low-Power SoCs and Deployability Constraints

On constrained platforms such as Raspberry Pi and ARM SoCs, prior work has investigated how eBPF/XDP can improve the forwarding performance and energy efficiency and has highlighted that factors including the CPU frequency, cache characteristics, and NIC queue capabilities have a significant impact on the achievable packet rate [13]. Some system-oriented studies further emphasize that, under resource constraints, adopting a lighter-weight and more controllable data path is essential to ensure stability, particularly for scenarios such as edge gateways and multi-source access [14,15].

Limitation. Embedded deployments are often simultaneously constrained by shared compute/I/O resources and driver capabilities, causing XDP to degrade to generic mode; the existing work still lacks systematic validation of the conditions and boundaries under which the benefits remain valid under the generic constraint.

1.2.4. System Case Studies and Engineering Experience: From Mechanisms to Transferable Conclusions

System-level efforts have adopted eBPF/XDP as data-plane building blocks for forwarding, load balancing, observability, and security. A common theme is to achieve stable and predictable performance by shortening the critical path while controlling the complexity (e.g., map-access overhead and the scale of in-kernel logic) [16,17,18,19,20]. Such experience provides useful engineering principles for designs on constrained platforms.

Limitation. Most case studies target more capable hardware and a mature ecosystem. When migrating to the “embedded + generic” setting, it remains necessary to answer which sources of benefit still hold under strong constraints and how the boundaries should be characterized.

In summary, under the common constraint combination of “embedded SoC with XDP only available in generic mode”, the existing studies still do not directly answer a practically important question: whether the generic-mode XDP is worthwhile for lightweight Layer-2 forwarding when Linux Bridge remains the conventional baseline in deployment. More specifically, the prior work still lacks (1) a stable explanatory framework that maps observed performance differences to their underlying mechanistic sources in this constrained setting and (2) quantitative validation of both the source of benefit and its applicability boundary. Accordingly, rather than claiming a new packet-processing primitive, this paper focuses on characterizing the practicality of lightweight Layer-2 forwarding under the embedded generic-XDP constraint and on extracting reproducible design insight, explanatory structure, and applicability boundaries from controlled experiments. Table 1 compares representative XDP/AF_XDP studies with this work in terms of platform assumptions, operating mode, and key distinctions.

Table 1. Comparison of representative XDP/AF_XDP studies and this work.

Work	Platform	Mode	Assumption/Focus	Key Distinction from This Work
Høiland-Jørgensen et al. [3]	x86/Linux servers	Native XDP	Native-driver-supported platform; high-performance in-kernel packet processing	Targets native XDP on well-supported platforms, unlike generic-mode forwarding on embedded SoCs
Galette [13]	Raspberry Pi/embedded edge platform	Native XDP	Native XDP-capable NIC/driver stack; lightweight edge dataplane design	Assumes native support, whereas this work studies XDP generic under embedded legacy constraints
Mostafa et al. [5]	Linux hosts	AF_XDP/ user space	AF_XDP driver readiness and deployment support	Focuses on AF_XDP deployment and driver support, unlike the lightweight in-kernel generic-mode path used here
Hara and Sasabe [21]	Linux platform	In-kernel/user-space hybrid	Lightweight inference integrated with packet processing path	Focuses on ML-assisted packet processing, whereas this work focuses on lightweight L2 forwarding and generic-vs-bridge comparison on RK3588
This work	RK3588 embedded SoC	XDP generic	Legacy/embedded platform without native XDP support; lightweight L2 forwarding	Studies the practicality of generic-mode XDP under embedded SoC constraints

The remainder of this paper is organized as follows. Section 2 presents the organizing framework and key assumptions for performance analysis. Section 3 describes the system design and implementation highlights. Section 4 details the experimental setup and analyzes the results to answer the research questions. Section 5 concludes the paper and discusses applicability boundaries and future work.

Our contributions are summarized as follows. First, we provide a lightweight XDP-generic-based Layer-2 forwarding design tailored to the embedded-SoC setting, where native XDP support is unavailable and Linux Bridge remains the practical baseline. Second, we introduce an explanatory cost-decomposition framework that characterizes how the dominant bottleneck shifts between CPU-bound and bandwidth-bound regimes and how the shared and differential costs between XDP generic and Linux Bridge should be interpreted. Third, through controlled experiments on RK3588, we validate both the benefit source and the applicability boundary of this design, thereby clarifying when the generic-mode XDP yields structural advantages and when the difference naturally narrows.

2. Theoretical Analysis and Performance Bottleneck Modeling

This section analyzes, from a theoretical perspective, the performance bottlenecks of Layer-2 forwarding in embedded SoC settings. We adopt CPU processing capacity and link bandwidth as common-sense upper bounds and develop a structured explanatory framework based on the shared costs and differential costs of different forwarding paths. The framework is used to characterize how the bottleneck shifts from CPU-bound to bandwidth-bound operation as packet size varies. It is intended to inform design trade-offs in system implementation and to provide a unified basis for understanding and interpreting the experimental results. Building on this framework, we further formulate key hypotheses that can be validated experimentally.

2.1. A Bottleneck Model for Layer-2 Forwarding on Embedded SoCs

To characterize which bottleneck dominates Layer-2 forwarding on embedded SoCs, we establish a first-order upper-bound model under a simplified setting with a single link, a single queue, and controlled dominant-core execution as a single-core approximation. Let the Ethernet frame length be L (Byte) and the nominal link bandwidth be B (bit/s). Under idealized conditions that ignore inter-frame gaps, encapsulation overhead, and retransmissions, the theoretical maximum packet rate determined by link bandwidth can be approximated as

$$R_{\mathrm{link}}\left(L\right)\approx {\displaystyle \frac{B}{8L}}.$$

(1)

This expression captures only the maximum packet rate supported by the link and does not include any processing overhead.

On the other hand, let the effective dominant-core clock frequency be f (cycles/s), and let the average number of CPU cycles required to process one frame on a given forwarding path be $C\left(L\right)$ (cycles/packet). Then, the theoretical maximum packet rate constrained by compute capacity can be approximated as

$$R_{\mathrm{cpu}}\left(L\right)\approx {\displaystyle \frac{f}{C\left(L\right)}}.$$

(2)

In steady-state forwarding, the achievable packet rate is simultaneously bounded by the two upper limits above and thus can be written as

$$R\left(L\right)\le min\{R_{\mathrm{link}}\left(L\right),R_{\mathrm{cpu}}\left(L\right)\}.$$

(3)

Accordingly, when $R_{\mathrm{cpu}}\left(L\right)<R_{\mathrm{link}}\left(L\right)$, the system operates in a compute-dominated CPU-bound regime; when $R_{\mathrm{link}}\left(L\right)\le R_{\mathrm{cpu}}\left(L\right)$, it enters a link-bandwidth-dominated bandwidth-bound regime. Because smaller packets correspond to a larger $R_{\mathrm{link}}\left(L\right)$, embedded SoCs are more likely to become CPU-bound under small-packet and high-PPS workloads. In this case, differences in the per-packet processing cost $C\left(L\right)$ directly determine the achievable upper bound on packet rate.

The above model is a first-order explanatory approximation for embedded data planes under a deliberately simplified setting. Its purpose is to provide a unified description of how the dominant bottleneck shifts with packet size, rather than to predict absolute performance or cycle-level packet-processing cost precisely. In particular, this formulation abstracts away several second-order factors, including inter-frame gaps, detailed Layer-2 framing overhead, cache-miss effects, memory-bandwidth interactions, and softirq contention across multiple cores. Under high-PPS conditions, these factors may cause $C\left(L\right)$ to exhibit nonlinear fluctuations and platform-dependent deviations. Therefore, in the subsequent experiments, we use empirical measurements to validate the explanatory consistency and applicability boundary of this approximation, rather than to claim it as a fully validated numerical cost model. More fine-grained attribution, such as profiler-based cycle analysis using perf, bpftool, or lightweight XDP profiling tools, is left as future work. Based on this upper-bound organizing language, the next subsection further decomposes $C\left(L\right)$ structurally for different forwarding paths to explain the sources of performance differences between the CPU-bound and bandwidth-bound regimes.

2.2. Structural Cost Analysis of Different Layer-2 Forwarding Paths

In Equation (2), the per-packet processing cost $C\left(L\right)$ determines the achievable packet-rate upper bound in the CPU-bound regime. Since this paper focuses on the sources of differences between forwarding mechanisms under the same platform, the same link, and the same workload, it is more meaningful to decompose $C\left(L\right)$ rather than to pursue an accurate estimate of absolute cycle counts. Specifically, we split $C\left(L\right)$ into the “shared cost” borne by all paths and the “differential cost” introduced by structural differences between paths, thereby forming a transferable explanatory basis.

Consider two forwarding paths, Linux Bridge and XDP generic. Their processing costs can be written as

$$C_{\mathrm{bridge}}\left(L\right)=C_{\mathrm{share}}\left(L\right)+C_{\mathrm{diff}}^{\mathrm{bridge}}\left(L\right),$$

(4)

$$C_{\mathrm{x}\mathrm{d}\mathrm{p}\text{-}\mathrm{g}}\left(L\right)=C_{\mathrm{share}}\left(L\right)+C_{\mathrm{diff}}^{\mathrm{x}\mathrm{d}\mathrm{p}\text{-}\mathrm{g}}\left(L\right).$$

(5)

Here, $C_{\mathrm{share}}\left(L\right)$ denotes the largely unavoidable cost of generic packet reception and basic kernel processing on embedded platforms, including driver-level packet reception, necessary data-structure maintenance, and fixed overheads along the baseline protocol-stack path. This component is broadly shared between the two mechanisms and constitutes the “floor” that remains under the generic constraint. In contrast, $C_{\mathrm{diff}}^{(·)}\left(L\right)$ captures the additional cost introduced by differences in data-path structure and is the key factor that leads to throughput divergence between the two mechanisms in the CPU-bound regime.

For Linux Bridge, the differential cost mainly arises from the processing path required to implement bridging and forwarding semantics—for example, lookup operations and forwarding-table maintenance in the bridging logic, processing steps coupled with a more complete protocol-stack path, and additional kernel path length that is more likely to be amplified under high-PPS conditions. For XDP generic, the differential cost is primarily reflected in the path-convergence benefit brought by “making minimal decisions and executing redirection at an earlier stage”: namely, constraining processing as much as possible to the necessary set of predicates and actions, thereby reducing subsequent protocol-stack traversal and bridging-semantic-related steps. It should be emphasized, however, that the generic mode remains coupled with general-purpose network-stack objects (e.g., sk_buff); consequently, its shared cost $C_{\mathrm{share}}\left(L\right)$ does not decrease as significantly as in native XDP [2,3]. This is also why we organize the explanation using “shared/differential costs” rather than an idealized “zero-copy path”.

Substituting Equations (4) and (5) into Equation (2), we obtain that, in the CPU-bound regime, the difference in achievable packet rate between the two mechanisms is mainly determined by the differential cost:

$$R_{\mathrm{cpu}}^{\mathrm{x}\mathrm{d}\mathrm{p}\text{-}\mathrm{g}}\left(L\right)-R_{\mathrm{cpu}}^{\mathrm{bridge}}\left(L\right)\approx f\left({\displaystyle \frac{1}{C_{\mathrm{share}}\left(L\right)+C_{\mathrm{diff}}^{\mathrm{x}\mathrm{d}\mathrm{p}\text{-}\mathrm{g}}\left(L\right)}}-{\displaystyle \frac{1}{C_{\mathrm{share}}\left(L\right)+C_{\mathrm{diff}}^{\mathrm{bridge}}\left(L\right)}}\right).$$

(6)

When small packets and high PPS drive the system into the CPU-bound regime, if XDP generic reduces the differential cost through path convergence such that $C_{\mathrm{diff}}^{\mathrm{x}\mathrm{d}\mathrm{p}\text{-}\mathrm{g}}\left(L\right)<C_{\mathrm{diff}}^{\mathrm{bridge}}\left(L\right)$, it can provide a structural advantage in achievable throughput. Conversely, as the packet size increases, and the system gradually enters the bandwidth-bound regime, the link upper bound in Equation (3) begins to dominate, and the throughput difference between the two approaches correspondingly converges. Therefore, the “structural space” emphasized in this paper does not come from redefining the upper-bound constraints; rather, it stems from reducing differential costs under the persistent generic constraint to achieve a lower per-packet processing cost.

Based on the above decomposition, the next subsection further organizes these mechanistic inferences into testable hypotheses. In the experimental section, we validate them one by one across different packet sizes and workload regimes to clarify the conditions under which the advantage emerges, the reasons for convergence, and the corresponding applicability boundaries.

2.3. Research Hypotheses

Building on the upper-bound organizing language and the shared/differential cost decomposition developed in Section 2, we summarize the performance differences across workload regimes into the following testable hypotheses, which will be validated one by one through experiments in Section 4.

H1 (Structural advantage in the CPU-bound regime). 

When small packets and high PPS drive the system into the CPU-bound regime, if XDP generic reduces the differential cost $C_{\mathit{diff}}^{\mathit{xdp}\text{-}\mathit{g}}\left(L\right)$ by converging the data-path structure, then its achievable upper bound on packet rate should exceed that of Linux Bridge, manifesting as reproducible improvements in throughput (PPS/Mbps). Meanwhile, because the processing path is shorter, its latency and jitter should not be worse than those of Bridge. The corresponding validation condition is to fix the link rate and select a relatively small packet size such that throughput does not reach the link upper bound, while observing CPU utilization as the dominant bottleneck.

H2 (Convergence of differences in the bandwidth-bound regime). 

As packet size increases or the workload becomes bandwidth-dominated, once the system enters the bandwidth-bound regime, throughput is primarily constrained by the link upper bound. Therefore, the throughput difference between XDP generic and Linux Bridge should converge significantly; in this regime, their performance differences are expected to be reflected more in CPU utilization than in the achievable bandwidth itself. The corresponding validation condition is to use a larger packet size or a near line-rate configuration and observe that both schemes approach the link limit while the throughput gap narrows.

H3 (Benefit boundaries and a critical point under the generic constraint). 

Because XDP generic remains coupled with general-purpose network-stack objects (e.g.,sk_buff) and exhibits a fixed overhead floor $C_{\mathit{share}}\left(L\right)$, its structural advantage does not monotonically increase across all small-packet ranges. When packets become extremely small, or when the bottleneck shifts to other components such as the sender/receiver, queues, or interrupts, the benefit may decrease, converge, or even reverse. The corresponding validation condition is to consider more extreme small-packet configurations, where the throughput improvement diminishes or becomes unstable and to use CPU utilization together with changes in packet loss/latency to judge whether the bottleneck is no longer dominated by forwarding-path differences.

Together, these hypotheses form the main thread for the subsequent experimental design and result interpretation. Section 4 will validate H1–H3 through comparative experiments across packet sizes and link rates and will accordingly identify the applicability boundaries and derive design implications under the “embedded SoC + XDP generic” constraint setting.

3. System Design and Implementation

This section presents the architecture and key design choices of a lightweight Layer-2 data-plane system for embedded SoCs based on XDP generic. The system takes the upper-bound bottleneck formulation in Section 2 as its boundary condition and uses the shared/differential cost decomposition as the explanatory framework. Under the premise that shared costs are unavoidable in generic mode, it reduces the differential costs by converging the critical path and minimizing the set of forwarding actions. In doing so, it lowers the per-packet processing cost and improves the achievable performance in the CPU-bound regime. The system is implemented on top of the native Linux networking subsystem: XDP generic runs in the kernel receive path, can be directly deployed and reproduced on embedded distributions such as OpenWrt, and serves to explain and validate the gains, convergence behavior, and boundaries described by H1–H3 in Section 2.3.

3.1. Overall Architecture

The proposed data-plane system targets typical embedded SoC network nodes and runs on the native Linux networking subsystem. It uses XDP generic as the data-plane execution entry and does not rely on user-space bypass frameworks or specific hardware accelerators and thus can be directly deployed and reproduced on mainstream embedded distributions such as OpenWrt. The system follows a control-plane/data-plane separation. The control plane is responsible for system initialization, interface configuration, and forwarding-rule installation (map update), and it stays off the high-speed forwarding critical path. The data plane executes minimal Layer-2 forwarding logic at the XDP generic attachment point in the kernel receive path: it performs an eBPF Map lookup (map lookup) and selects either XDP_PASS or XDP_REDIRECT to complete the forwarding action, thereby avoiding deeper protocol-stack processing.

This architecture is consistent with the upper-bound bottleneck formulation in Section 2. In the CPU-bound regime, the achievable packet rate is dominated by $R_{\mathrm{cpu}}\left(L\right)=f/C\left(L\right)$; accordingly, the core design goal is to reduce $C\left(L\right)$ by converging the critical path and compressing differential costs. Once the system enters the bandwidth-dominated regime, throughput is constrained by the link upper bound and the performance differences naturally converge. As shown in Figure 2, the proposed system adopts a control-plane/data-plane separation, where XDP generic executes minimal forwarding logic in the kernel receive path and the control plane remains off the fast path.

Figure 2. Architecture of the proposed XDP-based L2 data plane.

3.2. Lightweight Forwarding-Logic Design

To obtain reproducible CPU-bound performance gains under the “embedded SoC + XDP generic” constraint, we design the data-plane forwarding logic as minimal processing: it retains only the parsing, lookup, and action execution necessary for Layer-2 forwarding and avoids introducing additional protocol-stack traversal or complex control logic on the fast path. This design follows the shared/differential cost decomposition in Section 2: given that shared costs are unavoidable in generic mode, we reduce the per-packet processing cost by compressing the differential costs.

After an XDP program reaches the XDP generic hook, it performs only three steps. The pseudo-flow of the XDP generic forwarding logic can be summarized as follows:

1.

Parse the Ethernet header and perform boundary validation.

2.

Extract the minimal lookup key and query the forwarding rule from the eBPF map.

3.

If a valid rule exists, redirect the packet to the target interface (XDP_REDIRECT); otherwise, pass the packet to the normal network stack (XDP_PASS).

Parse Ethernet Header → Lookup(map) → Action. In the parsing stage, the program performs boundary checks and extracts the minimal lookup key. In the lookup stage, it queries the forwarding action through an eBPF map. In the action stage, it executes XDP_REDIRECT to send packets to the target interface when a rule matches; for misses or malformed packets, it executes XDP_PASS and hands the packet to the subsequent network stack, thereby preserving compatibility and providing a fallback path under exceptions. In the implemented prototype, the forwarding rule is stored in eBPF maps with explicit key/value layouts. In the port-based mode, the key is the ingress interface index, and the value is a port configuration containing the target interface index and forwarding flags. In the MAC-based mode, the key is the destination MAC address, while the value remains the same port configuration. A separate configuration map records the current forwarding mode, and a devmap is used to hold the redirect-capable target interfaces for the XDP redirect operation. Therefore, the lookup stage only needs to extract a minimal key from the incoming frame and retrieve the corresponding forwarding action without traversing higher-layer protocol state. Table 2 summarizes the correspondence between the design goals in Section 2, the implemented data-plane mechanisms, and the evaluation metrics used in Section 4.

Table 2. Mapping between design goals, mechanisms, and evaluation metrics.

Design Goal (Section 2)	Data-Plane Mechanism (This Section)	Expected Impact (Cost/Bottleneck)	Metrics and Corresponding Experiments
Reduce differential cost and converge the critical path	Minimal processing (three-step pipeline)	$\downarrow C\left(L\right)$; improved CPU-bound performance	PPS/Mbps, CPU%; Section 4.3 (throughput)/Section 4.5 (CPU overhead)
Maintain benefits under the generic constraint	Earlier decision at the XDP generic hook; reduced stack traversal	Benefits concentrate in the small-packet CPU-bound regime	Gains across packet sizes; Section 4.3 packet-size comparison/relative improvement
Compatibility and fallback	XDP_PASS on miss/exception	Packet loss, RTT/jitter; controllable risk on the exception path	RTT, packet loss; Section 4.4 (latency and stability)
Control-plane/data-plane separation	Control plane: map update; data plane: map lookup only	Stable throughput/CPU; more stable fast path	Stability evidence; Section 4.4 (stability: RTT/packet loss) + Section 4.5 (CPU overhead)
Natural convergence in the bandwidth-bound regime	Near bandwidth-bound (constrained by the link upper bound)	Line rate with large packets; convergence of differences	Large-packet/bandwidth-dominated regime; Section 4.3 (throughput convergence)
Boundaries and critical point (H3)	Shared overhead + bottleneck shift with extremely small packets	Benefit decreases/ converges/reverses	Extremely small-packet differences and boundary tightening; Section 4.6 (Findings and Implications)

Note: ↓ indicates a reduction in the corresponding cost or metric.

From a data-path perspective, the data-plane action set is converged to XDP_PASS and XDP_REDIRECT: the former provides fallback and compatibility, while the latter enables early decisions at the XDP generic attachment point and performs direct redirection, thereby compressing differential costs. This mechanism aligns with the hypotheses in Section 2.3: it yields reproducible benefits in CPU-bound small-packet scenarios (H1), exhibits convergence of differences in bandwidth-dominated regimes (H2), and reveals its boundaries when packets become extremely small or when the bottleneck shifts elsewhere (H3). These phenomena are validated and discussed in Section 4.

3.3. Resource Isolation and Execution-Environment Tuning

The purpose of the configurations described in this subsection is to reduce the measurement noise and improve interpretability. The corresponding test settings and parameters will be reported in the experimental section (Section 4) to ensure reproducibility.

To improve the stability and reproducibility of forwarding comparison experiments on embedded SoCs, we apply resource-isolation and tuning configurations at the execution-environment level for the data plane. The goal is to minimize disturbances to throughput and latency measurements caused by cross-core scheduling, softirq migration, and background tasks. These configurations do not change the data-plane mechanism itself; rather, they serve as prerequisites for experimental credibility and provide a consistent execution environment for the results in Section 4.

(1)

Dominant-core execution model. To approximate the single-core assumption in Section 2, we adopt a dominant-core convergence strategy: we configure the system so that forwarding-related NET_RX/softirq processing is concentrated as much as possible on a designated core, thereby emulating a single-core execution baseline in a statistical sense.

(2)

IRQ affinity and queue-consistency configuration. Under high-PPS workloads, NIC receive interrupts and NAPI behavior can significantly affect softirq overhead. We pin the relevant queue interrupts to the designated core and, as much as possible, keep receive and transmit processing on the same core to reduce cross-core wakeups and contention overheads.

(3)

Background-interference suppression and testing consistency. During experiments, we disable or reduce non-essential background services and repeat the test procedure under the same configuration. This ensures that the comparison between XDP generic and Linux Bridge is conducted under comparable system-load conditions, so that observed differences more directly reflect data-path structural factors.

The concrete configurations and parameter settings will be provided in Section 4 to support reproducibility.

3.4. Summary

This section has presented the overall architecture and key design choices of a lightweight Layer-2 data-plane system under the constraint setting of “embedded SoCs with only XDP generic support.” The system adopts a control-plane/data-plane separation and converges the critical path at the XDP generic attachment point using a minimal processing pipeline (Parse → Lookup(map) → Action: PASS/REDIRECT), thereby compressing the differential costs. In addition, dominant-core convergence and IRQ-affinity configurations are applied to reduce execution-environment disturbances and to provide consistent conditions for the subsequent comparative experiments.

These designs are aligned with the upper-bound formulation and the shared/differ-ential cost decomposition introduced in Section 2, and they directly correspond to hypotheses H1–H3 in Section 2.3: reproducible benefits in CPU-bound small-packet scenarios, convergence of differences in bandwidth-dominated regimes, and the manifestation of benefit boundaries under extremely small packets or when the bottleneck shifts elsewhere. The next section conducts experimental validation and result analysis based on this system implementation.

4. Experimental Results and Analysis

This section conducts system-level experiments to validate the lightweight Layer-2 data plane based on XDP generic designed in Section 3 and analyzes its forwarding-performance implications in embedded SoC settings. Guided by the upper-bound formulation and the shared/differential cost decomposition in Section 2, the experiments focus on verifying whether converging the critical path can reduce the per-packet processing cost and thereby deliver reproducible gains under CPU-bound conditions, approaching the achievable performance upper bound.

4.1. Experimental Environment and Methodology

4.1.1. Experimental Platform and Test Topology

Our experimental platform is built on an RK3588 embedded SoC equipped with 1 GbE and 2.5 GbE Ethernet interfaces. To remain consistent with the assumptions used in the theoretical analysis in Section 2, we adopt a Layer-2 forwarding evaluation setup with a single link, a single queue, and dominant-core convergence to approximate single-core execution. Under a controlled execution environment, the forwarding node is dedicated solely to the L2 forwarding task, enabling us to characterize performance evolution across the CPU-bound and bandwidth-bound regimes. The hardware and software configurations are summarized in Table 3.

Table 3. Experimental platform and software environment.

Role	Hardware	CPU/Memory	Network Interface	OS/Kernel
Sender/Receiver (logical endpoints)	x86 host (partitioned via network namespace)	Intel Core i3-N305 (8C/8T, up to 3.80 GHz), 32 GiB	Quad-port 2.5G PCIe NIC (Intel Ethernet controller), with two ports used for send and receive, respectively	Ubuntu 22.04.5 LTS/Linux 6.8.0-87-generic
Forwarder	RK3588 embedded SoC platform	4× Cortex-A76 + 4× Cortex-A55, 8 GiB	Realtek RTL8125 dual-port 2.5G NIC (r8125), two 2.5 Gb/s full-duplex links	iStoreOS 22.03.7 (OpenWrt 22.03.7)/Linux 5.10.221 (aarch64)

Note: The sender and receiver are two network-namespace instances on the same x86 host, which constructs an end-to-end path without increasing hardware complexity.

To further improve the reproducibility, the RK3588 forwarder configuration is specified more explicitly here. The board runs iStoreOS 22.03.7 with Linux kernel 5.10.221, and the 2.5 GbE forwarding interfaces are driven by the Realtek r8125 driver (version 9.014.01-NAPI-RSS). During the experiments, both forwarding-side links operate at 2500 Mb/s full duplex. Although the NIC supports multiple hardware channels, the measurements in this work are conducted under a controlled single-link single-queue setting to remain consistent with the simplified execution model used in Section 2.

The overall topology is illustrated in Figure 3. We adopt a single-node forwarding structure (single input, single output) consisting of a sender, an RK3588 forwarder, and a receiver, and we perform Layer-2 forwarding only. The sender and receiver are realized as two logical endpoints on the same x86 host using Linux network namespaces. Each namespace is configured with an independent IP address and routing rules, making their behavior equivalent to two separate host devices. This design enables a complete end-to-end forwarding path without additional hardware while preserving test reproducibility.

Figure 3. Experimental single-link Layer-2 forwarding topology for performance evaluation on RK3588.

We choose Linux Bridge as the baseline for comparison. The proposed XDP generic data plane and Linux Bridge are evaluated under the same hardware and operating-system environment, and a controlled-variable methodology is used to ensure a fair comparison (the execution environment is fixed according to the configuration in Section 3.3 to guarantee fairness and reproducibility). The evaluation metrics include achievable throughput (PPS/Mbps), end-to-end forwarding latency, and resource utilization (e.g., CPU). By varying the packet size, we cover both small-packet high-PPS workloads and large-packet bandwidth-limited scenarios, allowing us to observe how the two paths differ across bottleneck regimes.

4.1.2. Methodology and Statistical Conventions

To ensure stable and reproducible results, we adopt a unified test procedure and consistent statistical conventions. To approximate single-core execution in a controlled and reproducible manner, we apply a dominant-core convergence procedure on the RK3588 forwarder. Specifically, receive-side packet steering mechanisms such as RPS/RFS are disabled, and the relevant NIC interrupt sources are pinned to a designated CPU core through IRQ-affinity settings, so that forwarding-related processing is concentrated on one dominant core as much as possible. We verify this execution condition by checking per-core softirq increment statistics during the steady-state interval and confirming that forwarding-related activity is predominantly accumulated on the designated core. We emphasize that this setting is a controlled single-core approximation rather than a literal single-core hardware configuration; its purpose is to provide a fair and low-noise baseline for comparing XDP generic and Linux Bridge under the same execution constraint. For throughput measurement, the sender uses pktgen-dpdk to generate traffic with a fixed packet size, and the receiver collects NIC RX counters via scripts to compute the effective forwarding rate (PPS/Mbps). Each configuration is run for 20 s; we discard the first and last 5 s and report the average over the middle 10 s steady-state window. Each configuration was repeated three times under identical settings. The reported results are given as the mean ± standard deviation (mean ± std, $n=3$). In the corresponding figures, error bars indicate $\pm 1$ standard deviation.

For latency measurement, we use fping to measure end-to-end RTT (-c 5000 -p 1 -q) and record the steady-state packet-loss rate as well as the min/avg/max statistics. CPU utilization is observed and recorded using htop, which also helps determine whether the system operates in a CPU-bound regime or a bandwidth-dominated regime for a given packet size. All comparative experiments are conducted under the same topology and statistical conventions to ensure that the results for XDP generic and Linux Bridge are directly comparable.

4.2. Overview of Experimental Results

To facilitate an overall comparison between the two forwarding paths across packet sizes, we summarize the key metrics in Table 4, including the effective throughput (PPS/Mbps), end-to-end RTT (min/avg/max), packet loss rate, and CPU utilization on the forwarder. All results follow the unified testing and statistical conventions described in Section 4.1.2 and are obtained under the controlled execution condition of dominant-core convergence (single-core approximation). In the following subsections, we analyze the throughput, latency, and resource utilization separately, guided by the upper-bound formulation and the shared/differential cost decomposition in Section 2.

Table 4. Summary of key metrics across packet sizes (dominant-core convergence, 2.5 Gb/s link). Throughput- and RTT-related values are reported as mean ± standard deviation over three repeated runs.

Packet Size	Mode	TX PPS	RX PPS	Loss	Avg. RTT	CPU
(Bytes)		(pktgen)	(x86)	(%)	(ms)	(%)
64	XDP (generic)	204,224 ± 137	204,205 ± 13	0.00	0.455 ± 0.001	100
64	Linux Bridge	177,536 ± 69	177,540 ± 92	0.00	0.482 ± 0.002	100
128	XDP (generic)	191,200 ± 39	191,754 ± 15	0.00	0.431 ± 0.005	100
128	Linux Bridge	171,584 ± 97	171,309 ± 207	0.160	0.458 ± 0.002	100
256	XDP (generic)	169,728 ± 85	169,133 ± 100	0.351	0.455 ± 0.001	100
256	Linux Bridge	156,032 ± 95	155,850 ± 58	0.117	0.466 ± 0.002	100
512	XDP (generic)	156,832 ± 62	156,423 ± 44	0.261	0.465 ± 0.002	100
512	Linux Bridge	145,056 ± 140	144,007 ± 131	0.723	0.480 ± 0.001	100
1024	XDP (generic)	146,240 ± 104	145,301 ± 137	0.642	0.501 ± 0.001	100
1024	Linux Bridge	140,864 ± 236	140,232 ± 132	0.449	0.506 ± 0.001	100
1280	XDP (generic)	143,008 ± 47	142,479 ± 80	0.370	0.554 ± 0.001	100
1280	Linux Bridge	138,656 ± 118	139,829 ± 118	0.00	0.558 ± 0.002	100
1514	XDP (generic)	144,288 ± 112	143,435 ± 126	0.591	0.562 ± 0.001	100
1514	Linux Bridge	137,984 ± 186	138,574 ± 212	0.00	0.568 ± 0.001	100

4.3. Throughput Validation

Figure 4, Figure 5 and Figure 6 compare the RX packet rate/throughput and the relative improvement of the two forwarding mechanisms across packet sizes. All results are obtained under the controlled execution condition of dominant-core convergence (single-core approximation).

Figure 4. RX packet rate (PPS) comparison between XDP generic and Linux Bridge under the dominant-core setting (single-core approximation), single-link, and single-queue conditions at 2.5 Gb/s across different packet sizes. Error bars indicate $\pm 1$ standard deviation over three repeated runs.

Figure 5. RX throughput (Mb/s) comparison between XDP generic and Linux Bridge under the dominant-core setting (single-core approximation), single-link, and single-queue conditions at 2.5 Gb/s across different packet sizes. Error bars indicate $\pm 1$ standard deviation over three repeated runs.

Figure 6. Relative RX packet-rate gain of XDP generic over Linux Bridge under the dominant-core setting (single-core approximation), single-link and single-queue, at 2.5 Gb/s across packet sizes.

Under small-packet settings such as 64–256 Bytes, the forwarding-core CPU approaches saturation, and the system satisfies $R_{\mathrm{cpu}}\left(L\right)<R_{\mathrm{link}}\left(L\right)$. Consequently, the achievable packet rate is primarily constrained by the compute capacity (Equation (2)) and determined by the $min\{·\}$ upper bound in Equation (3). Following the structural decomposition in Section 2, the per-packet costs of Linux Bridge and XDP generic are given by Equations (4) and (5), respectively, with their difference mainly attributed to the differential-cost term. Therefore, when XDP generic reduces the differential cost by converging the critical path, its PPS advantage in the CPU-bound regime should, according to Equation (6), directly manifest as an increase in RX PPS. This matches the results observed in Figure 4 and Figure 5 for the small-packet regime.

As the packet size increases, the system gradually enters the bandwidth-dominated regime where $R_{\mathrm{link}}\left(L\right)\le R_{\mathrm{cpu}}\left(L\right)$. In this regime, throughput is primarily constrained by the link upper bound (consistent with the formulations in Equations (1) and (3)), and the difference between the two mechanisms correspondingly diminishes and converges. The relative-improvement plot in Figure 6 further shows that the gains are concentrated in small-packet and high-PPS scenarios. Overall, the experiments validate the judgment in Section 2 based on “shared/differential cost decomposition + dual upper-bound switching”: under the generic constraint, benefits arise from seeing differential costs compressed, and they primarily manifest in the CPU-bound small-packet regime.

4.4. Latency and Stability Analysis

To examine whether the throughput improvement comes at the cost of increased latency or packet loss, this subsection further compares the RTT and loss behavior of the two approaches (see Figure 7 and Figure 8). The tests are still conducted under the controlled execution condition of dominant-core convergence (single-core approximation) to avoid confounding factors such as endpoint bottlenecks or differences in parallelism.

Figure 7. RTT comparison between XDP generic and Linux Bridge under the dominant-core setting (single-core approximation), single-link, and single-queue conditions at 2.5 Gb/s across different packet sizes. Error bars indicate $\pm 1$ standard deviation over three repeated runs.

Figure 8. Packet loss rate comparison of XDP generic and Linux Bridge under the dominant-core setting (single-core approximation), single-link and single-queue, at 2.5 Gb/s across packet sizes. Note: Due to counter-sampling noise and misalignment of the statistics window, a few points may exhibit slightly negative loss; they are clamped to 0 in the plot.

As shown in Figure 7, the RTT of both approaches remains on the same order of magnitude across packet sizes, and we do not observe a persistently accumulating queuing delay as the throughput increases. This observation is consistent with the “CPU/link dual upper-bound” formulation in Section 2: the throughput gain stems from lifting the $R_{\mathrm{cpu}}\left(L\right)$ upper bound (Equations (2) and (3)) in the CPU-bound regime, rather than trading latency for throughput by introducing additional queuing or deeper processing stages. Consequently, the overall RTT behavior does not degrade.

As shown in Figure 8, the packet-loss rate exhibits discrete fluctuations across packet sizes, and we do not observe a systematic or monotonic degradation that accompanies the throughput improvement. In conjunction with the throughput and CPU results, these fluctuations are more likely attributable to factors such as the counting/statistics window, transient send/receive jitter at the endpoints, and momentary queue contention under CPU-bound conditions, rather than a new stability cost introduced by the critical-path optimization in XDP generic. Overall, the experiments do not indicate a phenomenon of “trading significant packet loss for throughput”.

4.5. System Resource-Overhead Analysis

To further validate the source of the throughput differences, this subsection compares the CPU overhead of the two approaches across packet sizes (see Figure 9). The test setup keeps the dominant-core convergence (single-core approximation) and the single-link single-queue configuration unchanged, so that CPU utilization can be used as a bottleneck indicator.

Figure 9. Dominant-core CPU utilization comparison of XDP generic and Linux Bridge under the dominant-core setting (single-core approximation), single-link and single-queue, at 2.5 Gb/s across packet sizes.

As shown in Figure 9, under small-packet high-PPS workloads, the forwarding-core CPU of both approaches is close to saturation, indicating a compute-limited state, in which the achievable packet-rate upper bound is dominated by $R_{\mathrm{cpu}}\left(L\right)$ (Equations (2) and (3)). According to the decomposition of the per-packet processing cost in Section 2, the difference between Linux Bridge and XDP generic mainly comes from the differential-cost term introduced by the data-path structure (Equations (4) and (5)). Therefore, even when the CPU is equally saturated, XDP generic can still achieve a higher RX PPS due to a lower per-packet cost, and the relative improvement can be characterized by Equation (6). This result is consistent with the throughput observations in Section 4.3, indicating that the observed advantage primarily comes from differential-cost compression, rather than from additional CPU resources or changes in parallelism.

As the packet size increases, the throughput difference exhibits a convergence trend. This phenomenon should be interpreted as the achievable throughput becoming progressively dominated by the link upper bound, rather than being explained by a reduction in CPU utilization. Overall, Figure 9 provides resource-level supporting evidence for our conclusion: under the generic constraint where shared overhead cannot be eliminated, the benefit mainly arises from compressing differential costs, and it is more pronounced in the CPU-bound small-packet regime.

4.6. Key Findings and Implications

This subsection summarizes the results in Section 4 and closes the loop with the framework in Section 2 (“shared/differential cost decomposition + dual upper bounds of CPU/link”).

Finding 1 (Reproducible gains for CPU-bound small packets). Under dominant-core convergence (single-core approximation), XDP generic achieves a higher RX PPS/throughput in the small-packet high-PPS regime. The advantage is consistent with the compute-limited state, where CPU utilization is close to saturation, indicating that the benefit primarily stems from lifting the $R_{\mathrm{cpu}}\left(L\right)$ upper bound (Equations (2) and (3)).

Finding 2 (Gains arise from compressing differential costs rather than eliminating shared costs). Based on the structural decomposition in Equations (4) and (5), the shared-cost term is unavoidable in generic mode; therefore, the difference between the two mechanisms is mainly determined by the differential-cost term. In the experiments, a higher PPS is observed even when CPU utilization is equally saturated, matching the inference characterized by Equation (6) that “per-packet cost differences → achievable packet-rate differences”.

Finding 3 (Natural convergence in the bandwidth-dominated regime). As the packet size increases, and the system gradually becomes dominated by the link upper bound, the throughput difference weakens and converges. This reflects the dual upper-bound switching mechanism described by Equations (1) and (3): after the bottleneck shifts from CPU to the link, the marginal impact of differential path costs on throughput decreases.

Implication (Meaning and boundaries under the embedded + generic constraint). On embedded platforms that only support XDP generic, converging the critical path and minimizing the action set to compress differential costs can still yield reproducible system-level benefits in CPU-bound small-packet scenarios. However, once the bottleneck shifts to the link or to endpoint generation/receiving capability, these gains become constrained by the upper-bound mechanism and tend to converge. Therefore, these results should be interpreted as a structural advantage demonstrated under controlled dominant-core, single-link, and single-queue conditions, rather than as a universal ranking that necessarily holds across all deployment scenarios.

5. Conclusions and Future Work

In conclusion, this paper studies the practicality of lightweight Layer-2 forwarding under embedded generic-XDP constraints on RK3588. Rather than claiming a new packet-processing primitive, the work provides a constrained-setting forwarding design, an explanatory cost-decomposition framework, and controlled experimental validation of both the source of benefit and its applicability boundary. The results show that XDP generic exhibits reproducible structural advantages over Linux Bridge in the CPU-bound small-packet regime, while the difference naturally narrows as the bottleneck shifts toward the link-bandwidth limit. These findings indicate that, even when generic-mode constraints retain copy operations and sk_buff-related overheads, meaningful gains can still be obtained through data-path simplification in embedded environments.

It should be emphasized that our conclusions are established under controlled execution conditions, including dominant-core convergence as an approximation, a single link and a single queue, and the assumption that endpoint capabilities do not dominate the bottleneck. When the system introduces multi-queue/multi-core parallelism, more complex forwarding actions, or when the bottleneck shifts to the endpoints, the dominant performance factors and the magnitude of benefits may change; the applicability boundaries therefore need to be revalidated under more general configurations. Power-aware evaluation would also be valuable, but the current RK3588 testbed does not provide synchronized fine-grained power instrumentation for the forwarding path; therefore, PPS/Watt analysis is left for future work rather than estimated with loosely matched external measurements.

Future work can follow a “from generic to native” trajectory. On newer embedded platforms that support native XDP, including future Rockchip- or Allwinner-based systems with improved NIC and driver support, the same experimental topology and statistical conventions can be reused to compare the key sources of overhead across execution modes and to further evaluate scalability under multi-core and multi-queue settings [21]. In addition, while keeping the action set minimal, more application-relevant forwarding semantics can be introduced to examine the upper bound of benefits and the associated costs of this design principle under more complex logic. Beyond forwarding-path optimization itself, another promising direction is to jointly consider communication reduction and task placement through adaptive compression [22] or compression-aware offloading [23]. This is particularly relevant to edge vision workloads, where the volume and structure of transmitted data can significantly affect end-to-end system efficiency. Incorporating such mechanisms may help extend the present lightweight data-plane design toward more communication-aware and application-coupled edge deployments.