Introduction to time synchronization

In der ersten Session des Tages erklärt Maciek Machnikowski die präzise Zeitsynchronisation mehrerer Systeme über eine Netzwerkverbindung mittels PTP. Das "Precision Time Protocol", oder eben kurz PTP ist in IEEE1588 standardisiert und ermöglicht die eine konfigurationsfreie Synchronisation mehrerer Systeme über Netzwerk im Nanosekundenbereich.

Nach einer Einführung in die Motivation führte Maciek kurz in die verschiedenen Komponenten ein, die in einem Linux-System für die präzise Erfassung von Zeitpunkten zuständig sind (die sog. PTP Hardware Clock, oder kurz PHC), sowie die verschiedenen Pfade, über die im Kernel die für den PTP-Dämon notwendigen Informationen bis in den Userspace transportiert werden.

Einen größeren Teil seines Talks widmet Maciek praktischen Beispielen und Tools aus der ptp4l-Suite, die verwendet werden:

• ptp4l, der Haupt-Dämon, der die Synchronisation von Leader und Follower- Clock (für die älteren unter uns: Grandmaster und Slave) sowie die Abhandlung des Best Master Clock Algorithm BMCA implementiert
• ts2phc, mit dem Time Events, etwa die PHC auf Pulse per Second (PPS) Events aus einer präzisen Uhr (z.B. einem GNSS-Empfänger) in die PTP Hardwareclock synchronisiert werden. ts2phc unterstützt zudem das Parsen von NMEA-Strings, die von GNSS-Empfängern über UART verschickt werden und die Time of Day enthalten.
• phc2sys, um die Systemzeit auf die PTP Hardware Clock zu synchronisieren
• pmc um Debugging Informationen aus den verschiedenen Komponenten auszulesen
• timemaster zur Synchronisation von PTP und NTP
• phc_ctl zum Debugging der PTP Hardware Clock

Nach diesem sehr praxisnahen Teil geht Maciek kurz auf die Unterschiede der verschiedenen Profiles von PTP ein, die in ptp4l unterstützt werden. Er erläutert, dass alle praxisrelevanten Profile in ptp4l unterstützt werden, dass aber einige wenige Features gewissen Einschränkungen unterliegen.

Zum Abschluss seines Talks geht Maciek am Beispiel eines einfachen Setups noch kurz auf die Einschränkungen und häufige Schwierigkeiten bei Aufbau eines PTP- Setups ein und gibt einen kurzen Ausblick auf das bevorstehende Release von ptp4l 4.0.

Nach der Mittagspause mit üppigem Lunchpaket stehen Talks auf dem Programm, die für Embedded-Anwendungen nur von eingeschränkter Bedeutung sind, dennoch aber einen guten Überblick über die Vielfalt der Anforderungen im Network-Subsystem des Kernels geben.

P4TC - Your Network Datapath Will Be P4 Scripted

In diesem Workshop erläuterte Jamal Hadi Salim die Grundlagen von P4 und die die Integration von P4 in den Linux Kernel als P4TC. P4 steht für das "Programming Protocol-independent Packet Processors" Ökosystem, einer Programmiersprache für Packet Forwarding Planes in Netzwerkgeräten, also einer Programmiersprache, mit der beschrieben werden kann, wie Netzwerkpakete direkt in Hardware an ihr Ziel weitergeleitet werden können, ohne dabei CPU-Last zu erzeugen.

Während P4 schon seit einiger Zeit existiert und sich auch als Industriestandard für die Beschreibung der Packet Forwarding Plane herausgestellt hat, ist bislang kein direkter Support dafür im Kernel verfügbar. Mit P4TC soll nun der Kernel um die Möglichkeit erweitert werden -analog zu BPF- externe P4-Skripte nachzuladen. Diese werden in Kombination mit einer Beschreibung der Hardware-Capabilities dann entsprechend so kompiliert, dass möglichst viele Aufgaben in Hardware, typischerweise Smart NICs, Neural Accelerators oder Mesh-Processors, ausgeführt werden, während der verbleibende Teil der Aufgaben transparent in Software übernommen wird.

Eine weitere Motivation für die Initiatoren des Projekts bei Intel war, dass mit P4TC Traffic Control Features implementiert werden können, ohne dafür Kernelmodules kompilieren zu müssen, was im Datacenter-Umfeld aus verschiedenen, teils regulatorischen, teils organisatorischen Gründen bisher gewisse Hürden bedeutet habe.

Weiter würde man sich so das aufwändige Mainlining des Traffic Control Offloading ersparen, was jedoch in der anschließenden Diskussion auf ein sehr gemischtes Echo stieß. Auch aus den Reihen des FRR zeigte sich hier noch Diskussionsbedarf, da für eine effiziente Implementierung für häufig verwendete Routen das Hardware-Offloading verwendet werden sollte, während für seltener verwendete Routen oft kein Platz in den beschränkten Ressourcen der Hardware vorhanden ist. Um die vorhandenen Ressourcen optimal auszunutzen wäre dafür ein Kommunikationskanal zwischen dem Routing-Daemon im Userspace und P4TC nötig. Es zeichnet sich ab, dass an dieser Stelle noch Erweiterungen des Offload-Flags in switchdev erforderlich werden.

RDMA programming tutorial

Im letzten Talk des Tages wurde von Roland Dreier anhand von Beispielen die Grundlagen der Remote DMA und die Programmierung von Anwendungen gegen dieses Framework erläutert.

RDMA ist ein primär aus der Big Data- und Datacenter-Welt stammendes Feature, das schon seit etlichen Jahren das Übertragen von Speicherinhalten über das Netzwerk ermöglicht, ohne dass dabei die CPUs des angesprochenen Speichers explizit Code ausführen müssen. Es wird also über das Netzwerk remote auf RAM zugegriffen, ähnlich eines lokalen DMA-Zugriffes.

Nach einer Einführung über die verschiedenen Ausprägungen von Asynchronous Queues gab Roland einen Überblick über die Eingliederung in die verschiedenen Subsysteme des Kernels und die verwendeten Abstraktionen.

Da verschiedene Implementierungen in Layer 2 und Layer 3 existieren, ist die Verwendung von RDMA nicht mehr auf die wohl populärste Implementierung Infiniband beschränkt, mit rxe steht im Kernel eine Soft-roCE-Implementierung zur Verfügung, die über gewöhnliches Ethernet verwendet werden kann.

Nach einem kurzen Überblick über die Userspace Libraries librdmacm zum Verbindungsaufbau und libibverbs für die eigentlichen Requests und Datapath Operations zeigte Roland anhand einiger Code Snippets, wie eine Applikation über RDMA Speicher mit einem lokalen Prozess oder einem entfernten Device austauschen kann.

Für Details empfiehlt sich, die Beispiele aus dem Repository RDMA Core zu analysieren.

XDP Workshop

Der zweite Tag der NetDev 0x16 begann mit einem Workshop zu XDP. Der Express Data Path ist eine Möglichkeit, mittels eBPF (extended Berkeley Packet Filter) für Netzwerkpakete bereits sehr früh nach dem Empfangsinterrupt zu entscheiden, ob das Paket verworfen, in den Netzwerkstack weitergegeben, oder zurück an eine Netzwerkkarte weiter geschickt werden soll.

Zudem können Pakete an einem großen Teil des Netzwerkstacks vorbei direkt in den Userspace geschleust werden, um für spezielle Anwendungen mit hohem Durchsatz die Performance zu steigern.

Im Workshop wurden die aktuellsten Änderungen Entwicklungen in diesem Umfeld vorgestellt, etwa Dynamic Pointers von Joanne Kong, die damit für Meta eine Möglichkeit implementiert hat, um auch Daten interagieren zu können, deren Größe zur Compilezeit eines BPF-Programms noch nicht bekannt ist.

Auch zu den anderen Themen, wie die XDP_Hints zur besseren Annotation von XDP-Puffern mit Metadaten oder die Arbeit von Zhan Xue (Intel), um mit XDP_REDIRECT zu Pakete direkt in Hardwarebeschleuniger, etwa für Kryptographie, umleiten zu können, wurde lebhaft diskutiert.

Aus der Sicht eines Embedded-Entwicklers ist diese Technologie sehr spannend, insbesondere Anwendungen wie die Dekompression von Videostreams über Netzwerkverbindungen in entsprechenden Hardwarebeschleunigern drängt sich förmlich auf.

Ob die Infrastruktur hier alle erforderlichen Anbindungspunkte zur Verfügung stellt, wird zu beobachten bleiben, aber es ist sehr spannend hier zu überlegen, welche weitere Anwendungen die hier vorgestellten Entwicklungen ermöglichen könnten.

Auch hier zeigt sich wieder die Stärke der Entwicklung in einer lebendigen Community, bei der Experten aus verschiedenen Hintergründen zusammen kommen, und gemeinsam Design und Entwicklung der Subsysteme vorantreiben.

In den Kaffeepausen spinnen sich diese Überlegungen im gemeinsamen Gespräch fort. Dies ist eine wertvolle Ergänzung zu den sonst üblichen Diskussionen auf den Mailing Lists und ermöglicht einen direkteren und schnelleren Austausch von Meinungen, Erfahrungen und Ideen.

So hatte ich heute beispielsweise die seltene Möglichkeit, mit einigen Entwicklern, die wie ich an TSN (Time Sensitive Networking) arbeiten, über die aktuellen Entwicklungen zu FRER (Frame Replication and Duplicate Elimination for Reliability) und Implementierungsvarianten aktueller RFCs (Request for Comments) aus den DetNet (Deterministic Networking) Workinggroups der IETF zur redundanten Datenübertragung von Echtzeitdaten in Netzwerken zu diskutieren.

FRR Workshop

In der zweiten Session des Tages zeigten die Entwickler von FRRouting die aktuellen Entwicklungen und Verbesserungen an der Free Routing Protocol Suite. Mobashshera Rasool von VMWare präsentierte die Designentscheidung und den Support für MLD (Multicast Listener Discovery) und PIM (Protocol Independent Multicast), die nun für IPv4 und IPv6 über den pimd daemon in FRR verfügbar sind, nachdem der dafür benötigte technische Unterbau bereits seit Kernelversion 4.19 in mainline ist.

Dank der Arbeit von Dr. Olivier Dugeon von Orange Innovation Network ist in FRR nun auch Segment Routing verfügbar. Dabei kann an ein Netzwerkpaket eine Liste mit Segment Identifiers angehängt werden, die den Pfad des Pakets durch das Netzwerk bestimmen. Im Gegensatz zu regulären Routing-Algorithmen kann so eine Mehrzahl ringfreier Pfade durch ein Netz aufgespannt werden, um beispielsweise redundante Pakete über mehrere Routen zu schicken und so dem Ausfall von Links in Echtzeitanwendungen zu begegnen. Diese Technologie wird bereits jetzt in verschiedenen kommerziellen Routern implementiert, diese sind voll kompatibel zur Implementierung in FRR.

Auch für Embedded ergeben sich im Zusammenspiel mit DetNet viele interessante Praxisanwendungen, beispielsweise das explizite Aufspannen redundanter Echtzeitlinks in einem Netz. Sicherlich wird es nicht lange dauern, bis auch für diese Anwendungen Segment Routing in freier Wildbahn gesichtet wird.

Abschließend gab Donald Sharp einen Überblick über die aktuellen Entwicklungen und einen Ausblick auf die Features im nächsten FRR-Release. Neben vielen inkrementellen Verbesserungen, Bugfixes und einer kontinuierlich gesteigerten Codequalität wurden dabei besonders die Bemühungen von Donatas Abraitas erwähnt, die kontinuierlichen Änderungen im BGP (Border Gateway Protocol) nachzupflegen.

Network view of embedded specific challenges for non-embedded network developers

Nach dem Mittagessen hielt Oleksij Rempel von Pengutronix gleich zwei Talks. In "Network view of embedded specific challenges for non-embedded network developers" gab Oleksij einen Überblick über verschiedene Praxisbeispiele aus dem Arbeitsalltag eines Kernelhackers mit Fokus auf Embedded Hardware.

Oleksij führte dabei zuerst die Unterschiede zwischen Embedded und nicht- Embedded-Anwendungen aus. Obwohl die Grenzen zunehmend verschwimmen, gibt es im Embedded-Umfeld einige speziellere Einschränkungen wie beispielsweise Power Constraints oder maximale Initialisierungszeiten von Verbindungen. Analog zur Aufweichung der Grenze zwischen embedded Devices und nicht-embedded devices werden auch im Embedded-Umfeld Feld- und Onboard-Busse wie CAN zunehmend durch Ethernet ersetzt. Dennoch zeigt sich, dass für embedded Usecases und Anforderungen oft erheblich von herkömmlichen IT-Usecases abweichen. Als Beispiel nennt Oleksij die fq_codel queuing discipline, die für TCP gut einsetzbar ist, sich beim Einsatz für CAN-Busse aber als sehr problematisch herausstellt. Da Linux zunehmend auch in embedded-Anwendungen eingesetzt wird, sollten Entwickler auch für die besonderen Anforderungen dieses Umfelds sensibilisiert werden. Als weiteres Beispiel führt Oleksij die verschiedenen Feldbusse im Automotive-Umfeld auf, von denen nur CAN mainline ist, die aber zunehmend durch Ethernet ersetzt werden. Aufgrund der abweichenden Anforderungen bilden sich jedoch auch hier vom Default abweichende Substandards, etwa Base-T1 über Twisted Pair, aus. Dies ist vor allem der Optimierung und Reduktion von Kosten, Performance und Energieverbrauch geschuldet. Weitere Anforderungen ergeben sich aus den Timing Requirements der Anwendungen, zum Beispiel kann für Automotive-Anwendungen keine Autonegotiation verwendet werden, da dieser Vorgang zu lange dauert, ein Link muss binnen weniger Millisekunden aktiviert werden. Hierfür müssen bestehende Konfigurationsinterfaces erweitert werden.

Als weiteres Beispiel nennt Oleksij Explosionsgeschützte Bereiche. In diesen ist die Energiemenge in einem System auf eine bestimmte Menge begrenzt, was auch Netzwerkverbindungen vor besondere Herausforderungen stellt. Mit 10Base-T1L kann die Amplitude des Links auf 1.0Vpp begrenzt werden, was den Einsatz in einer explosionsgefährdeten Umgebung erlaubt. Support für diesen Standard wurden aktuell im Kernel hinzugefügt, erfordern aber Änderungen, um beispielsweise Verbindungen mit Gegenstellen zu unterbinden, die 2.4Vpp-Links in der Autonegotiation annoncieren.

Ein weiteres Beispiel ist eine spezielle Implementierungsvariante für Linkredundanz, bei der mehrerer Phys an eine MAC angebunden werden. Hierfür existiert keine passende Abstraktion im Kernel, es findet daher aktuell auf der Mailingliste eine Diskussion diesbezüglich statt. Eine weitere Variante dieser Anwendung ist die Anbindung mehrerer Phys an einem MAC, um in Layer 1 verschiedene Standards unterstützen zu können.

Ähnliche Herausforderungen ergeben sich aus den Kommunikationsketten von MDIO-Links für SFP-Cages.

Anhand dieser Beispiele zeigt Oleksij, welche Auswirkungen die Anforderungen im Kernel haben. Teils können für die Umsetzung der Anforderungen bereits vorhandene Schnittstellen erweitert werden, jedoch ist teils auch erforderlich, komplett neue Schnittstellen im Kernel zu schaffen.

Implementing cooperative link diagnostics by using dusty corners of IEEE 802.3 specification

In seinem direkt darauf folgenden zweiten Talk erklärt Oleksij, wie Link Diagnostics in Ethernet implementiert werden kann.

Oft wird Link Diagnostics, also die Erkennung von Fehlern in den physical links, etwa defekte Kabel, Stecker, usw., von Hardwareherstellern nicht als wichtiges Feature angesehen. Die Beiträge hierzu im Kernel stammen daher meist von individual contributors, oftmals Hobbyisten. Gerade im Feld ist jedoch genau dieses Feature in vielen Anwendungen dringend erforderlich. Oleksij führt aus, dass sehr viele verschiedene Fehlermodi existieren (Kurzschlüsse, Erdschlüsse, Kabelbrüche, etc der verschiedenen Kabeladerpaare).

Mit dem Kommando

ethtool -t eth0

kann ein Selbsttest von MAC und PHY durchgeführt werden, womit in einem aktuellen Kernel der Phy in den Loopback-Modus geschaltet wird. Dadurch können Fehler in der Strecke zwischen MAC und PHY erkannt werden.

Mit dem Kommando

ethtool --cable-test eth0

kann ein grundlegender Kabeltest durchgeführt werden.

Über das Kommando

ethtool eth0 | grep -i sqi

kann bestimmt werden, ob der Phy zu eth0 die Bestimmung des Signal Quality Index (SQI) unterstützt.

Der Selftest kann bezüglich seiner Funktionalität noch erweitert werden, was allerdings eine Kommunikationsmöglichkeit zum Linkpartner erfordert.

Weiter funktionieren cable tests meistens nur gut, wenn die Gegenstelle ausgeschaltet ist, da ansonsten die Fast Link Pulses (FLPs) der Autonegotiation das Messergebnis verfälschen.

Um zu zeigen, wie diesem Problem abgeholfen werden kann, erklärt Oleksij zunächst, wie ein Kabeltest mittels Time Domain Reflectometry (TDR) funktioniert. Dazu wird vom Phy ein Pulse auf ein Kabel angelegt, dessen Ausbreitung und Reflexion der Phy ausmisst. Anhand des Messegebnisses kann zwischen Kabelbruch, Kurz- oder Erdschluss und korrekt funktionierenden Kabeln unterschieden werden. Die Abtastrate des Phys bestimmt dabei die Präzision der Messung, üblich ist eine Messgenauigkeit von 80 cm.

Anschließend erklärt Oleksij, dass für die Autonegotiation ebenfalls Pulse auf den Link angelegt werden, die die Messergebnise der TDR verfälschen können.

Oleksij schlägt vor, das Autonegotiation-Flag "remote fault" in den Fast Link Pulses zu verwenden, das eine Sendepause in der Autonegotiation erzwingt. In der entstehenden Stille könnte eine Messung mit TDR vorgenommen werden. Da die Autonegotiation Pulse bei einer niedrigeren Frequenz arbeiten als der reguläre Ethernet Link, ist die Wahrscheinlichkeit groß, dass diese auch noch bei einem gewissen Beschädigungsgrad des Links bei der Gegenstelle ankommen. Im Link Code Word der FLP der Autonegotiation könnten Bit 13("RF) und Bit 15 ("NP") hierfür verwendet werden. Das RF-Flag (Remote Fault) indiziert dabei einen allgemeinen Fehler, das NP-Flag ("Next Page") dient dazu, noch weitere Pages zu ergänzen, um präzisere Anforderungen zu kommunizieren.

Hierfür müsste eine vendor specific Message verwendet werden.

Oleksij hat einen ersten Patch hierfür auf die Netdev Mailinglist geschickt und lädt zum allgemeinen Review und zur Diskussion ein.

"We've got realtime networking at home" - Why many systems are moving to TSN so slowly

Zum Abschluss der Vorträge habe ich noch meinen eigenen Talk gehalten. In diesem Talk habe ich die grundlegenden Anforderungen an Echtzeitnetzwerke zusammengefasst: Zeitsynchronisation, Maximale Übertragungsdauern und Quality of Service, also die garantierte Übertragung von priorisierten Inhalten. Ich habe dann Implementierungsversuche mit herkömmlichem Ethernet der Implementierung mittels TSN gegenübergestellt und erläutert, mit welchen Migrationsstrategien man im Feld befindliche Systeme systematisch upgraden kann, bis ein System voll TSN-fähig ist.

Zum Abschluss meines Talks habe ich die Entwickler motiviert, mehr Dokumentation, Beispiele und Tests zu ergänzen, um Systemingenieure und Endanwender besser in die Lage zu versetzten, diese neuen Technologien auch einzusetzen.

Nach Ende der Talks ergab sich beim Social Event noch die Möglichkeit, sich mit Maintainern und Entwicklern auszutauschen und die Menschen hinter den Postings auf der Mailinglist kennenzulernen.

It's Time to Replace TCP in the Datacenter

In seiner Keynote stellt John Ousterhout vor, warum TCP sich zwar verbreitet hat, aber für Datacenter-Anwendungen eigentlich relativ ungeeignet ist.

Er zeigt ausführlich, dass die grundlegenden Eigenschaften des Protokolls den fundamentalen Anforderungen an diese relativ spezielle Workload diametral gegenüberstehen, weshalb es nicht möglich ist, TCP nennenswert für diese Anwendung zu verbessern oder zu erweitern.

Aus den Ergebnissen seiner Forschung hat seine Arbeitsgruppe das HOMA-Protokoll entwickelt, dessen Vorteile ausführlich diskutiert und mit Messergebnissen demonstriert wurden. Obwohl bereits für die aktuelle Softwareimplementierung gegenüber TCP für typische Datacenter-Workloads Performanceverbesserungen um mehr als eine Größenordnung erreicht werden können, wird zum Erreichen der in Line-Rate, also der theoretisch verfügbaren Bandbreite, auch für HOMA ein Hardwareoffloading in den Netzwerkkarten nötig werden.

HomaLS: Tunneling messages through secure segments

Im Folgetalk zeigt Tianyi Gao, wie HOMA-Segmente analog zu DCTCP-Segmenten verschlüsselt werden können. Er präsentiert einen Prototyp seiner Implementierung für Hardwareoffloading auf Mellanox CX16 und stellt erste Messungen vor, die bereits jetzt schon 20% Verbesserung gegenüber den üblichen DCTCP Implementierungen erreichen.

dcPIM: Low–latency, High–throughput, Receiver–driven Transport Protocol

Im darauf folgenden Talk wurde ein erster Ausblick auf die Herausforderungen für Link Speeds >200Gbps, sog. Terabit-Links, in Datacenters gegeben. Anhand von Messungen wurde verdeutlicht, dass die Hauptquelle von Latenzen dabei die Residence Time in Switches ist. Bei Terabit-Ethernet benötigen kleine Netzwerkpakete nur wenige Mikrosekunden um versendet zu werden, weshalb die Switchqueues erheblich beim Datendurchsatz ins Kontor schlagen. Da die Architektur von Datacenters und die Datenflüsse dort selbst wie die Architektur eines Switches aussehen, schlagen Qizhe Cai und Rachit Agarwal daher vor, die in Switches zur Lösung dieses Problems bereits verwendete Methode des Parallel Iterative Matching zur Variante Datacenter Parallel Iterative Matching (dcPIM) weiterzuentwickeln, die in einem iterativen Prozess eine optimale Zuordnung von Datenströmen auf Links und Ressourcen vornimmt.

Da das mathematische Modell dahinter gut erforscht ist, schnell konvergiert und zudem keine Änderungen an den verwendeten Protokollen oder APIs erforderlich sind, gehen die Autoren davon aus, dass sich dieser Ansatz reibungslos deployen lässt.

Nach diesem eher theorielastigen Vormittag mit vielen Anwendungsfällen, die sehr weit von den üblichen Embedded-Usecases meiner täglichen Arbeit entfernt sind, ergab sich beim Mittagessen einige interessante Kontakte und Diskussionen, unter anderem mit Entwicklern aus dem WiFi-Stack, die am Ende im gemeinsamen Review eines 5 Jahre alten Proof of Concept Codes endete, der überraschend gut auf die aktuellen Multilink-Erweiterungen in den aktuellen Iterationen der Wifi-Standards anwendbar ist.

bring network and time together using Linux tracing

Nach der Mittagspause zeigte Alexander Aring in seinem Talk, wie über mehrere physische oder virtuelle Maschinen eines Rechnerclusters verteilt mit trace-cmd zeitsynchronisiert Traces aufgezeichnet, ins slog2sdk-Format umgewandelt und mittels jumpshot analysiert werden können, um das DLM lock protocol in einer GANTT-ähnlichen Darstellung leichter untersuchen zu können.

In–Kernel Fast Path Performance For Containers Running Telecom Workload

In ihrem Talk zeigten Nishanth Shyamkumar, Piotr Raczynski, Dave Cremins, Michal Kubiak und Ashok Sunder Rajan, wie sie ein klassisches Setup einer 4G Basisstation von Proprietärer Software auf proprietärer Hardware mit proprietären Betriebssystemen (was in der Telekommunikationsindustrie über lange Jahre so üblich war) auf Standard-Server umstellen konnten, indem sie die Softwarekomponenten für mehrere Basisstationen in Docker- Containern laufen ließen.

Die Hauptherausforderung dabei stellte die effiziente Anbindung der einzelnen Container an die Netzwerkhardware des Hostsystems dar, was jedoch mit SRIOV und AF_XDP zero copy gut gelöst werden konnte.

Dies ermöglicht, die Infrastruktur auf erheblich günstigerer Hardware zu betreiben und dadurch beim Ausrollen und im Betrieb von Mobilfunkinfrastruktur erheblich Kosten zu sparen.

Hier lassen sich wohl auch erste Lehren für die effiziente Anbindung von Hardware in Containern ziehen, die auch für Embedded-Anwendungen relevant werden könnten, sodass dieser Talk nicht nur wegen der 20-fachen Performancesteigerung im Vergleich zur initialen Trivialimplementierung sehr spannend war.

Linux kernel networking acceleration using P4–OVS on IPU

Sandeep Nagapattinam, Nupur Uttarwar, Venkata Suresh Kumar und Namrata Limaye zeigten in ihrem Talk, wie sich mit P4 unter Zuhilfenahme von einer Infrastructure Processing Unit (IPU) erhebliche Performancezugewinne beim Layer2 Forwarding, Routing und VxLAN erreichen lassen.

Vermutlich werden sich die bei unseren Kunden üblichen Anforderungen nie in dem hier avisierten Durchsatz- und Performancebereich bewegen, dennoch ist es spannend zu beobachten, wie hier mit neuen Ideen dem Ende von Moore's Law ein Schnippchen geschlagen werden soll.

High Performance Programmable Parsers

Der letzte Talk des Tages von Tom A. Herbert wiederum zeigte einen interessanten Lösungsansatz für ein Problem, das auch im embedded-Umfeld durchaus häufig zu beobachten ist. Recht häufig müssen Netzwerkpakete geparst, also die einzelnen Felder in einem Datenframe analysiert werden, um aus einem Paket alle erforderlichen Informationen zu extrahieren.

Die dafür nötige Software, ein sogenannter Parser, wird konventionell meistens händisch implementiert, was ein sehr mühsames und dadurch langwieriges Verfahren ist.

Tom stellt in seinem Talk vor, wie mit der CPL, der Common Parser Language, in einem json File deklarativ ein Protokoll beschrieben werden kann. Aus dieser Beschreibung kann dann ein Parser erzeugt werden, der über die kparser Infrastruktur später im Kernel zum Parsen von Netzwerkpaketen verwendet werden kann. In Kombination mit XDP und eBPF kann so ein eintreffendes Paket einfach und effizient untersucht, und an den Netzwerkstack oder über den Express Data Path an den betreffenden Empfänger weitergeleitet werden.

Zum Abschluss zeigt Tom, wie sich Hardwareoffloading über P4 auch in dieser Infrastruktur einbinden lässt, jedoch sind dafür noch einige Herausforderungen zu meistern. Ich bin gespannt, ob wir schon bald auch im ein oder anderen Projekt von dieser Technologie Gebrauch machen können, und dadurch für unseren Kunden deutlich Entwicklungszeit einsparen können.

When regular expressions meet XDP

Im ersten Talk des Tages erklärte Ivan Koveshnikov, wie er bei GCore DDoS-Protection für Game Traffic mit regex im XDP implementiert. Da für diese Anwendung vor allem kleine UDP-Pakete zu parsen sind, die zudem sehr regelmäßige Strukturen aufweisen, bietet sich ein Parsing mit regex an.

Zum regex matching setzen sie die BSD-Lizensierte Engine Hyperscan ein, die oft auch für deep packet inspection verwendet wird und bereits für das hochperformante scannen von Netzwerkpaketen optimiert ist. Für eine effiziente Implementierung von Regex in eBPF-Programmen sind aufgrund der Größe der Regex und wegen Limitierungen von eBPF bezüglich der Verfügbarkeit von Vector Instructions (XDP läuft in einem SoftIRQ-Kontext, wo die FPU- Instructions nicht verfügbar sind), verschiedene Anpassungen am Kernel notwendig. Ivan erklärt, dass sie daher das Speichern und wiederherstellen des FPU state in SoftIRQs implementiert haben, was allerdings erfordert, Interrupts und Preemptions auszuschalten, sobald FPU load/store instructions verwendet werden. Dadurch sind auch die Vector instructions verfügbar und der regex parser kann sehr effizient in einem eBPF Helper ausgeführt werden.

Zur Konfiguration können entweder eBPF maps verwendet werden, die zwar bereits Synchronisation mitbringen, aber eine fixe Größe der Einträge erzwingen und applikationsspezifisch sind, oder Einträge in einem configfs.

Wegen der größeren Flexibilität eines configFS haben sie sich für diese Implementierungsvariante entschieden.

Anschließend präsentierte Ivan einige Benchmarks, die sie im Fall der XDP_DROP (also für verworfene Pakete) und XDP_TX (also für weitergeleitete Pakete) erreichen konnten.

Für Pakete größer als einige Hundert Bytes Payload kann ihre Lösung invalide Pakete "at line rate" verwerfen, also so schnell wie das angebundene Netzwerk, die Weiterleitung der für gut befundenen Pakete ist etwas aufwändiger. Hier sieht Ivan noch Verbesserungspotential, obwohl das neue System bereits schon jetzt erfolgreich produktiv eingesetzt werden kann.

Am Ende seines Talks ruft Ivan die Hersteller von Netzwerkkarten dazu auf, die Interaktion von XDP mit Hardwareoffloading zu verbessern, da in den Treibern oft nur DPDK (Dataplane Development Kit)-Support, aber keine oder nur unzureichende Unterstützung für XDP vorgesehen wurde. Besonders die XDP Hints sieht er hier als einen möglichen Weg, diese Situation zu verbessern.

Ivan stellt seinen Code auf Github zur Verfügung und motiviert die Zuhörer, ihre eigenen Messungen durchzuführen.

Towards µs Tail Latency and Terabit Ethernet: Disaggregating the Host Network Stack

Im anschließenden Talk wurde die Forschungsarbeit von Qizhe Cai, Midhul Vuppalapati, Jaehyun Hwang, Christos Kozyrakis, und Rachit Agarwal vorgestellt. Sie stellten nach einem Upgrade ihres Netzwerklabors von 10GBit auf agreggierte 100GBit Links fest, dass sich aus der grundlegenden Struktur des Netzwerkstacks Beschränkungen der Performance für schnelle Links ergeben.

Die zugrundeliegende Architektur mit einem Pipelinekonzept ist nur schwer zu optimieren, da die Anforderungen für langlebige Datenflüsse und kurze Datenbursts Änderungen an sehr vielen verschiedenen Stellen erfordern, die viele Querabhängigkeiten haben.

Sie schlagen daher vor, die grundlegende Architektur ähnlich dem Linux Storage Subsystem mit loosely coupled layers zu implementieren.

In einem ersten Prototyp, den sie auf Github bereits veröffentlicht haben, konnten sie bereits sehr beeindruckende Performancezuwächse erreichen.

The Anatomy of Networking in High Frequency Trading

PJ Waskiewicz stellte anschließend die Besonderheiten der Anforderungen an die Netzwerkinfrastruktur für High-Speed-Trading vor. Diese Welt liegt hinter einem Schleier aus Geschäftsgeheimnissen verborgen, dennoch konnte PJ strukturiert die Grundzüge dieser sehr ungewöhnlichen Welt vermitteln. Während die Anbindung an die Börsenplätze noch mit konventionellen 10Gbps Ethernet-Links erfolgt, werden die Entscheidungen über die zu tätigenden Käufe und Verkäufe in High Performance Computing Clustern getroffen, in welchen die entsprechenden Inferenzmodelle teils in Software, teils in Hardware ausgeführt werden.

In beiden Fällen sind hohe Performance, niedrige Latenz, besonders aber deterministische und vorhersagbare Latenz der Netzwerkkommunikation absolut unabdingbar, um Wartezeiten zu vermeiden. Diese würden letztlich zu schlechteren Ergebnissen in den Finanztransaktionen führen.

Auf Seite des Betriebssystems zeigte PJ, wie die auch bei vielen Embeddedanwendungen durchgeführten Optimierungen, etwa der Einsatz von RT_PREEMPT, CPU Isolation, Interrupt Pinning, Wahl geeigneter CPU Power States usw. nicht nur die Average Case und Median, sondern auch die Worst Case Performance erheblich verbessern. Eine erstaunliche Erkenntnis für diesen speziellen Anwendungszweck ist der Verlust von Determinismus durch die SoftIRQs im Empfangspfad, was in dieser Anwendung schlicht durch permanentes Polling umgangen wird.

Im Bereich der High Performance Computing Cluster herrscht auch heute noch RDMA als Kommunikationsmedium der Wahl, oft über Infiniband, vor. Hier erhofft PJ sich insbesondere von io_uring und XDP weitere Performancesteigerungen. Es wird mittlerweile immer schwieriger, erfahrene Entwickler und Administratoren für diese Technologien zu finden oder neu auszubilden, zudem ist Infiniband als Nischenprodukt extrem teuer. PJ wirft daher die Frage auf, in wieweit RoCE oder iWARP die genannten Anforderungen erfüllen können, besonders bei converged Networks, also im Mischbetrieb mit konventionellem Ethernettraffic.

Auch neue Kandidaten wie HOMA werden in der Industrie mit großem Interesse untersucht, jedoch muss weiter eine so niedrige Latenz wie möglich und ein minimaler Jitter gewährleistet sein.

Merging the Networking Worlds

Nach diesem so interessanten wie speziellen Talk diskutieren David Ahem und Shrijeet Mukherjee in ihrem Talk über eine Kombination von Berkeley Sockets, insbesondere für den Zugriff auf die Control PLane, mit RDMA bzw. einer Verbs-basierten Kommunikation in der Data Plane. Sie argumentieren, dass damit die Vorteile aus diesen beiden Welten für hochperformante Datenübertragung im Netzwerk vereint werden könnten.

Nach den Verschiedenen Talks, in denen die Ablösung der "alten Welt" durch eine bessere Zukunft postuliert wurde, ist dieser Ansatz, gut funktionierende und bekannte Infrastruktur zu behalten und das beste aus beiden Welten zu vereinigen, - zumindest aus Ansatz eines altgedienten Programmierers - eine sehr angenehme Aussicht. Evolution statt Revolution.

Fixing TCP slow start for slow fat links

Maryam Ataei Kachooei präsentiert die Ergebnisse ihrer Forschungsarbeit zur Optimierung von TCP congestion control für die Kommunikation über geostationäre und Low Orbit Satelliten.

Die Algorithmen, mit denen TCP die verwendeten Packetgrößen und Datenraten an die verfügbaren Links anpasst, skalieren per default nicht gut für diese Art von Link, was wohl vor allem an den vergleichsweise langen Paket-Roundtriptimes über den Satelliten-Link liegt. Mit ihrer Forschungsarbeit konnte Maryam jedoch Parametersätze finden, die auch mit den bereits implementierten Algorithmen eine deutlich bessere Performance erreichen.

The TSN building blocks in Linux

Anschließend gab Ferenc Fejes vom Ericsson Research Traffic Lab nach einer kurzen Einführung in die verschiedenen Standards zum Thema Time Sensitive Networking eine ausführliche Übersicht über den aktuellen Stand der Implementierung der einzelnen Komponenten in Linux.

Er zeigte dabei nicht nur die verwendeten Kernelkomponenten, sondern stellte auch die dazugehörigen Userspace-Interfaces zur Konfiguration sowie Möglichkeiten zum Hardwareoffloading vor.

Neben eigenen Messungen für einige der Komponenten zeigte er Beispiele für die Konfiguration und diskutierte die noch offenen Themen, beispielsweise die Anbindung der einzelnen Komponenten an Netzwerkkonfigurationsprotokolle über entsprechende Daemons und Services.

Auch sollten seiner Ansicht nach dringend Selbsttests und Verifikationstools implementiert werden, um Anwender bei der Inbetriebnahme zu unterstützen, eine Forderung der ich mich sehr gerne und sehr nachdrücklich anschließe.

Zum Schluss unterstrich Ferenc noch einmal, dass durch die Verfügbarkeit von TSN-fähiger Switchhardware in den Switchdev- und DSA-Frameworks bereits heute die entsprechende Hardware als first class citizens unterstützt werden, und dass auch das Hardwareoffloading bereits jetzt gut in die bestehende Infrastruktur integriert werden kann (und teils sogar bereits integriert ist).

Towards a layer–3 data–center fabric with accelerated Linux E–VPN on the DPU

Im darauf folgenden Talk demonstrierten Roopa Prabhu und Rohith Basavaraj, wie sie in der Data Processing Unit DPU, einem Hardwarebeschleuniger von Nvidia ein Hardwareoffloading von E-VPN implementieren und dabei erstaunliche Performance erreichen konnten.

State of the union in TCP land

Im letzten Talk des Tages fasste Eric Dumazet die Entwicklungen des letzten Jahres im Linux TCP-Stack zusammen. Neben einer Verbesserungen im Bereich der Security handelt es sich dabei primär um Performanceverbesserungen.

Kernel Selftests und Switch Testing

Nach dem offiziellen Teil der Veranstaltung trafen sich noch einige Entwickler vor Ort mit per Videocall zugeschalteten Kollegen aus Hildesheim, um Strategien für In-Kernel-Selftest für Switches und eine Strategie für Hardwaretests von Switches zu diskutieren.

Ein Prototyp aus der diesjährigen Pengutronix Techweek fand dabei regen Anklang, und wir hoffen schon bald mit Integration neuer Exporter in Labgrid den Baustein auch für andere Entwickler in der Community mit Testinfrastruktur unterstützen zu können.

Pushing OpenVPN down the stack: Data Channel Offload (DCO)

In diesem Talk erläutert Antonio Quartulli die aktuellen Optimierungsbestrebungen bei OpenVPN. OpenVPN implementiert klassisch sowohl Control Plane als auch Data Plane für VPN-Verbindungen im Userspace, was zwar große Freiheit in der Implementierung bietet, gegenüber einer Implementierung der Data Plane im Kernel allerdings auch erhebliche Performance-Einbußen bedeutet.

Der zu verschlüsselnde Netzwerktraffic wird dabei bisher von den Anwendungen (z.B. Webbrowser) durch ein tun-Device, also ein Layer3-Tunneldevice, in den Kernel, und wieder zurück in die OpenVPN-Applikation im Userspace geschickt.

Diese verschlüsselt die Daten und schickt diese wieder in den Kernel, der die Daten über den Netzwerkstack aufs Netz und damit an den VPN-Server schickt. Jedes Datenpaket muss daher doppelt durch die Kernel-Userspace-Boundary, was zu erheblichen Performanceeinbußen gegenüber in-Kernel-Implementierungen (wie wireguard, a.d.A.) führt.

Neben der Tatsache, dass die OpenVPN Applikation singlethreaded ist und daher nicht von den mittlerweile oft reichlich verfügbaren Prozessorkernen Gebrauch machen kann, führt das dazu, dass die Performance von OpenVPN mittlerweile deutlich hinter den in Hardware verfügbaren Bandbreiten zurückbleibt. Da die Codebase von OpenVPN bereits etwas in die Jahre gekommen ist, hat Antonio nicht den Userspace-Code optimiert sondern untersucht, wie sich dieses Problem durch ein Offloading der Data Plane in den Kernel weitgehend lösen lässt. Da in der Praxis proprietäre Erweiterungen der Control Plane, also dem Auf- und Abbau sowie Management von Verbindungen gängige Praxis sind ("BYOV" - bring your own VPN), wird die Control Plane weiter im Userspace gehalten, während das Verschlüsseln mittel Kernel Crypto API und das Kapseln der Netzwerkdaten im DCO (Data Channel Offload) implementiert werden. Das DCO ist ein virtual Device Driver, der per Netlink API konfiguriert wird und über Standard- APIs Daten mit dem Userspace austauscht.

Als Besonderheit wird, im Gegensatz zur bisherigen Implementierung, die für den peer-to-multipeer-Modus (Server Modus) eine komplette Routing-Tabelle im Userspace hält, nun auch die Routing Table des Kernels verwendet, die lediglich um die erforderlichen more specific routes erweitert wird.

Ob sich diese Optimierungen mit Wireguard mithalten können, wird zu beobachten bleiben, tragen aber auf jeden Fall dazu bei, die Performance-Lücke zwischen OpenVPN und Wireguard wieder zu verkleinern.

Die von Antonio vorgestellte Lösung ist bereits jetzt voll funktionsfähig, das Data Channel Offload ist auf Github verfügbar. Um sie in OpenVPN2 zu verwenden zu können muss der aktuelle Masterbranch verwendet werden, die Änderungen werden jedoch bald auch in der OpenVPN Version 2.6 releast.

NVMeTCP Offload – Implementation and Performance Gains

Shai Malin und Aurelien Aptel stellen in ihrem Talk Optimierungen an NVMe-TCP vor. NVMe-TCP ist ein Protokoll zur Anbindung von Storage über TCP, Darin wird jede Storage Queue über einen TCP socket angebunden, auf dem Lese- und Schreiboperationen, die entsprechend über einen Command Identifier (CID) gekennzeichnet werden, in eine remote-System getunnelt werden können.

Um eine möglichst hohe Performance zu erreichen, dürfen Server ein Reordering vornehmen, um kleine Requests längeren Zugriffen vorzuziehen. Die Datenintegrität wird über eine Prüfsumme (CRC) gewährleistet.

Nach einer sehr kurzen Einführung in dieses ungewöhnliche Thema erklären Shai und Aurelien, dass in der aktuellen Implementierung, trotz verschiedener Optimierungen, die größte Performancebremse das Kopieren von empfangenen Daten ist. Auch die CRC-Validierung nimmt erheblich Rechenzeit in Anspruch und ist daher ein attraktives Optimierungsziel.

Da die NVMe-TCP PDUs zudem über mehrere TCP Segments verteilt sein können (oder mehrere NVMe-TCP PDUs in einem TCP Segment enthalten können), ist ein trivialer Zero-Copy-Ansatz hier nicht zielführend.

Stattdessen schlagen sie die DDP (Direct Data Placement) Infrastruktur vor. Die Grundidee ist, für Protokolle wie NVMe-TCP, die auf Request-Response-Paaren basieren, dedizierte vorallozierte Buffer zu verwenden.

Da die Daten der NIC bereits per DMA in diese dedizierten Buffer kopierten werden, kann auf diesen mit geringerem Aufwand analysiert werden, ob ein Hardware Offloading möglich ist.

Wird dieser Ansatz mit beispielsweise CRC-Offloading kombiniert, lassen sich für NVMe-TCP Performancegewinne von bis zu 58% bezüglich erreichter Bandbreite bei gleichzeitig um bis zu 20% niedrigerer CPU-Last erreichen.

Als lessons learned empfahlen Shai und Aurelian den Zuhörern, mit perf und flamegraphs sorgfältige Messungen durchzuführen, um Performanceoptimierungen zunächst auf den teuersten Operationen einer kompletten Kette durchzuführen.

In ihrem Fall stellten sie beispielsweise fest, dass die Kontext Switches, die durch die Interrupts bei jedem UMR Event pro PDU ausgelöst wurden, zu erheblichen Performanceeinbußen führten. Durch die Annahme, dass das Offloading opportunistisch sei und man nicht auf completion zu warten habe, konnten sie erhebliche Verbesserungen herbeiführen.

Weiter erklärten sie, dass coalescing von Paketen für das Offloading, also die Ausführung von Offloading-operationen für mehrere Pakete auf einmal, zu erheblichen Performancezugewinnen gegenüber dem Offloading für Einzelpakete führte. Wenn das Offloading für die jeweiligen Einzeloperationen (hier CRC-Berechnung und DDP) getrennt durchgeführt wird, lassen sich Pakete besser poolen, was erneut die Performance steigert.

Um das Offloadings ideal auf den realen Anwendungsfall optimieren zu können empfehlen sie, echten Traffic mit TCPDump und Wireshark auf die statistische Verteilung der vorhandenen Paketgrößen zu untersuchen.

To TLS or not to TLS - That is not the question

Nabil Bitar, Jamal Hadi Salim und Pedro Tammela stellen in ihrem Talk die Ergebnisse ihrer Performanceanalyse für verschiedene Varianten von TLS auf x86 vor. Sie vergleichen die Performance für uTLS (also im Userspace), verschiedene Varianten von kTLS (im Kernel - mit und ohne Plattformoptimierung) sowie mit und ohne Hardware-Offloading.

Während für größere Datenströme wenig überraschend kTLS mit Offloading einen nennenswerten Vorteil bietet, ist der für das Offloading erforderliche Overhead für kurze Datenströme größer als der zu erzielende Performancezuwachs, sodass aktuell für kurze Streams uTLS zu bevorzugen ist.

Die Autoren stellen ausgiebige Messungen vor und demonstrieren, wie sie den Performance-Overhead mit ftrace bis hin zum Setzen der Offloading Socketoptions zurückverfolgen konnten. Während die direkten Ergebnisse dieses Talks wohl weniger für die Embedded- Entwicklung fühle ich mich sehr an ein Mantra meines Mentors erinnert, das ich mir auch in Zukunft weiter sehr zu Herzen nehmen möchte: Always check your assumptions.

Cross–Layer Telemetry Support in Linux Kernel

Justin Iurman und Benoit Donnet demonstrieren in ihrem Talk, dass die zunehmende Migration von monolithischen Services hin in eine verteilte Microservices-Architektur besonders auch das Debugging und die Performanceanalyse vor besondere Herausforderungen stellt.

Application Performance Management (APM) und verteiltes Tracing (z.B. openTelemetry) wählen hier den Ansatz, bisher bekannte Tracing-Infrastruktur, wie sie aus der Applikationsentwicklung schon lange bekannt ist und verwendet wird, nun verteilt über ein Netzwerkcluster auszurollen und synchronisiert über die gesamte Genese eines Requests über alle beteiligten Layer und Microservices zu tracen. Eine besondere Herausforderung sind hierbei unter anderem die Zeitspannen, da beispielsweise ein HTTP-Request eine verhältnismäßig große Round-Trip-Time gegenüber einem einzelnen Funktionsaufruf hat. Weiter stellt die Korrelation von Netzwerktraffic auf Funktionsaufrufe eine besondere Herausforderung dar, da die verteilten Aufrufe über mehrere Subkomponenten der Architektur verfolgt und zusammengesetzt werden müssen. Die Autoren schlagen vor, dafür generische Identifier in den Netzwerkpaketen zu verwenden, die über die verschiedenen Schichten propagiert werden könnten, jedoch trifft dieser Vorschlag in der anschließenden Diskussion und auch bei der Publikation entsprechender Drafts in der IETF auf erheblichen Widerspruch, da für den Vorteil der besseren Tracebarkeit erhebliche Overheads in Kauf genommen werden müssten. Aus diesem Grund laden die Autoren zu einer offenen Diskussion ein, um gemeinsam alternative und weniger invasive Lösungen für diese Anforderung zu suchen.

Integrating Power over Ethernet and Power over Dataline support to the Linux kernel

Im letzten regulären Talk der Konferenz erklärt Oleksij Rempel von Pengutronix, wie er ein Framework für Power Delivery over Media Dependent Interface geschaffen und mittlerweile bis nach net-next, also mainline gebracht hat.

Den meisten dürfte Power over MDI als PoE, also Power over Ethernet, bekannt sein, jedoch wurde das ursprüngliche Standardset in der IEEE mehrfach erweitert und auch auf andere Layer1-Implementierungen wie Base100x-T1 ausgeweitet.

Oleksij erklärt, dass nicht nur die Vielfalt (und wie bei der IEEE oft üblich fehlende kostenlose Verfügbarkeit) der Standards, sondern auch die Vielfalt an Namen für die einzelnen Komponenten eine Herausforderung für die Schaffung einer generischen Infrastruktur im Kernel und der Userspace-API darstellten.

Weiter sind für die einzelnen Standards verschiedene Optionale und Verpflichtende Funktionskomponenten sowie Kommunikationswege vorgesehen, beispielsweise um Leistungsverfügbarkeit out-of-band zum Netzwerktraffic zwischen Komponenten auszuhandeln.

Oleksij wählte daher den Ansatz, eine möglichst minimale Implementierung nach Mainline zu bringen. Insbesondere sein Ansatz, nur für ihn auch testbare Komponenten von Power over MDI zu integrieren, und später weitere Aspekte nachzureichen, ist ein sehr nachvollziehbarer und sinnvoller Ansatz. Aus diesem Grund ist aktuell im Framework nur der PoDL PSE support implementiert, also der Power Sourcing Equipment (Energiequelle) für PoDL (Power over DataLine für Base-T1). Dafür kann bereits jetzt der Admin State des PSE pro Port kontrolliert werden, dies muss aus naheliegenden Gründen unabhängig vom link admin state passieren. Sobald sich die uapi dafür stabilisiert hat wird Oleksij auch support in ethtool nachreichen. Einen Proof-of-Concept hat er bereits jetzt implementiert und demonstrierte ihn im Rahmen seines Talks.

Als nächste Schritte sieht Oleksij die Implementierung der Classification, also Out-of-Band-Aushandlung der genauen PoMDI-Implementierung, sowie Interfaces an das power delivery framework, um die zur Verfügung stehende Leistung zwischen den Hardware Ports eines PSE-Devices aufteilen zu können oder auch einzelne Ports priorisiert versorgen zu können. Auch die Ergänzung der Gegenseite (PD, also Powered Device) ist ein weiterer Schritt, um entsprechend des zur Verfügung stehenden Power Budgets beispielsweise im System Diagnosedaten zur Verfügung stellen zu können oder den Energieverbrauch an die gelieferten Energiemengen anpassen zu können.

Auch hofft Oleksij, bald schon PoE im Kernel unterstützen zu können.

Outreachy

Anschließend präsentierte Roopa Prabhu das Outreachy -Programm für networking-Projekte. Outreachy vermittelt Praktika in Opensource-Projekten und setzt Mentorship Programs auf, wobei besonderer Fokus darauf liegt, in diesen Projekten unterrepräsentierte Personengruppen zu unterstützen.

Als Beispiel für ein gelungenes Outreachy-Praktikum präsentierte Jaehee Park das Ergebnis ihrer Arbeit im vergangenen Sommer, in dem sie in verschiedenen Stellen Netzwerkstack Optimierungen vorgenommen hat, etwa der Nutzung von AVX2-Extension für ein beschleunigtes Nullen von skb- Strukturen, der beschleunigten Ausführung und Verbesserung von Selbsttest oder Verbesserungen für Gratious Arps.

Closing Ceremony

Mit der Closing Ceremony endete die NetDev 0x16. Nebst viel Lob für die Organisatoren und Sprecher wurde hier sehr offen über die Herausforderungen des Hybrid-Events diskutiert. Es ist erfrischend, in einer Community arbeiten zu dürfen, die sich ihrer Stärken und Herausforderungen bewusst ist, und auch vor Schwierigkeiten nicht zurückschreckt und offen diskutiert, wie Dinge verbessert werden können.