# Network Interface Drivers: Architecture & High Performance

TL;DR / Management Summary Ein Netzwerktreiber ist mehr als nur ein Übersetzer. In modernen Linux-Systemen steuert er die Interaktion zwischen Hardware-Interrupts und dem Kernel-Stack. Schlüsselkonzepte wie NAPI (New API) verhindern Interrupt-Storms durch Polling unter Last, während DMA (Direct Memory Access) Daten ohne CPU-Last in den RAM schiebt. Für Admins ist das Verständnis von Ring-Buffern und Offloading-Features (LRO, TSO) entscheidend für das Fine-Tuning von 10GbE/100GbE-Infrastrukturen.

# 1. Einführung & Architektur

Vom Signal zum Paket.

Die Reise eines Pakets beginnt im PHY (Physical Layer) der NIC und endet im sk_buff (Socket Buffer) des Kernels. Der Treiber ist das Bindeglied.

# NAPI (New API)

Früher löste jedes Paket einen Hardware-Interrupt (IRQ) aus. Bei 1 Million Paketen/Sekunde würde die CPU nur noch Interrupts bearbeiten.

• Mechanismus: Der Treiber wechselt bei hoher Last vom Interrupt-Modus in den Polling-Modus.
• Vorteil: Die CPU “holt” sich Pakete gesammelt ab, wenn sie Zeit hat (SoftIRQs).

# Architektur-Diagramm (Mermaid)

graph TD
    NIC[NIC Hardware] -->|1. RX Packet| DMA[DMA Transfer to RAM]
    NIC -->|2. Hard IRQ| CPU[CPU]
    CPU -->|3. Schedule| SoftIRQ[SoftIRQ / ksoftirqd]
    SoftIRQ -->|4. Poll Driver| Driver[Driver / NAPI]
    Driver -->|5. Push to Stack| NetCore[netif_receive_skb]
    NetCore -->|6. Protocol| IP[IP / TCP Stack]

# 2. Driver Management in der Praxis

Hardware bändigen.

# Ring-Buffer (RX/TX)

Die NIC hat interne Warteschlangen (Ring-Buffer). Wenn diese voll sind, werden Pakete verworfen (dropped), bevor der Kernel sie sieht.

# Anzeigen der aktuellen Ring-Größen
ethtool -g eth0

# Erhöhen der RX-Buffer (falls Hardware unterstützt)
ethtool -G eth0 rx 4096

# Offloading Features

Moderne NICs übernehmen Aufgaben von der CPU:

• TSO (TCP Segmentation Offload): NIC zerlegt große TCP-Segmente in MTU-gerechte Pakete.
• GSO (Generic Segmentation Offload): Kernel-seitiges Software-Fallback.
• RSS (Receive Side Scaling): Verteilt Pakete auf mehrere CPU-Kerne basierend auf Flows.

# 3. Deep Dive: Driver Development Basics

Was Entwickler wissen müssen.

Ein NIC-Treiber implementiert im Wesentlichen die net_device_ops Struktur.

# Kern-Funktionen:

1. ndo_open: Wird bei ip link set up aufgerufen. Initialisiert DMA und Interrupts.
2. ndo_start_xmit: Die Funktion zum Senden. Nimmt ein sk_buff und übergibt es an die Hardware.
3. ndo_set_rx_mode: Konfiguriert Multicast-Listen und Promiscuous Mode.

# Memory Alignment & Cache Locality

Ein guter Treiber sorgt dafür, dass die Daten so im RAM liegen, dass die CPU sie effizient lesen kann. Fehlausgerichtete Zugriffe kosten wertvolle Taktzyklen.

# 4. Day-2 Operations: Performance Tuning

100GbE ist kein Plug & Play.

# IRQ Affinity

Verteilen Sie die Netzwerklast auf verschiedene CPU-Kerne, um ksoftirqd Bottlenecks zu vermeiden.

# Anzeigen, welche CPU welche IRQs bedient
cat /proc/interrupts | grep eth0

# Manuelles Pinning (Beispiel CPU 0-3)
echo "03" > /proc/irq/123/smp_affinity

# Combined Channels

Nutzen Sie Multi-Queue NICs voll aus:

# Anzahl der Queues/Channels anpassen
ethtool -L eth0 combined 8

# 5. Troubleshooting & “War Stories”

Wenn der Link blinkt, aber nichts durchgeht.

# Top 3 Fehlerbilder

1. Symptom: netdev watchdog: eth0: transmit queue 0 timed out.

   • Ursache: Hardware-Hänger oder Bug im Treiber (meist DMA-Error).
   • Lösung: Firmware-Update oder Kernel-Upgrade. Deaktivieren von TSO kann oft als Workaround helfen.

2. Symptom: Hohe CPU-Last auf Kern 0, andere Kerne schlafen.

   • Ursache: RSS (Receive Side Scaling) nicht aktiv oder falsch konfiguriert.
   • Lösung: ethtool -x eth0 prüfen und Indirection Table korrigieren.

3. Symptom: Paketverlust bei Lastspitzen trotz freiem RAM/CPU.

   • Lösung: Ring-Buffer vergrößern und net.core.netdev_max_backlog erhöhen.

# “War Story”: Der “Micro-Burst” Killer

Wir hatten einen High-Frequency-Trading Cluster, der bei Market-Open Pakete verlor. Monitoring zeigte 5% CPU Last. Die Lösung: Ein eBPF-Skript zeigte, dass die NIC-Buffer innerhalb von Mikrosekunden überliefen (Micro-Bursts). Der Standard-Intervall von Prometheus (15s) sah das nicht. Wir mussten die Ring-Buffer auf das Hardware-Maximum setzen und Interrupt Coalescing (ethtool -C) minimieren, um die Latenz stabil zu halten.

# 6. Monitoring & Alerting

KPIs für die Netzwerkschnittstelle.

# Wichtige Metriken

• rx_dropped / tx_dropped: Harte Hardware-Drops.
• rx_fifo_errors: Hinweis auf Ring-Buffer Überlauf.
• softnet_stat: cat /proc/net/softnet_stat. Die dritte Spalte zeigt, wie oft das Polling-Budget überschritten wurde.

# Alerting (Prometheus)

- alert: HighNetworkDrops
  expr: rate(node_network_receive_drop_total[1m]) > 10
  for: 2m
  labels:
    severity: critical
  annotations:
    description: "Interface {{ $labels.device }} verliert Pakete auf {{ $labels.instance }}."

# 7. Fazit & Empfehlung

Die Wahl der NIC und des Treibers ist das Fundament jeder Cloud-Infrastruktur.

• Empfehlung: Setzen Sie im Datacenter auf Intel (i40e, ice) oder Mellanox (mlx5_core). Diese Treiber sind extrem ausgereift und bieten beste Unterstützung für High-Performance Features.
• Vermeiden: No-Name NICs in Virtualisierungs-Hosts (Proxmox). Ein Bug im Treiber kann das gesamte Dateisystem (via iSCSI/NFS) korrumpieren.

# Anhang: Cheatsheet

# Referenzen

• Linux Foundation: Networking Tutorials
• Kernel Documentation: NAPI
• Intel Wired Ethernet Drivers Documentation