Kernel-Bypass mit DPDK im Trading.

Der Linux-Netzwerkstack ist ein technisches Wunderwerk — aber für Trading-Latenzen im einstelligen Mikrosekundenbereich ein Hindernis. Kernel-Bypass-Frameworks wie DPDK, Solarflare Onload oder OpenOnload sprechen direkt mit der Netzwerkkarte, ohne Umweg über den Kernel. Lohnt sich die Komplexität?

Warum der Kernel im Weg steht.

Ein normales recv() über einen TCP-Socket durchläuft eine erstaunliche Zahl von Schichten: Netzwerkkarte schreibt per DMA in einen Ring, löst einen Interrupt aus, der Interrupt-Handler scheduliert SoftIRQ, dieser läuft durch den Netzfilter, dann durch den IP- und TCP-Stack, kopiert Daten in Socket-Buffer, der User-Thread wird geweckt, ein Kontextwechsel passiert, schließlich liest die Anwendung. Selbst auf einem gut getunten System kostet das 5–15 Mikrosekunden — manchmal mehr.

Kernel-Bypass eliminiert fast alle diese Schritte. Die Anwendung pollt direkt die Karte, Pakete werden in vorab gemappten DMA-Regionen sichtbar, der TCP/UDP-Stack läuft im User-Space. Resultat: 1–3 Mikrosekunden End-to-End, deterministisch, ohne Interrupt-Jitter.

Die Werkzeuglandschaft.

Drei Hauptansätze haben sich etabliert:

• DPDK (Data Plane Development Kit): Open Source, ursprünglich von Intel. Funktioniert mit vielen Netzwerkkarten, eigene Treiber im User-Space, Poll-Mode-Driver. Lernkurve steil, Ökosystem groß.
• Solarflare/AMD Onload: kommerzielle Bibliothek, die existierende Socket-API drop-in ersetzt. LD_PRELOAD, kein Code-Change nötig. Sehr beliebt in der Finanzindustrie, weil die Migration so einfach ist.
• XDP/AF_XDP: Linux-natives eBPF-Framework. Nicht ganz so schnell wie DPDK, aber besser integriert. Wird in den nächsten Jahren wichtiger.
• io_uring: kein echter Bypass, aber drastisch effizienter als klassische Sockets. Für viele Anwendungen ausreichend.

DPDK in der Praxis: ein UDP-Receiver.

Ein minimaler Multicast-Receiver in DPDK sieht so aus (vereinfacht, ohne Init-Boilerplate):

#include <rte_eal.h>
#include <rte_ethdev.h>
#include <rte_mbuf.h>

#define RX_BURST 32

static int rx_loop(void* arg) {
    const uint16_t port = *static_cast<uint16_t*>(arg);
    struct rte_mbuf* bufs[RX_BURST];

    while (true) {
        const uint16_t nb = rte_eth_rx_burst(port, 0, bufs, RX_BURST);
        if (nb == 0) continue;

        for (uint16_t i = 0; i < nb; ++i) {
            auto* m = bufs[i];
            auto* eth = rte_pktmbuf_mtod(m, struct rte_ether_hdr*);
            // Layer-2/3/4 manuell parsen, payload extrahieren
            process_market_data(rte_pktmbuf_mtod_offset(m, uint8_t*, 42),
                                m->data_len - 42);
            rte_pktmbuf_free(m);
        }
    }
    return 0;
}

Auffällig: keine Sockets, keine recv-Aufrufe, kein Kernel. Stattdessen rte_eth_rx_burst — ein Poll auf die Karte. Die Schleife läuft auf einem dedizierten Core (isoliert via isolcpus) bei 100 % CPU. Das ist Absicht: Sie tauschen CPU-Auslastung gegen Latenz.

Was Sie dabei aufgeben.

Kernel-Bypass ist kein „freier" Performance-Gewinn. Sie verlieren konkret:

• Den TCP-Stack des Kernels. Sie brauchen einen eigenen (mTCP, F-Stack, eigener) oder beschränken sich auf UDP — was im Market-Data-Empfang oft ausreicht, im Orderversand aber nicht.
• Klassische Werkzeuge: tcpdump, iptables, Routing-Tabellen, alles im Kernel. Diagnose wird mühsamer.
• Multi-Tenancy: die Karte (oder VFs) gehört einer Anwendung.
• CPU-Auslastung: Poll-Mode bedeutet 100 % Last auf einem Core, rund um die Uhr.

NIC, Tuning, Topologie.

Die Wahl der Netzwerkkarte ist entscheidend. Für DPDK sind Intel-XL710-Serie, Mellanox-ConnectX-5/6/7 oder die Solarflare-X2-Familie üblich. Wichtig ist Cut-Through-Routing auf dem Switch, kurze Kabel und vor allem ein klar definierter, deterministischer Pfad. Wer Co-Location bei einer Börse hat, weiß das — wer es nicht hat, sollte die Mühe gar nicht erst beginnen.

Auf der Server-Seite kommt das übliche Low-Latency-Tuning dazu: BIOS auf „Performance" stellen, C-States aus, P-States fixiert auf Maximum, Hyperthreading aus oder gezielt verwendet, isolcpus für die Trading-Cores, NUMA-affine Speicherallokation, Huge Pages für die DPDK-Mempools.

Was es wirklich bringt.

Konkrete Zahlen aus Messreihen auf realen Mandanten-Setups:

• Standard-Linux-Socket, getuned: ~12 µs Median, ~80 µs P99.
• SO_BUSY_POLL plus io_uring: ~6 µs Median, ~25 µs P99.
• Solarflare Onload: ~2.5 µs Median, ~6 µs P99.
• DPDK auf isoliertem Core: ~1.5 µs Median, ~3 µs P99.

Die Sprünge sind real. Aber: Diese Zahlen sind nur Netzwerk-Stack-Latenz. Die Anwendungslogik kommt obendrauf. Wenn Ihr Strategie-Code 50 Mikrosekunden für eine Entscheidung braucht, gewinnen Sie durch DPDK nichts — Sie haben das falsche Problem adressiert.

Wann es sich wirklich lohnt.

Drei Use-Cases, in denen Kernel-Bypass spürbar Edge bringt:

1. Latency-Arbitrage zwischen Venues — jede Mikrosekunde gewonnen bedeutet höhere Fill-Quote.
2. Market-Making mit aggressiver Quote-Pflege — schnelleres Reagieren auf Marktbewegungen, weniger Adverse Selection.
3. Order-Cancellation in volatilen Phasen — wer schneller cancelt, blutet weniger.

Für eine systematische Strategie mit Haltedauern von Sekunden oder länger ist Kernel-Bypass ein teures Hobby ohne ökonomischen Nutzen.

Migrationspfad.

Wenn Sie sich entscheiden, in diese Richtung zu gehen, empfehle ich einen gestaffelten Ansatz: zuerst io_uring und Socket-Tuning ausreizen, dann Solarflare Onload als transparente Lösung (kein Code-Change), und nur wenn das immer noch nicht reicht, die Investition in DPDK mit eigenem Stack. Letzteres ist ein Mehrmonatsprojekt mit entsprechenden Personalkosten — keine Wochenendübung.

Sie überlegen, ob Kernel-Bypass für Ihre Strategie messbare Edge bringt? Erstgespräch buchen — wir analysieren Ihren kritischen Pfad und bewerten den Aufwand realistisch.