Login
Newsletter
Werbung

Mo, 23. November 2009, 07:59

Software::Netzwerk

Linux-Netzwerkstack parallelisiert Verarbeitung mit »Receive Packet Steering«

Ein Patch eines Google-Mitarbeiters ermöglicht die parallelisierte Verbarbeitung eingehender Netzwerk-Pakete auf mehreren Prozessoren.

Aktuelle Netzwerkadapter sind in der Lage, Datenpakete extrem schnell zu übertragen - bis zu einem Punkt, an dem der Netzwerk-Stack des Betriebssystems zum Flaschenhals wird. Trotz Verbesserungen an der Hardware (Offload) muss der Stack die Arbeit in Zukunft auf mehrere Prozessoren verteilen können.

Das Problem tritt hauptsächlich beim Empfang auf. Ausgehende Pakete werden meist von verschiedenen Prozessen erzeugt, die die Betriebssystemfunktionen des Netzwerk-Stacks aus ihrem eigenen Prozessorkontext heraus aufrufen. Da der Scheduler die Prozesse bereits möglichst effizient verteilt, laufen viele Aktivitäten parallel.

Empfangene Pakete kommen dagegen immer von einer einzigen Quelle, dem Netzwerkadapter und dessen Treiber. Einige Adapter besitzen mehrere Empfangswarteschlangen und Interrupt-Leitungen, versuchen also einen gewissen Grad an Parallelisierung zu erreichen, indem die Interrupt-Routinen gleichzeitig mehrfach gerufen werden. Dies gilt jedoch vor allem bei günstigeren Adaptern nicht. Diese bieten aber ebenfalls Geschwindigkeiten jenseits von Fast Ethernet, und Käufer solcher Hardware verlangen ebenfalls die bestmögliche Leistung.

Tom Herbert, Mitarbeiter bei Google, hat nun einen als »Revceive Packet Steering« bezeichneten Patch eingereicht, der die Pakete direkt nach dem Empfang verteilt. Hierzu wird aus relevanten Protokolldaten (derzeit IP-Adresse und Port) ein Hash errechnet und daraus die zu verwendende CPU bestimmt (»Steering«). Da die Daten eindeutig für eine Verbindung sind, landen Pakete für eine bestimmte Verbindung immer bei der gleichen CPU.

Der Ansatz parallelisiert zwar die Verarbeitung, bringt aber ein Detail-Problem mit sich: Die verteilende CPU und die verarbeitende CPU sind nicht notwendigerweise identisch, die Daten aus dem Paket-Header müssen also mehrfach in die CPU-Caches eingelesen werden, was den Gewinn wieder schmälert. Allerdings stellte sich heraus, dass einige Netzwerkadapter Hashes für eingehende Pakete bereits selbst berechnen können. Der Treiber übergibt diese dann direkt an den Steering-Code und macht weitere Berechnungen überflüssig.

Ersten Benchmarks zufolge konnte der Durchsatz auf einigen Testsystemen mit 8 und 16 Kernen im Mittel um das Dreifache gesteigert werden.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung