Software Design Patterns for Latency Measurements with eBPF in SDN Environments

Software Design Patterns for Latency Measurements with eBPF in SDN Environments Pedro Lucas M. S. Rosa∗ , Bruno L. Dalmazo† , Leticia S. Machado∗ , Jéferson Campos Nobre∗ ∗ Institute of Informatics

M AC A C N E U P SC TE RI D PT

arXiv:2611.04973v1 [cs.PF] 3 Nov 2026

Federal University of Rio Grande do Sul, Porto Alegre–RS, Brazil pedro.sousa@ufgrs.br, leticia.machado@inf.ufrgs.br, jcnobre@inf.ufrgs.br † Computing Science Center Federal University of Rio Grande, Rio Grande–RS, Brazil dalmazo@furg.br

Abstract—This work proposes, implements, and evaluates a modular architecture based on software design patterns applied to latency measurement in Software-Defined Networks (SDN) using the Extended Berkeley Packet Filter (eBPF) and the Express Data Path (XDP). Unlike approaches that focus solely on measurement precision, this study examines how design patterns can structure observability systems in an extensible and maintainable way while preserving data-plane efficiency. The proposed architecture applies the Observer, Strategy, and Factory Method patterns to modularize the metric collection and analysis pipeline, allowing dynamic integration of policies and data sinks. The experimental environment was implemented with Mininet, Python agents, and eBPF/XDP programs, and was evaluated in terms of processing time, overhead, and evolution effort. The results show that the introduction of design patterns show no clear evidence of measurable degradation or performance, maintaining continuous measurements with a minimum of 5% overhead. The findings suggest that software engineering practices may be applied to the construction of eBPF-based monitoring and observability systems. Index Terms—eBPF, XDP, One-Way Delay, Network Observability, Software Design Patterns, Kernel-Level Monitoring.

I. I NTRODUCTION

The advancement of communication technologies and the growing demand for distributed, latency-sensitive applications have motivated the exploration of new approaches to network monitoring. In particular, the Extended Berkeley Packet Filter (eBPF) and the Express Data Path (XDP) have emerged as useful tools for kernel-level instrumentation, enabling relatively precise measurements with modest overhead [1]. These mechanisms have been applied in different domains, from cloud systems and microservices [2], [3] to software-defined networking (SDN), providing improved visibility of traffic and programmable network functions [4]. Although eBPF/XDP enable highly efficient and precise latency measurements, existing solutions often treat the software architecture of the collection pipeline as a secondary concern. As a result, many approaches prioritize data-plane instrumentation while neglecting architectural aspects such as modularity, extensibility, and controlled evolution, leading to

This manuscript has been accepted for presentation at the IEEE International Symposium on Computers and Communications (ISCC 2026).

tightly coupled and hard-to-evolve systems. This lack of architectural guidance constitutes a recurring software engineering problem that hinders maintainability, long-term reuse, and experimental reproducibility of eBPF/XDP-based observability solutions [5]. However, most existing studies focus on point solutions for observability without adopting software design patterns that promote reuse and modular organization [6]. This limitation makes eBPF/XDP-based monitoring solutions harder to maintain and extend, and reduces their experimental reproducibility [7]. Thus, the main issue explored in this work is not latency measurement itself, but the lack of structured guidelines to support the development of measurement systems based on eBPF/XDP. We therefore investigate how design patterns can be applied to structure and evaluate latency measurement architectures in a systematic, sustainable, and extensible way. To the best of our knowledge, prior works evaluate eBPF-based latency measurement primarily from a dataplane optimization perspective, without explicitly formalizing the collector architecture using software design patterns. Recent research demonstrates eBPF efficiency in real-time metric collection, highlighting its precision and scalability [8]– [10]. Other works address its integration with security and observability mechanisms in containerized and cloud environments [11]–[13]. Nonetheless, these approaches emphasize dataplaneaspects while neglecting the underlying software design. In the SDN context, studies such as [14], [15] reinforce the need for modular architectures that reconcile performance with design clarity, a gap this article aims to fill by formalizing the use of design patterns applied to latency measurement. Based on this gap, this work proposes a modular and standardized architecture for one-way delay (OWD) measurements in programmable networks, integrating eBPF/XDP with a software layer structured around classic engineering patterns. The architecture comprises three layers: (i) the data plane, implemented in the kernel via XDP; (ii) the user-space control plane, with Python agents; and (iii) a modular HTTP collector structured with the Observer, Strategy, and Factory Method patterns. This integration enables continuous measurements with reasonable accuracy with minimal overhead and supports dynamic reconfiguration of the observability pipeline.

On the software engineering side, the literature is scarce regarding formalization of architectural patterns for eBPFbased systems. This work differs by proposing an event-driven collection architecture that incorporates Observer, Strategy, and Adapter/Factory, and by demonstrating that such abstractions maintain performance while reducing evolution effort. Therefore, this work addresses a practical gap between network programmability and software engineering by proposing a simple and standardized event-driven architecture for continuous latency measurement using eBPF. Unlike prior studies that mainly focus on kernel-level optimizations or dataplane performance, this approach emphasizes modular and reusable software components based on well-known design patterns, while preserving low overhead. As a result, the proposed architecture can be more easily extended and applied in real operational scenarios, including latency-sensitive and safety-critical applications such as connected health systems.

M AC A C N E U P SC TE RI D PT

The contributions of this article include: (i) the design of an architectural model that applies software design patterns to latency monitoring using eBPF/XDP, targeting higher-speed dataplane environments; (ii) the implementation and experimental validation of this model in an SDN setting using Mininet; and (iii) a quantitative and qualitative analysis of the impact of modularity and abstraction on extensibility and dataplane performance. The results demonstrate that continuous latency monitoring can be achieved with software modularization while maintaining dataplane overhead below 5%. The remainder of this article is organized as follows: Section II presents theoretical foundations and related work; Section III describes the methodology and proposed architecture; Section IV details the experimental environment and results; Section V discusses observations and threats to validity; and Section VI concludes and outlines future directions. II. R ELATED W ORK

Several recent studies have explored the use of eBPF and XDP for network monitoring and observability of distributed systems. However, most concentrate on specific optimizations or on cloud and microservice scenarios, without directly addressing the application of software design patterns to continuous latency measurements. Efficient Continuous Latency Monitoring with eBPF [8] proposes a framework for continuous one-way delay monitoring with eBPF, demonstrating microsecond precision and low overhead. Although promising, the solution is centered on kernel adjustments and does not address collector modularity. Similarly, Analysis and Optimization for Passive One-Way Delay Measurement Tax in Container Networks [9] investigates passive OWD measurements in container networks, analyzing processing impact and costs. The focus is on dataplane efficiency, without considering software engineering or architectural extensibility. In distributed-system observability, ViperProbe [2] and eBPF-Enhanced Complete Observability Solution for CloudNative Microservices [3] apply eBPF to collect metrics, logs, and traces in microservice environments. Both explore data integration for real-time diagnostics but do not present a reusable software model, limiting adaptation to contexts such as SDN or latency-sensitive applications. Research on integrating eBPF with SDN, such as Efficient Network Monitoring Applications in the Kernel with eBPF and XDP [6] and Traffic Monitoring Applications Using Programmable Networks and eBPF [5], shows that dataplane instrumentation can be performed directly in the kernel. These works emphasize performance and scalability but do not address standardization of collection software or the use of design patterns. In SDN architectures, Protocol-Independent Hardware SDN Router [14] and Open Chain: Kernel-Based SFC Architecture Using eBPF [4] advance integration between SDN controllers and kernel eBPF functions, but focus on forwarding and filtering rather than latency measurement or modular observability.

III. A RCHITECTURE AND I MPLEMENTATION

This section describes the architecture and implementation of the proposed system, starting with a high-level overview and followed by component-level details. A. System Overview

The proposed system is designed to perform continuous latency monitoring with minimal impact on the dataplane while maintaining flexibility for analysis and evolution. The architecture follows a layered design composed of kernel-level instrumentation, user-space agents, and a modular collection and processing layer. Figure 1 presents the end-to-end pipeline, illustrating how packets are intercepted at the dataplane, transformed into latency events, and processed by modular decision and persistence components. B. Latency Measurement using eBPF/XDP

Latency measurements are performed using eBPF/XDP programs attached to the packet reception path. By intercepting packets at the earliest possible point in the networking stack, the system can reach microsecond-level timestamp precision under certain conditions while avoiding interference from higher-layer processing. Each packet is annotated with sequence identifiers and timestamps, enabling inference of one-way delay (OWD) without relying on clock synchronization between hosts. Since Mininet runs under a shared kernel and time base, OWD can be computed with sufficient precision for latency analysis. This measurement process is continuous and fixed, producing a regular stream of latency samples that serve as input for subsequent decision and reaction mechanisms. C. Latency Decision and Reaction Strategy While latency measurements are continuously collected using eBPF/XDP mechanisms, raw measurements alone are insufficient to guide operational decisions. The system must determine whether observed latency variations correspond to

Sequential Measurement Pipeline for One-Way Delay Kernel Layer

User Layer

Packet Interception XDP/eBPF program intercepts incoming packets, records timestamp and sequence number

Metric Collection & Processing Layer

Event Handling & Storage Packet Transmission & Reception

E. Kernel Layer: XDP/eBPF In the kernel layer, the eBPF/XDP program intercepts packets upon reception, recording timestamps and sequence numbers at the exact arrival moment. This capture occurs before socket allocation, ensuring microsecond-level precision. The program operates directly on the RX path, storing information in eBPF maps. Each map entry contains a sequence identifier, arrival timestamp, and send time, enabling inference of one-way delay without relying on inter-host synchronization. Collected events are exported to user space via eBPF maps or perf events, ensuring low communication cost and high sampling frequency.

M AC A C N E U P SC TE RI D PT

Sender transmits UDP packets with send timestamp; receiver consumes kernel events, computes delay, and publishes LatencyEvent

HTTP server receives LatencyEvent, processes it via monolithic or modular architecture, and stores results

impact on the dataplane and relatively high temporal precision. The system is structured into three complementary layers: (i) Kernel, (ii) User, and (iii) Collector. This organization enables separation of concerns, reduced coupling, and extensions without requiring changes to core measurement logic.

Fig. 1. End-to-end pipeline for one-way delay measurement using XDP/eBPF.

transient fluctuations or sustained performance degradation. To address this, we define an explicit latency-aware decision and reaction strategy, formalized in Algorithm 1.

Algorithm 1 Latency-Aware Decision and Reaction Strategy Input: Latency samples stream L, window size W , thresholds θlow , θhigh Output: Monitoring action A 1: LW ← CollectSamples(L, W ) ▷ Aggregate samples over a sliding window 2: p95 ← Percentile(LW , 95) ▷ Estimate tail latency 3: if p95 > θhigh then 4: A ← TriggerAlert ∧ EnableDetailedMonitoring 5: else if p95 > θlow then 6: A ← FlagAnomaly ∧ LogEvent 7: else 8: A ← LogMeasurement 9: end if 10: return A The proposed strategy aggregates latency samples over sliding windows to reduce sensitivity to short-lived spikes and relies on the p95 statistic to capture tail latency behavior. Two threshold levels are employed to distinguish between moderate and severe degradation, enabling proportional reactions such as logging, alerting, or monitoring escalation. This design preserves dataplane efficiency while helping support timely detection of abnormal latency conditions. D. Implementation Details The proposed architecture was designed to perform continuous one-way delay (OWD) measurements with limited

F. User Layer: Sending and Receiving Agents The user layer was implemented in Python using the BCC (BPF Compiler Collection) library to communicate with the kernel. Two agents were developed: sender and receiver. The sender agent transmits UDP packets containing the send timestamp in the payload. The receiver agent, running on another Mininet host, captures packet arrival via XDP, computes the one-way delay (OWD), and publishes the result in JSON format to an HTTP collection endpoint. Publishing occurs continuously, and each latency event is encapsulated in a LatencyEvent structure containing fields seq, latency_us, and timestamp. This structure standardizes communication across layers and enables the application of design patterns in the collector component. G. Metric Collection and Processing Layer The collection layer was developed in pure Python (stdlib), operating as an HTTP server responsible for receiving and processing events sent by the agents. Two collector variants were implemented: (i) Baseline and (ii) Patterns. In the Baseline version, the HTTP handler is monolithic: each POST request writes directly to a CSV file and, when enabled, applies a fixed threshold to trigger alerts. This version serves as the experimental control. In the Patterns version, the collector adopts a modular architecture structured around three design patterns: • Observer: latency events are published on an EventBus, allowing multiple subscribers to react independently. • Strategy: interchangeable analysis policies are defined, such as fixed thresholds or percentile-based sliding window analysis (P95WindowStrategy). • Adapter/Factory: persistence and alert sinks (e.g., CsvSink, JsonlSink, AlertSink) are instantiated uniformly without coupling to the collector core. The HTTP handler materializes each received event as a LatencyEvent and publishes it on the bus. Persistence, detection, and alerting logic are delegated to configured modules, keeping the core lightweight, reusable, and extensible.

H. Metrics and Experimental Processing

M AC A C N E U P SC TE RI D PT

Two complementary types of metrics were collected to evaluate both system behavior and architectural impact: • One-Way Delay (OWD, µs): computed as the difference between send and arrival timestamps obtained directly from the XDP sensor. • Evolution Effort: measured as the number of lines of code added or modified to implement equivalent extensions (e.g., p95/20 detection and JSONL persistence), computed using git diff --shortstat. To ensure experimental hygiene, a warm-up phase was applied by discarding the first five samples of each run. Additionally, outliers were trimmed using the statistical rule Q3 + 3 · IQR to mitigate transient effects of the virtualized environment. These practices ensured consistency across runs and reliability of the collected metrics, enabling fair comparison between the Baseline and Patterns implementations. Figure 1 summarizes the complete measurement pipeline, from kernellevel packet timestamping to modular metric processing and persistence.

6.8.0-40-generic, 4 vCPUs, and 4 GB RAM, ensuring stable performance during measurements. Experimental traffic consisted of UDP flows sent from h1 to h2 on port 5555, at approximately five packets per second for 20 seconds, totaling around 100 packets per run. The receiver agent executes the XDP program to record arrival timestamps and publish OWD results in JSON format to the collector’s HTTP endpoint. This process enables continuous measurement and correlation of pipeline behavior under different configurations (Baseline and Patterns). Before each experiment run, it is performed a warm-up period to stabilize measurements and minimize noise arising from system initialization. The first five samples of each run were discarded, and statistical outlier trimming was applied using Q3+3·IQR. This methodology ensured result consistency and comparability across implementation variants, isolating the impact of modularization introduced by the design patterns.

IV. E VALUATION

This section presents the experimental setup and evaluation results used to assess the proposed architecture. The experiments focus on performance, measurement accuracy, and modularity-related overhead. A. Experimental Environment

Experiments were conducted in an emulated environment to assess the proposed architecture under controlled, reproducible conditions. Mininet enabled simulating network topologies with isolation and precise control of traffic parameters while keeping the same Linux kernel and a shared time base among nodes. The experimental environment was built using a robust stack of networking and development tools, centered around Mininet for SDN topology emulation and Open vSwitch (OVS) to manage virtual switching. The core logic for the agents and the HTTP collector was developed in Python 3.8+, leveraging the BCC (BPF Compiler Collection) to provide a Python-based interface for interacting with the eBPF subsystem. Additionally, the collector was implemented using standard Python libraries, specifically http.server for network communication and csv and json for efficient data handling and storage. The topology comprised two hosts (h1, h2 and one switch interconnecting them (s1), plus an external host r0 running the HTTP collector. In this network setup, h1 acts as the UDP packet sender responsible for embedding send timestamps in the payload, while s1 functions as the virtual switch (OVS) handling link-layer forwarding. On the receiving end, h2 runs a python script to compute One-Way Delay (OWD) and forward the results to r0, an external host connected to the Mininet network that operates an HTTP collector. The environment ran on a virtual machine with Ubuntu 22.04 LTS, kernel

B. Experiments

The experiments were conducted to assess the behavior of the proposed architecture under controlled conditions, by comparing a Baseline (monolithic) implementation with a Patterns version that incorporates Observer, Strategy, and Adapter/Factory abstractions. The evaluation addresses three research questions (RQs): (i) qualitative aspects related to observability and system structure (RQ1), (ii) the impact on measurement performance and precision (RQ2), and (iii) the effort required for architectural evolution (RQ3). Each experimental run generated approximately 100 OWD measurements, which were processed in real time by the HTTP collector. Quantitative analysis showed that per-request processing time (processing us) remained stable, on the order of tens of microseconds, with no significant differences between Baseline and Patterns. After discarding the first five samples (warm-up) and trimming with Q3 + 3 · IQR, we observed: • Median (p50) processing time between 21–22 µs; • Mean between 26 and 27.5 µs; • 95th percentile (p95) below 40 µs. These results indicate that collector modularization did not show a clearly perceptible overhead in this environment. Differences between versions were statistically negligible within the expected variability of the virtualized environment. The collected OWD statistics presented stable behavior for both implementations. One-way latency measurements (latency us) were consistent across runs, with minimal variation between Baseline and Patterns. This demonstrates that the modular pipeline appears to have limited influence on the data plane, preserving collection accuracy even with added observers and dynamic strategies. Figure 2 illustrates the OWD sample distribution and the similar behavior between the two approaches. Collector stability suggests that modularization and the use of design patterns do not adversely affect data-path performance, supporting the premise that software abstractions can be introduced without degrading the efficiency of an

M AC A C N E U P SC TE RI D PT

adding P95WindowStrategy and AlertSink—demonstrating the architecture’s structural flexibility. Direct observation of logs and metrics confirmed that the patterns-based pipeline offered greater readability, traceability, and control over the event flow—desirable traits in continuous monitoring environments. Table I summarizes the main experimental results. The data show that using design patterns brought clear benefits in modularity and extensibility without compromising efficiency or measurement precision. Performance remained equivalent to the monolithic version, and evolution effort decreased as new components were incorporated. These results provide empirical evidence addressing RQ1–RQ3 and suggest that software engineering principles can be applied to eBPF/XDPbased measurement pipelines without sacrificing performance or operational simplicity. TABLE I S UMMARY OF METRICS OBTAINED IN THE EXPERIMENTS

Fig. 2. OWD distribution between Baseline and Patterns variants after statistical trimming.

eBPF/XDP-based system. To assess architecture extensibility and maintainability, we performed two identical tasks on both collectors: (A) implementing a 95th-percentile sliding-window policy (p95/20); and (B) adding a new data destination (JSONL sink). The required effort was estimated by measuring the number of lines of code (LOC) changed using git diff --shortstat, a commonly used proxy for maintenance and upgrade effort. Results showed that, for the first evolution (A), the Patterns collector required a slightly higher number of lines due to introducing classes and EventBus infrastructure. However, subsequent evolutions demanded minimal changes, since the modular architecture allows adding new components without editing the collector core. From the second task (B) onward, the marginal evolution cost decreased significantly: new Sinks or Strategies could be added by simply subscribing to the event bus, without changing the HTTP handler. This evidence suggest adherence to the Open/Closed principle, enabling extension via composition rather than modification, an essential characteristic in monitoring systems that require rapid adaptation and maintenance.

C. Qualitative Evidence of Observability During experiments, the online alert log generated by the p95/20 strategy recorded immediate detection of high tails in the first measurement windows. In initial runs, p95 us values near 5.4 s were observed due to environment warmup—expected behavior for XDP in generic mode. This behavior was mitigated by the warm-up strategy and the statistical trimming applied in the offline analysis. Notably, these adjustments required no changes to the HTTP handler code—only

Metric p50 OWD (µs) p95 OWD (µs) Mean OWD (µs) Average overhead (µs) LOC (evolution A) LOC (evolution B)

Baseline 21.3 38.7 26.0 22.1 47 39

Patterns 21.5 39.2 27.5 23.0 61 17

D. Discussion

The results presented here show that applying software design patterns to eBPF/XDP measurement pipelines is feasible and effective. The modular architecture preserved the same performance as the monolithic collector while improving organization, flexibility, and ease of evolution. This section revisits the RQs in light of the experimental findings. 1) RQ1: Architecture and Observability: The combination of Observer, Strategy, and Adapter/Factory patterns produced a loosely coupled and flexible collector. The core domain, centered on the LatencyEvent and the HTTP handler, remained stable even after adding new strategies and sinks. Using the EventBus as mediator allowed independent reaction to latency events, simplifying testing and maintenance. During experiments, enabling the p95/20 strategy was sufficient to detect latency variations without modifying the collection logic, demonstrating effective separation of concerns and improved observability. 2) RQ2: Performance and Collector Neutrality: The OWD distributions of the Baseline and Patterns versions were equivalent. Average processing time remained around 26–27 µs, with the 95th percentile below 40 µs. This indicates that introducing abstractions did not compromise data-path efficiency. Because the collector operates in the control plane and only processes events published by the XDP agent, its overhead is minimal and isolated from the dataplane. Small variations are explained by the virtualized setup, including xdpgeneric mode and host OS interference.

These results answer RQ2 by showing that modularization is neutral with respect to performance and suitable for continuous observability systems. 3) RQ3: Extensibility and Code Evolution: Although introducing patterns increases the initial implementation effort, subsequent changes become simpler and more predictable. New components, such as a JSONL sink or a percentilebased strategy, were added by implementing new classes and subscribing them to the event bus, without modifying the system core. This behavior directly addresses RQ3, demonstrating that the architecture supports evolution through extension rather than modification, reducing maintenance effort over time.

ACKNOWLEDGMENTS This work was supported by CNPq (Process 315427/20230), FAPERGS (Process 24/2551-0000727-0) and CAPES (Finance Codes 88887.954253/2024-00 and 001). It is also part of the INCT of Intelligent Communications Networks and the Internet of Things (ICoNIoT)(405940/2022-0). R EFERENCES [1] F. Holik, S. Jouet, and D. Pezaros, “An ebpf-based programmable network architecture for ot digital resilience use-cases,” in 2025 IEEE Symposium on Computers and Communications (ISCC), 2025, pp. 1–6. [2] J. Levin and T. A. Benson, “Viperprobe: Rethinking microservice observability with ebpf,” in 2020 IEEE 9th International Conference on Cloud Networking (CloudNet). IEEE, 2020, pp. 1–8. [3] B. Sharma and D. Nadig, “ebpf-enhanced complete observability solution for cloud-native microservices,” in ICC 2024-IEEE International Conference on Communications. IEEE, 2024, pp. 1980–1985. [4] M. S. Castanho, C. K. Dominicini, and M. A. Vieira, “Cadeia-aberta: Arquitetura para sfc em kernel usando ebpf,” in Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuı́dos (SBRC). SBC, 2019, pp. 763–776. [5] E. R. Santos, E. P. C. Júnior, M. A. Vieira, and L. F. Vieira, “Aplicações de monitoramento de tráfego utilizando redes programáveis ebpf,” in Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuı́dos (SBRC). SBC, 2019, pp. 417–430. [6] M. Abranches, O. Michel, E. Keller, and S. Schmid, “Efficient network monitoring applications in the kernel with ebpf and xdp,” in 2021 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN). IEEE, 2021, pp. 28–34. [7] R. Li, Z. Zhou, Z. Zhang, J. Guo, and Q. Liu, “Mv-tfnet: Malware traffic detection based on multi-view flow sequence and time-frequency feature fusion,” in 2025 IEEE Symposium on Computers and Communications (ISCC), 2025, pp. 1–7. [8] S. Sundberg, A. Brunstrom, S. Ferlin-Reiter, T. Høiland-Jørgensen, and J. D. Brouer, “Efficient continuous latency monitoring with ebpf,” in International Conference on Passive and Active Network Measurement. Springer, 2023, pp. 191–208. [9] J. Xie, C. Ma, H. Yu, L. Luo, and G. Sun, “Analysis and optimization for passive one-way delay measurement tax in container networks,” in 2024 IEEE 17th International Conference on Cloud Computing (CLOUD). IEEE, 2024, pp. 247–255. [10] M. Repetto and A. Carrega, “Monitoring network flows in containerized environments,” in Cybersecurity of Digital Service Chains: Challenges, Methodologies, and Tools. Springer, 2022, pp. 32–55. [11] J. Nam, S. Lee, P. Porras, V. Yegneswaran, and S. Shin, “Secure intercontainer communications using xdp/ebpf,” IEEE/ACM Transactions on Networking, vol. 31, no. 2, pp. 934–947, 2022. [12] M. Feng, J. Zhou, and Y. Tang, “Enhancing cloud-native security through ebpf technology,” in 2024 IEEE 11th International Conference on Cyber Security and Cloud Computing (CSCloud). IEEE, 2024, pp. 165–168. [13] G. Jin, J. Li, and G. Briskin, “Enhanced ebpf verification and ebpfbased runtime safety protection,” in 2024 IEEE Security and Privacy Workshops (SPW). IEEE, 2024, pp. 224–230. [14] R. D. G. Pacı́fico, L. F. D. S. Duarte, M. S. Castanho, J. A. M. Nacif, and M. A. M. Vieira, “Sistema de processamento de pacotes serverless,” in Simposio Brasileiro de Redes de Computadores e Sistemas Distribuidos (SBRC). SBC, 2020, pp. 183–196. [15] D. Carvalho, V. E. Quincozes, S. E. Quincozes, J. F. Kazienko, and C. R. P. dos Santos, “Bg-idps: Detecção e prevenção de intrusões em tempo real em switches ebpf com o filtro de pacotes berkeley e a metaheurı́stica grasp-fs,” in Simpósio Brasileiro de Segurança da Informação e de Sistemas Computacionais (SBSeg). SBC, 2022, pp. 139–152.

M AC A C N E U P SC TE RI D PT

E. Practical Implications The findings suggest that design patterns are a practical choice for building continuous observability solutions on top of eBPF/XDP. Modularization enables new metrics, policies, and output formats (CSV, JSONL, time series) to be added without destabilizing the system. More broadly, observability pipelines should be designed as evolvable software systems rather than ad hoc measurement scripts. The results reinforce that modularity and extensibility can be achieved without sacrificing performance, even in latency-sensitive environments. Collector neutrality with respect to the dataplane confirms that precise measurements can be introduced without interfering with operational traffic, which is essential in real-time and critical applications.

and physical environments with time synchronization, as well as extend the pipeline with additional metrics such as jitter and packet loss to further assess its applicability in real-world monitoring systems.

F. Threats to Validity The study has limitations related to environment, metrics, and topology. OWD measurements in Mininet rely on a single time base, and outliers were removed using Q3 + 3 · IQR. The Processing_us metric does not capture the full XDP cost but enables fair comparison. The simple topology limits external validity. Small windows may introduce variation, although we used ≥20 samples and structured logs.

V. C ONCLUSION AND F UTURE W ORK This work presented a modular architecture for OWD measurement using eBPF, combining kernel-level precision with established software design patterns. We investigated whether abstractions such as Observer, Strategy, and Adapter/Factory could be introduced without compromising performance while improving extensibility and code organization. Experiments conducted in a Mininet environment show that the modular version maintains processing time and latency behavior comparable to the monolithic baseline, with no observable impact on data-plane efficiency. At the same time, the architecture became easier to evolve, allowing new detection strategies and data sinks to be added with less modification effort. These results indicate that high-performance measurement with eBPF/XDP can coexist with a clean and maintainable software structure. As future work, we plan to evaluate the architecture in more diverse scenarios, including native XDP deployments

Related documents

• An Agnostic Approach to Building Empirical Type Ia Supernova Light Curves: Evidence for Intrinsic Chromatic Flux Variation Using Nearby Supernova Factory Data#1165856
• TSNBench: Benchmarking LLM Proficiency in Time-Sensitive Networking#175172
• OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type#476302
• Dynamic Link Exchange Protocol (DLEP) Latency Range Extension#502372
• Matched-View Cross-Domain Evaluation of WireGuard VPN Traffic Classification Using Early-Flow Fingerprints#622480