bthomas

“DPDK let us look at the header while it was still in L3 and write the payload exactly where the GPU expects it.” — Andre Renard

We needed the cluster to ingest over 6.4 Tb/s without major CPU resources.

Opening

“Instruments break not with loud bangs but with slow math: a firehose of packets the CPU can’t place, ring buffers that miss by a cacheline, correlators that stall because a matrix never quite arrived in order.”

When the Canadian Hydrogen Intensity Mapping Experiment (CHIME) started seeing the sky as streams of UDP from thousands of digitizers, Andre Renard had one job that mattered: get every packet where the GPU expects it, on time, without roasting host memory bandwidth.

CHIME’s design bet early on GPUs for correlation, cheap FLOPs, tensor cores on the horizon, rapid iteration. That created a different bottleneck: host memory. Traditional paths (kernel sockets, two-pass reorders, GPU-side reshuffles) burned cycles and DRAM bandwidth they didn’t have. Renard’s team started looking at DPDK.

The move was pragmatic. Poll-mode to avoid context switches; DDIO to inspect headers while the bytes are still in LLC; non-temporal writes to land payloads directly at precomputed strides. One pass across cache, one write to DRAM, one GPU read.

The Human Story

Andre Renard (University of Toronto / CHIME Collaboration) joined CHIME as project staff: a computer scientist embedded in a physicist-led experiment. “It’s definitely not a solo project,” he says. Multiple institutions, from UBC to Perimeter to McGill, share software development; 5-10 engineers contribute at any time across telescopes. Renard took the network path: FPGAs push UDP; GPUs correlate; the host makes it look easy.

“I’m proud we made the world’s largest radio correlator of its time actually work, bandwidth, antennas, the whole thing, and that our piece of the pipeline held up.”

Industry Consensus / Problem Identification

By the time CHIME began building, GPUs for radio astronomy had moved from a curiosity to a credible option. FPGAs and ASICs still dominated the front end, but matrix-heavy, low-bit-depth math made GPUs attractive and cost-effective. CHIME’s architecture took advantage of that:

• F-engine (FPGA): Digitize and channelize. Split broadband into thousands of narrow frequency channels; perform the corner-turn so each downstream node sees all inputs for a subset of frequencies.
• X-engine (GPU): Perform cross-correlation across all inputs (outer products → Hermitian matrices), then hand results to post-processing and imaging.

The catch was scale. The project moved UDP Packets at over 6.4 Tb/s across point-to-point links from F engines to X-engine GPU nodes. The canonical approaches in similar systems—split headers/payloads with verbs, land payloads, then second-pass reorder on CPU or GPU—double-touch DRAM and overuse cores.

“We hit host memory bandwidth early. That was our wall, more than PCIe or GPU FLOPs.”

The idea that “the kernel can take it” was a non-starter. Even older CHIME nodes ran ~25.6 Gb/s per CPU, and upgrades now target ~100 Gb/s per NUMA. That mandates kernel bypass and ruthless avoidance of extra passes.

Technical Challenge

Make a UDP firehose look like a tidy, GPU-ready matrix without:

• Using kernel sockets or copy-heavy paths
• Performing a reorder pass in CPU DRAM
• Wasting GPU global memory to reorder there
• Spinning too many cores on per-packet overhead

CHIME’s additional constraint: they maintain a RAM ring buffer of incoming baseband (raw) data. If an event (e.g., FRB) triggers, they pull the raw segment from RAM. SSDs can’t keep up (endurance and bandwidth), and spinning disks are out of the question at these rates. That rules out “NIC→GPU only” paths: the data must pass through host DRAM anyway.

“The dream of NIC DMA straight into GPU is nice, but our science needs a full-rate copy in host RAM.”

So the path had to both feed the GPU and preserve a DRAM copy, with minimal memory traffic.

The Unconventional Approach

The team leaned into three ideas:

• Poll-mode everywhere (DPDK): Avoid context switches and per-packet kernel overhead; dedicate cores; treat the CPU as a very fast, very predictable copier.
• DDIO locality: Receive into LLC; inspect headers while they’re still in L3; decide final destinations before touching DRAM.
• Non-temporal scatter-writes: From L3, perform NT stores into multiple DRAM offsets per packet, arranged so the GPU sees exactly the matrix tiles it expects.

This flips the usual reorder pattern. Instead of landing payloads “somewhere,” sorting later, and writing again, the RX path places each packet once where it belongs in the final GPU-consumable layout. Then the GPU reads once, and math begins.

“We can even scatter/gather: same packet payload written into multiple precomputed strides so the final matrix shape is perfect for the kernel.”

That last part matters in that correlation is outer products over many inputs and channels. Arranging memory in the right order translates directly into higher GPU occupancy and simpler kernels.

Cultural Translation

CHIME sits at the intersection of astronomy, HPC, and network systems. Each community brings different mental models:

• Astronomers speak in beams, baselines, and FRBs. The requirement is scientific: don’t drop packets; preserve baseband; map the sky.
• HPC/GPU folks want coalesced reads, tensor core throughput, and tile shapes.
• Network engineers obsess over queues, NUMA locality, and cachelines.

CHIME’s software framework, Kodakan, bridges the gap. It hides DPDK boilerplate (NIC init, RX queue mapping, core pinning) behind base classes and YAML pipeline descriptions. Teams across instruments can implement a new “stage” without learning every DPDK nuance or pthread trick.

“One binary can run different telescopes by swapping the YAML pipeline. In some limited cases, you can build a new instrument mostly by writing a new config.”

What It Actually Does

At the packet path level:

• F-engines send UDP frames containing channelized samples.
• DPDK poll-mode RX cores deque packets while they’re still in L3 (DDIO).
• The code parses a custom header (still hot) to compute target offsets.
• It performs non-temporal stores to scatter the payload into DRAM addresses computed from header details.
• A GPU stage then DMA-reads those regions and launches correlation kernels (outer products → Hermitian matrices).
• In parallel, a baseband ring buffer in host RAM retains a rolling window of raw data for later retrieval if a trigger fires.

Scope & limits (explicit):

Scope: Host-side packet → DRAM placement optimized for GPU consumption; baseband retention in RAM; portable across several telescopes via a shared framework.
Limits: UDP ingress expects packet order gaps; logic tolerates reordering but assumes very low loss; still host-DRAM mediated (no NIC→GPU direct placement), by design.

Addressing Concerns

“Isn’t verbs/RDMA the modern way?”
Renard’s team considered verbs-based split and reorder. The challenge: extra passes. Either a CPU second pass to reorder or a GPU reorder that burns global memory and adds complexity. Their constraint, full-rate baseband in RAM, means NIC→GPU doesn’t remove the DRAM trip. DPDK minimizes it to one write.

“Poll-mode wastes cores.”
They run on 6-core CPUs in many nodes, intentionally small, because the CPU’s job is mostly copy/placement with few cycles per packet. DPDK’s low overhead made that feasible. On newer 100 Gb/s per NUMA nodes, they add distributor cores; the model still holds.

“Kernel bypass is dated; smart NICs can fix this.”
Smart NICs or programmable NIC pipelines could help, but economics and programmability matter. Commodity NICs plus DPDK delivered, repeatedly, across multiple instruments. The hardware dream Andre sketches, programmable on-NIC address calculation from custom headers, remains compelling if it arrives as a commodity surface.

“The bet is simple: one pass across cache, one write to DRAM, one GPU read. Anything extra pays interest in costs bandwidth you don’t have.”

Real-World Impact

• CHIME correlator: At build time, largest radio correlator by bandwidth × antennas. The DPDK-based path is a critical link in sustained operations.
• Throughput milestones: Legacy nodes around 25.6 Gb/s per CPU; upgrades targeting 100 Gb/s per NUMA with distributor cores.
• Multi-site operations: Software and framework used across ~6 sites and by external users who download and adapt stages.
• Science enabled: Mapping 21-cm neutral hydrogen to probe baryon acoustic oscillations; pulsar timing; prolific fast radio burst (FRB) detection with outrigger stations for precise localization.
• Maintainable deployments: Preference for Ubuntu-bundled DPDK eases adoption across collaborations without bespoke build hurdles.

Reproduce It (Engineering Notes)

Goal: Land UDP payloads into GPU-ready DRAM tiles in a single pass.

Environment (representative):

• NIC: Commodity 10/25/100 GbE supporting DDIO on host platform
• CPU: 1–2 sockets; ensure NUMA-local RX queues; 6 cores workable at ~25 Gb/s; add distributor cores at 100 Gb/s/NUMA
• GPU: 4× per node typical; correlation kernels tuned for int4/int8/tensor cores
• RAM: Large (e.g., ≥1.5 TB per node) to hold baseband ring buffer
• DPDK: Use distro-packaged (Ubuntu) for reproducibility across sites; pin lcores via YAML/pipeline config in Kodakan

Build/Run sketch (framework-agnostic pseudocode):

// Pseudocode: single-pass placement
while (rx_dequeue(pkts, RX_BURST)) {
  for (pkt in pkts) {
    hdr = parse_header(pkt);              // still in LLC via DDIO
    // Compute one or more target offsets for scatter
    for (t in layout_targets(hdr)) {
      nt_store(t.dst, pkt->payload, t.len); // non-temporal write to DRAM
    }
  }
}
// GPU stage DMA-reads the arranged tiles and launches corr kernels.

Config checklist:

• Map RX queues to NUMA-local cores and target DRAM on the same socket.
• Disable interrupt moderation; poll-mode only.
• Use hugepages for DPDK mbufs; align scatter destinations to GPU-friendly strides.
• Validate LLC hit rates and memory ops with Intel PCM (or analogous counters).
• At 100 Gb/s, add a distributor core fan-out to multiple placement workers per NUMA.

Sanity checks:

• Zero-loss on long runs at target line rate (synthetic F-engine traffic OK).
• PCM shows ~2 memory ops/byte path (DRAM write, then GPU read).
• GPU kernels see expected tile shapes without an internal reorder step.

Trade-offs

• Host RAM dependency is intentional (for baseband capture); NIC→GPU bypass would under-deliver CHIME’s needs.
• Poll-mode demands dedicated cores; it buys predictability and low tail latency at the cost of idle power.
• Scatter-write complexity shifts logic to RX; it simplifies GPU kernels and reduces total memory traffic.

Community Impact

The correlator work sits alongside and in conversation with broader radio astronomy efforts, teams exploring NIC→GPU placement, terabit class ingress, and tensor-core-tailored kernels. Renard calls out ASTRON work (e.g., John Romein) exploring DPDK for GPU memory regions and extreme bandwidth. While CHIME’s current path stays DRAM-centric by design, these lines of work are converging on the same question: How do we feed accelerators at scale without melting host resources?

“Long term, everyone faces the same problem: feeding GPUs without burning CPUs or DRAM.”

Future & Next Steps

• CHIME X-engine upgrade: Modern GPUs, tensor-core kernels, updated Kotekan pipelines; sustained 100 Gb/s/NUMA paths.
• CORD (sister telescope): Dish-based array next to CHIME; newer FPGAs; similar DPDK path via a switch fabric.
• HIERAX (South Africa): Sister project targeting similar 100 Gb/s/NUMA ingest with Kotekan stages.

Wishlist for NICs + APIs:

• Bulk enqueue semantics akin to verbs: “Next N packets land at base + stride S”
• Programmable address calculators on NICs: turn custom headers into DMA addresses (and scatter lists)
• A commodity path for FPGA→RDMA encapsulation that’s feasible without massive RTL investments

How to Contribute

• DPDK stages in Kodakan: New packet processors for alternative F-engine formats; distributor-core strategies for 100G.
• Performance tooling: Portable PCM-like sampling, NUMA heatmaps, and cache residency metrics integrated into pipelines.
• GPU kernels: int4/int8 correlation kernels tuned for new tensor cores; memory-layout co-design with host scatter logic.
• Reliability: Long-haul, zero-loss regression harnesses; packet gap simulation; time-sync checks across multi-site deployments.

Onboarding path:

1. Start with docs/tests in Kodakan: run a synthetic F-engine generator → verify placement maps and GPU tiles.
2. Implement a toy stage: parse a minimal header, scatter to two destinations; validate with a tile checker.
3. Add metrics hooks (per-queue drops, L3 hit rate proxies, DRAM BW, GPU DMA time).
4. Join the mailing lists; discuss NUMA layouts and YAML pipelines before touching hot paths.
5. Only then propose core changes to shared DPDK abstractions.

Project links:

• https://github.com/kotekan/kotekan
• https://chime-experiment.ca/
• https://www.chord-observatory.ca/
• https://hirax.ukzn.ac.za/

Closing

Ask Renard what he’d change in DPDK, “It does what we need.” Then the engineer resurfaces: bulk enqueue semantics, on-NIC programmable address transforms, a commodity way for FPGAs to produce RDMA-placeable streams without heroic RTL. None of that contradicts CHIME’s DRAM-first reality. It simply opens options for the next instruments.

“I’d love a commodity NIC where I upload a tiny program: here’s my header, here’s the formula, put the packet exactly there.”

If you’re a developer who enjoys cachelines, NUMA maps, and the satisfaction of shaving one more pass off a hot path, CHIME’s approach shows the shape of the work: make placement decisions earlier; touch memory fewer times. Bring that energy to DPDK, to Kotekan, and to the telescopes that still need to be made real.

Get Involved: Review your first DPDK patch

---

About CHIME

The Canadian Hydrogen Intensity Mapping Experiment (CHIME) is a fixed, wide-field radio telescope located at the Dominion Radio Astrophysical Observatory near Penticton, British Columbia. It uses four stationary, 100-meter-long cylindrical reflectors in a drift-scan configuration: as Earth rotates, CHIME continuously maps a narrow north–south strip of the sky. Its science focuses on three pillars: 21-cm cosmology (tracing large-scale structure via neutral hydrogen and baryon acoustic oscillations), pulsar timing (including gravitational-wave–related studies), and fast radio bursts (FRBs), with outrigger stations added for high-precision FRB localization.

On the compute side, CHIME pairs FPGA “F-engine” front ends (digitization and channelization with a corner-turn) with GPU “X-engine” correlators that perform massive outer-product math to form visibilities and images. The collaboration spans multiple institutions—the Dominion Radio Astrophysical Observatory, McGill University, and many other institutions.—with shared software frameworks that enable related instruments (e.g., sister arrays in Canada and South Africa) to reuse pipeline components and configurations.

About the Linux Foundation

The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects, including Linux, Kubernetes, Model Context Protocol (MCP), OpenChain, OpenSearch, OpenSSF, OpenStack, PyTorch, Ray, RISC-V, SPDX and Zephyr, provide the foundation for global infrastructure. The Linux Foundation is focused on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

Last Updated: 03/19/2026

Tobias Roeder, Application Engineer at ipoque – a Rohde & Schwarz company, has spent years working at the intersection of deep packet inspection (DPI), open source packet processing, and telecom infrastructure. In a recent interview and follow-up to his DPDK Summit presentation, Tobias offered a candid view into how ipoque’s DPI engine integrates with DPDK rte_table API , and how their customer base, spanning startups to large telcos, leverages DPDK features to build intelligent, efficient, and secure networks.

DPI at Scale: A Practical Overview

ipoque provides a commercial DPI SDK that classifies traffic in real time without requiring decryption. It’s used to classify a wide variety of consumer and enterprise applications (e.g., WhatsApp, Netflix, MS Teams or VPN-Services) up to industrial IOT protocols (e.g. MQTT, Modbus, OPC UA..). The ultimate goal is to identify encrypted flows, and support decisions in firewalls, gateways, loadbalancers, UPFs, and other network functions.

While DPI isn’t new, its complexity has risen dramatically with the growth of encrypted and obfuscated protocols. As Tobias explains, “It used to be simple, most traffic was unencrypted or used more verbose TLS handshakes. Now, TLS 1.3 ESNI and QUIC obfuscation make traditional methods ineffective. Our DPI uses supervised machine learning to differentiate things like video-streaming versus video-downloading. ”

“It used to be simple, most traffic was unencrypted or used basic TLS. Now, TLS 1.3 and QUIC make traditional methods ineffective. Our DPI uses supervised machine learning to differentiate things like video-streaming vs video-downloading.”

Why DPDK?

For ipoque, DPDK serves as the abstraction layer that simplifies NIC access and enables rapid deployment across diverse environments, from embedded NXP devices to BlueField DPUs. “DPDK creates a very well-maintained base layer that abstracts away network card complexity,” Tobias notes. “It is our customers’ first choice of open-source packet processing frameworks.”

“DPDK creates a very well-maintained base layer that abstracts away network card complexity,” Tobias notes. “It is our customers’ first choice of open-source packet processing frameworks.”

Many of ipoque’s customers already have DPDK integrated into their stacks. Others migrate with Tobias’s team’s help. DPDK’s LTS stability and availability of tooling like testpmd are cited as core strengths in onboarding new users.

Feature Focus: Flow Offload and State Tracking

Two DPDK features stand out for ipoque’s use cases:

• rte_flow offload: After DPI classifies a flow (especially long-running “elephant flows” like video or file-transfers), it can be offloaded to the NIC for efficient hardware processing.
• rte_table / rte_cuckoo_hash: These libraries enable robust flow tracking, which is critical for stateful inspection. See details of performance comparisons in Tobias`s DPDK Summit presentation

These libraries simplify otherwise complex aspects of connection tracking, which would need to be built and maintained independently.

AI and ML in DPI

While AI in packet processing is often discussed at the infrastructure level (CI systems, test automation, or inference at the edge), ipoque integrates supervised Machine Learning and Deep Learning algorithms directly into its SDK. This helps identify traffic types even when protocol handshakes offer no visibility.

For instance, distinguishing a user video-streaming from video-downloading (both encrypted) is no longer feasible through traditional methods “Enhancing DPDK QoS with DPI allows for video optimization in 4G/5G packet cores.” Tobias explains.

“Enhancing DPDK QoS with DPI allows for video optimization in 4G/5G packet cores.”

Technical Challenges and DPI Resilience

Tobias acknowledges the performance burden posed by encrypted traffic and evolving transport protocols like QUIC. Features like multiplexed streams over UDP present new challenges to fair scheduling in mobile networks. For this reason, DPI-enabled user plane functions (UPFs) benefit from accurate traffic classification within DPDK-forwarding paths.

Recent Developments at ipoque and Rohde & Schwarz

Tobias’s insights also align with a wave of recent updates from the company:

• Encrypted Traffic Intelligence (ETI): Unveiled at MWC 2025, ETI enhances the classification of TLS 1.3, QUIC, and ESNI traffic using advanced AI without needing decryption. It’s embedded in ipoque’s core DPI engines.
• Open RAN DPI Analytics Report: A 2025 study showed that 74% of RAN vendors view DPI as critical to telemetry, real-time traffic analytics, and slicing logic in Open RAN deployments.
• Partnership with ElastiFlow: By combining IPFIX flow records with DPI insights, the collaboration brings observability into fine-grained, application-aware dimensions — especially valuable for CSPs managing encrypted or obfuscated traffic.
• Expanded 5G Solutions: At MWC, Rohde & Schwarz showcased next-gen monitoring and QoE/QoS tools that integrate ipoque’s DPI stack for real-time 5G visibility.

DPI and the Future of DPDK

When asked what excites him most about the future, Tobias points to cross-project collaboration and expanding DPDK’s reach beyond traditional telecom and networking. “It’s been amazing to see projects like radio telescopes and sensor analytics using DPDK. We’re eager to support use cases that aren’t just about routers, 4G/5G cores and firewalls.”

“It’s been amazing to see projects like radio telescopes and sensor analytics using DPDK. We’re eager to support use cases that aren’t just about routers, 4G/5G cores and firewalls.”

As protocols evolve and encryption deepens, DPI’s role becomes more nuanced. The toolkit must be accurate, passive, and fast, and the packet processing framework underneath must be efficient, adaptable, and stable.

For ipoque, DPDK is the first choice for user-space packet processing. And for the wider ecosystem, Tobias’s work highlights how DPI isn’t just surviving encryption, it’s evolving with it.

[img source p5. https://www.ipoque.com/media/brochures/Solution_guide_en_DPI_3608-7309-62_v0201_144dpi.pdf]

Learn More:

• ipoque DPI SDK Overview
• Encrypted Traffic Intelligence Press Release
• DPDK rte_flow Documentation
• Tobias 2025 Summit presentation

Kubernetes revolutionized application orchestration, but infrastructure management? Still a mess of REST APIs and shell scripts that barely integrate with the ecosystem. Guvenc Gulce and IronCore Team saw datacenter operators wrestling with networking solutions that treated Kubernetes as an afterthought, bolted on rather than built in.

The vision was clean: pure IPv6 underlay networks, software-defined overlays, SmartNIC offloading, all controlled through native Kubernetes APIs. No NAT boxes. No firewall appliances. Just L3 routing with SDN on top. One of the important challenges of this endeavor ? Building a dataplane fast enough to hit line-rate while maintaining the flexibility to integrate deeply with Kubernetes.

That’s where dpservice comes in – and where DPDK became essential.

The Gap in Infrastructure Management

“We thought that there was a need for a good solution for Kubernetes based infrastructure management for real and virtualized resources in a datacenter environment with software components designed from the beginning to integrate nicely with the Kubernetes ecosystem,” Güvenç explains.

That motivation drove the creation of dpservice as a key component of the SDN layer for IronCore – an open source, EU-funded project under The Linux Foundation and NeoNephos Foundation.

The problems in the open source infrastructure space were clear. “A lot of the infrastructure resource management projects were using REST APIs and/or script based solutions lacking operational logic and they would integrate half-heartedly with Kubernetes and they were not really designed with Kubernetes in mind,” Güvenç notes. These solutions treated Kubernetes as just another API endpoint rather than embracing it as the foundation for infrastructure orchestration.

The architectural vision went further.

“We also think that datacenter underlay traffic can be simple and only using IPv6 is enough. This would ease network operations and reduce the amount of used appliances in the datacenter. (NAT / Firewall boxes),” says Güvenç.

The idea: dpservice sitting on top of a simple IPv6 underlay network would offer software defined networking functionality by making use of SmartNICs, while IPv4 and IPv6 could still be offered in the customer virtual network.

This wasn’t about recreating existing virtual switches. It was about rethinking datacenter networking from first principles with Kubernetes as the control plane.

Why DPDK Was Non-Negotiable

When you’re building high-performance SDN, your options narrow quickly.

“If you need fast / low latency / high throughput software defined networking in datacenters, you don’t have that many options. EBPF and DPDK are the first two dominant technologies that come to your mind,” Güvenç explains.

The team chose DPDK for specific reasons: “it offers a rich ecosystem of libraries to develop the dataplane/packet processing logic and offers a nice software abstraction to offload the traffic completely to the hardware.”

The performance target wasn’t ambitious – it was absolute.

“By using DPDK, we can reach line-rate in the software defined network functions we use which is actually the highest performance you can get.”

Line-rate means the theoretical maximum throughput of the hardware. There’s no performance left on the table.

This matters because dpservice isn’t handling toy workloads. It’s the SDN layer for production infrastructure supporting virtualized and bare metal resources. Packet forwarding, routing, NAT, firewalling – all happening in software at wire speed. DPDK’s library ecosystem made this achievable without writing everything from scratch.

The hardware offload abstraction proved equally critical. SmartNICs can take over packet processing tasks entirely, but only if the software can communicate with them effectively. DPDK provides that layer, letting dpservice treat hardware acceleration as a configuration choice rather than a complete architectural rewrite.

What dpservice Actually Is

At its core, dpservice is a DPDK-based dataplane designed for a specific architectural vision. Unlike OVS-DPDK or VPP, it’s built around assumptions that simplify datacenter operations.

“OVS-DPDK and VPP are two prominent examples when it comes to DPDK based virtual switches and routers but they both also have their pros and cons and would not fit to our use-case 100%,” Güvenç explains. “OVS is very L2 oriented for example but our solution aims for simplifying the underlay network where we keep the L2 networks very small (2 members) and run the communication purely L3 based.”

VPP presented different challenges.

“VPP’s code is also mostly not based on DPDK libraries and has a steep learning curve, if you want to adapt it to your needs. DPDK is doing a much better job here and the VPP’s graph based dataplane approach can be used also in the DPDK ecosystem where dpservice is also doing it.”

The distinctive features emerge from these design choices. “The unique features of dpservice are being very L3 oriented, supporting IPv6 from the beginning, Supporting SR-IOV and hardware flow offloading from the beginning,” says Güvenç. The project also ships with “a kubernetes controller and API which can be used to create Virtual Networks, Virtual Interfaces and Network Functions.”

That Kubernetes integration isn’t an afterthought. The metalnet controller (https://github.com/ironcore-dev/metalnet) bridges dpservice into the broader IronCore ecosystem, making network resources manageable through standard Kubernetes patterns.

Güvenç’s own summary captures it well:

“dpservice project delivers a high-performance DPDK based dataplane for SR-IOV virtual functions, seamlessly integrating into Kubernetes environments through its metalnet controller to provide scalable software defined networking services.”

Why Kubernetes Integration Matters

The push for Kubernetes-native infrastructure management isn’t about following trends. “Seamless Kubernetes integration is important as we think that Software Defined Networking should have all the positive effects of a Kubernetes based infrastructure management, like self-healing of managed systems and easier Day-2 operations with a better central insight to the managed systems underneath,” Güvenç explains.

For operators, the abstraction changes daily work. “For an operator, the managed virtual machines, metal machines and virtual networks are like abstract resources and he doesn’t need to deal with specific machines and customer networks in the infrastructure. These are declared as kubernetes specifications and they get materialized with Kubernetes controllers in place. Operator’s job can be simplified and automated.”

The benefits extend to AI-driven operations. “It would be even easier to inject AI based decisions into an IaaS system which uses Kubernetes as there are mature AI based decision helpers which nicely integrate with Kubernetes,” notes Güvenç.

Developers gain leverage too. “A developer can also rely on the battle-tested Kubernetes libraries / testing frameworks when he/she develops his/her resource management logic and this would make possible to concentrate on the real value delivered (like in our case an SDN layer) as the rest is already a mature technology which can be leveraged.”

The observability story integrates naturally. “We also use Prometheus and Grafana from CNCF project suite to give a better observability to dpservice internals. Prometheus exporters can nicely integrate with DPDK’s telemetry interface.” The entire cloud-native ecosystem becomes available once you’re Kubernetes-native.

The IronCore and European Sovereign Cloud Context

dpservice doesn’t exist in isolation. It’s the SDN layer for IronCore, which tackles infrastructure-as-a-service challenges in the NeoNephos Foundation context. “IronCore is the project in Neonephos context which concentrates on infrastructure management. It is a typical IaaS project/offering and it is one of the important building blocks to provide the high level services in the sovereign cloud context, like platform mesh and it integrates nicely with other Neonephos projects like Gardener and Garden Linux.”

The European sovereign cloud effort addresses real concerns about infrastructure independence and data sovereignty. dpservice provides the high-performance networking layer that makes this vision technically feasible. “dpservice is providing the SDN layer of the IronCore IaaS and making it an important piece in the overall context.”

The project is young in the open source world. “The project is not so widely known yet as it was donated to The Linux Foundation only 3 months ago by SAP,” Güvenç notes. The contributor base reflects this early stage: “We have on our github page 14 contributors at the moment. I am the single maintainer and technical lead of the dpservice project at the moment but we have 3 more key people contributing to dpservice. The initiator of the project is Malte Janduda and the other two key contributors are Jaromír Smrček and Tao Li .”

The organizational backing is visible. “The organisations which are involved are also the same organisations which are members of the Neonephos Foundation. This can be seen publicly on the Neonephos page: https://neonephos.org/members“

Engaging with the DPDK Community

The dpservice team is actively seeking connections with the broader DPDK community.

“We would be happy to get feedback about the dpservice project from the DPDK community,” says Güvenç.

“I am already in close contact with the maintainers and technical committee of the DPDK and presented dpservice to them. We also explore possibilities of what we can upstream from dpservice to the DPDK ecosystem. There are the first ideas emerging like re-usable DPDK Graph nodes which can be contributed to the DPDK community.”

This upstream engagement could benefit both projects. DPDK gains real-world validation of its graph-based dataplane approach and potentially reusable components. dpservice gains visibility and community feedback that can strengthen the project.

What’s Coming Next

The roadmap is public and actively maintained: https://github.com/orgs/ironcore-dev/projects/13

Two major features dominate the near-term plan. “The most important two things we plan to do in the near future is to give the ability to dpservice encrypt the traffic leaving from it to the wire and decrypt the traffic it receives from the wire,” Güvenç explains. Wire-level encryption adds another layer of security for sovereign cloud deployments where data protection is paramount.

“The second important thing on the roadmap is to integrate High Availability to dpservice so that dpservice can run with two instances and there is the possibility of seamless failover from one instance to the other one.” Production infrastructure demands resilience, and HA support moves dpservice from interesting technology to production-grade component.

Getting Started and Contributing

You don’t need a datacenter to experiment with dpservice. The team built ironcore-in-a-box specifically to lower the barrier to entry. “If someone wants to try dpservice or IronCore. You don’t need first a complex infrastructure for it. We have the ironcore-in-a-box project which uses the Kind cluster to demonstrate the usage of the IronCore project. TAP device based dpservice is included. Installation is very easy.” (https://github.com/ironcore-dev/ironcore-in-a-box)

For developers looking to contribute, Güvenç provides clear starting points. “For the potential contributors, I would recommend to start with the developer documentation of dpservice https://github.com/ironcore-dev/dpservice/tree/main/docs/development and for the overall understanding of IronCore, I would recommend to start with the IronCore documentation https://ironcore.dev/iaas/getting-started.html and especially networking part of it.”

A technical deep dive is available for those who want more detail: https://guvenc.github.io/software%20engineering/2024/10/18/dpservice.html

The project welcomes engagement. “We also welcome contributions / comments and more stars for the GitHub page of the dpservice.” (https://github.com/ironcore-dev/dpservice)

The Reward

Building infrastructure software can be thankless work – months of effort invisible to end users. But Güvenç finds motivation in real-world impact. “I think the most exciting and rewarding moment is to see other people use dpservice / IronCore and they can get an added value out of it.”

The development experience itself offered early wins. “During the build phase it was very exciting to make fast progress to implement the first features of dpservice as the DPDK has nice examples and a wide range of libraries which make the first success moments quickly possible.”

That’s DPDK’s strength showing through – not just raw performance, but an ecosystem that accelerates development. When your networking dataplane needs to hit line-rate while integrating with Kubernetes, talk to hardware SmartNICs, and support production workloads, you need a foundation that handles the complexity. DPDK provides that foundation.

dpservice shows what becomes possible when you build on it.

---

Try dpservice:

• ironcore-in-a-box: https://github.com/ironcore-dev/ironcore-in-a-box
• dpservice repository: https://github.com/ironcore-dev/dpservice
• IronCore documentation: https://ironcore.dev/iaas/getting-started.html
• Technical deep dive: https://guvenc.github.io/software%20engineering/2024/10/18/dpservice.html
• metalnet controller: https://github.com/ironcore-dev/metalnet

Connect with the team on Linkedin:

Malte Janduda

Guvenc Gulce

Jaromír Smrček

Tao Li