optimierung des freebsd-packet-capturing-stacks filediplomarbeit optimierung des...

Diplomarbeit

Optimierung desFreeBSD-Packet-Capturing-Stacks

(Improving the FreeBSD Packet Capturing Stack)

Fakultat IV - Elektrotechnik und InformatikIntelligent Networks / Intelligente Netze (INET)

Research Group of Prof. Anja Feldmann, Ph.D.

Alexandre Fiveg

9. Februar 2010

Prufer: Prof. Anja Feldmann, Ph. D.Betreuer: Fabian Schneider

Die selbstandige und eigenhandige Anfertigung versichere ich an Eides

Statt.

Berlin, den 9. Februar 2010 Alexandre Fiveg

Abstract

Die hohe Datenrate in modernen Netzwerken erschwert die vollstandige Erfassung desVerkehrs. Die Grunde konnen sowohl in der begrenzten Performance der Hardware, alsauch in der Ineffizienz von Software liegen.

Im Rahmen dieser Diplomarbeit wurden die fur die Verkehrserfassung verantwortlichenKomponenten eines konventionelles Rechnersystem analysiert mit dem Ziel, die Engstel-len welche die Paketverluste bei Verkehrserfassung verursachen konnen zu identifizieren.Dabei wurden sowohl die Hardware- als auch die Softwareaspekte betrachtet. Aufgrundder herausgestellten Problemen wurden neue Softwarekomponenten fur das BetriebssystemFreeBSD implementiert. Damit wurden sowohl Paketverluste als auch die Auslastung desRechnersystems bei der Erfassung des Verkehrs deutlich reduziert.

Inhaltsverzeichnis

1 Einleitung 3

1.1 Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.2 Hardware- und Software-Voraussetzungen . . . . . . . . . . . . . . . 4

1.2 Verwandte Projekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Begriffserklarung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Struktur der Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Grundlagen 7

2.1 Hardwareaspekte bei Capturing . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Netzwerkadapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2 Bussystem: PCI, PCI-X, PCIe . . . . . . . . . . . . . . . . . . . . . 13

2.1.3 RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.4 CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Softwareaspekte bei Capturing . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1 Packet Capturing in FreeBSD . . . . . . . . . . . . . . . . . . . . . . 16

2.2.2 Interruptbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.3 Berkley Packet Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.4 Libpcap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3 Zero-Copy BPF Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4 Capturing-Analyse und Anforderungen . . . . . . . . . . . . . . . . . . . . . 22

2.4.1 Capturing-Stack-Analyse . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4.3 Namenskonventionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Entwurf 27

3.1 Datenstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.1 Verwendungszwecke fur Ringpuffer . . . . . . . . . . . . . . . . . . . 27

3.1.2 Grunde fur die Ringpuffer-Struktur im ringmap-Capturing-Stack . . 27

3.1.3 Memory-mapped Paket-Ringpuffer fur ringmap-Capturing-Stack . . 27

3.2 Funktionalitat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.1 Paketzustellung in den Ringpuffer. Netzwerktreiber . . . . . . . . . . 30

3.2.2 Systemaufruf-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2.3 Userspace-Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . 36


4 Implementierung 40

4.1 Datenstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1.1 Ringpuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2 Funktionalitat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2.1 Treiber. Paketzustellung . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2.2 Anpassung der Libpcap . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3 Makrodefinitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4 Schwierigkeiten und Probleme wahrend des Implementierung-Prozess . . . . 45

4.4.1 Mangel an Dokumentation . . . . . . . . . . . . . . . . . . . . . . . 45

4.4.2 Komplexitat der Hardware . . . . . . . . . . . . . . . . . . . . . . . 45


5 Leistungsbewertung 475.1 Messaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.1.1 Testablaufspezifikationen . . . . . . . . . . . . . . . . . . . . . . . . 485.1.2 Erzeugung von Verkehr . . . . . . . . . . . . . . . . . . . . . . . . . 495.1.3 Messung der CPU-Auslastung und der Paketverluste beim Capturing 50

5.2 Test-Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.2.1 Parameter fur die Generierung des Netz-Verkehrs . . . . . . . . . . . 525.2.2 Treiber-Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.3.1 Ringmap-Paket-Capturing-Stack . . . . . . . . . . . . . . . . . . . . 535.3.2 Vergleich generic- mit ringmap-Paket-Capturing-Stack . . . . . . . . 60

6 Zusammenfassung 636.1 Erreichte Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.1.1 Verbesserung der Capturing-Performance . . . . . . . . . . . . . . . 646.1.2 Stabilitat und Benutzbarkeit . . . . . . . . . . . . . . . . . . . . . . 64

6.2 Einschrankungen des ringmap-Packet-Capturing-Stack . . . . . . . . . . . . 646.3 Zukunftige Themen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.3.1 Performance-Vergleich mit dem Zero-Copy-BPF-Buffers . . . . . . . 656.3.2 10Gbit Capturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

1 Einleitung

1.1 Motivation.

Paket-Capturing oder Sniffing ist der Prozess des Abfangens von Netzwerkpaketen, mitdem Ziel diese zu speichern, zu analysieren und darzustellen. Aufgrund der limitiertenRechnerleistung und Ineffizienz der Software, kommt es leider oft dazu, dass nicht allePakete aus dem Netz untersucht werden konnen.

Die Hardwareressourcen eines Computers wie Bandbreite der internen Bussen, CPU-Zyklen-Rate und Speicher (RAM und Hintergrundspeicher) sind begrenzt. Das hat zurFolge, dass die Menge der ankommenden Paketen, die ein Computer pro Zeitintervall be-arbeiten und speichern kann, auch nicht unendlich groß ist. Die “Geschwindigkeit” desDatentransports zwischen einem Peripherie-Gerat und RAM ist durch die Bandbreite desBussystem begrenzt. Die Anzahl der im RAM befindlichen Pakete, die sich pro Zeitin-tervall bearbeiten bzw. filtern lasst ist sowohl von der Leistung des Prozessorbusses alsauch von der CPU-Leistung abhangig. Wenn die empfangenen Pakete auf die Festplattegeschrieben werden sollen, geschieht dies auch nicht schneller, als es der Hintergrundspei-cher erlaubt. Jede von den obengenannten Hardwarebegrenzungen kann Datenverluste beiCapturing verursachen, wenn die Rate der ankommenden Pakete uber die Performance-Grenzen der darunterliegenden Hardwarekomponenten steigt.

Aber nicht nur die Hardware stellt einen Flaschenhals fur die Datenbearbeitung in einemRechnersystem dar. Die Hardwareressourcen konnen von der Software ineffektiv benutztwerden. Zum Beispiel: wenn ein Programm wesentlich mehr Operationen ausfuhrt, als zurLosung des Problems notig waren, dann erzeugt es einen unnotig hohe Systemlast undreduziert damit die Datenmengen, die es in einem Zeitintervall bearbeiten konnte.

Das Ziel dieser Diplomarbeit ist es, die fur Capturing relevante Komponente des Betriebs-system FreeBSD zu untersuchen, die potentiellen “Engstellen” in der Software, die zu denDatenverlusten fuhren konnen, herauszufinden, und effiziente Algorithmen zur Erhohungdes Datendurchsatzes und Reduzierung der Systemauslates beim Capturing zu erarbeiten,zu implementieren und auszuwerten.

Um Anforderungen fur den Entwurf der Algorithmen stellen zu konnen, mussen zuerstdie fur Capturing relevante Aspekte erklart werden. Dies wird im Kapitel Grundlagen ge-macht. Auch in dem Kapitel werden die dargestellten Capturing-Hintergrunde analysiert.Dabei wird versucht, herauszufinden, an welchen “Stellen” und unter welchen Bedingun-gen Performance-Verluste beim Capturing stattfinden konnen. Auf Basis der Ergebnissewerden die Entwurf- bzw. Implementierung-Anforderungen fur den praktischen Teil derDiplomarbeit abgeleitet.

Bevor wir mit den Grundlagen anfangen, werden wir die fur Capturing-Thematik wichtigenBegriffe definieren und die Hardware- und Software-Voraussetzungen fur die Diplomarbeitangeben.

3

1.1.1 Definitionen

Packet-Capturing nennen wir den Prozess des Empfangens, Filterns, Bearbeitens, Spei-cherns und ggf. Darstellens des Datenverkehrs aus einem Netzwerk.

Capturing-System ist ein Rechnersystem mit der Software, die fur Packet-Capturingbenotigt wird. Auf der Abbildung 1 sind die Hardware-Komponente eines Capturing-Systems dargestellt. Das sind: Netzwerkadapter, RAM, CPU, Hintergrundspeicherund Terminal. Die schwarzen Pfeile zeigen die Richtung des Datentransfers beimCapturing.

Packet-Capturing-Stack ist die Software, die fur Capturing benotigt wird. Sie kann ausmehreren Komponenten bestehen. Im Betriebssystem FreeBSD sind diese Kompo-nenten sowohl im Kern des Betriebssystem als auch in der Userspace-Library libpcapimplementiert.

Capturing-Performance ist die Anzahl von Paketen, die das Capturing-System proeiner bestimmten Zeiteinheit aufnehmen, bearbeiten, und speichern kann.

1.1.2 Hardware- und Software-Voraussetzungen

Fur den praktischen Teil der Diplomarbeit wird die folgende Hardware und Software vor-ausgesetzt:

• Hardware:

– PC: x86-Architektur

– eine Netzwerkkarte aus der Familie Intel(R) PRO/1000 Gigabit Ethernet Ad-apter:82540EP/EM, 82541xx, 82544GC/EI, 82545GM/EM, 82546GB/EB, 82547xx

• Software:

– Betriebssystem: FreeBSD 7.x

– Treiber fur Intel(R) PRO/1000: em-6.9.x

Die vorausgesetzte Hardware hat keine besonderen Anspruche und ist uberall zu bekom-men. Die Software steht unter BSD-Lizenz, ist frei erhaltlich und einfach auf der voraus-gesetzten Hardware installierbar.

1.2 Verwandte Projekte

Zero-Copy BPF Buffers

Im Jahr 2007 haben Robert Watson and Christian Peron (Universitat Cambridge) ihreLosung zur Verbesserung von FreeBSD Capturing-Stack vorgeschlagen und implemen-tiert [3]. Die Idee basiert auf Verwendung von shared-memory-Buffers. Shared-Memory-Buffers sind von mehreren Prozessen gemeinsam benutzte Speicherbereiche. Mit ihrer Hilfekonnen Prozesse kommunizieren, ohne Copy-Operationen ausfuhren zu mussen. Weil dieCopy-Operationen besonders viel CPU-Zyklen brauchen, verbessert dies wesentlich dieAusfuhrungszeiten von Programmen. Die Details des “Zero-Copy BPF Buffers”-Projektwerden im Kapitel Grundlagen (Abschnitt 2.3) Erklart.

4

Hintergrund-

Speicher

N e t z w e r k a d a p t e r

RAM

CPU’s

Darste l len Speichern

Terminal

Fi l tern und Bearbei ten

P a k e t e n e m p f a n g

Abbildung 1: Capturing-System

1.3 Begriffserklarung

In dieser Diplomarbeit werden oft einige englische Begriffe auftauchen. Sie haben zwardeutsche Ubersetzung, werden aber meistens in ihrer englischen Form benutzt. Aus die-sem Grund gibt es hier eine kurze Begriffserklarung. Auch, weil der praktische Teil derDiplomarbeit auf einer konkreten Hardware- und Softwareplattform realisiert wird, sinddie Bedeutungen der Begriffe gezielt dem Kontext der Diplomarbeit angepasst.

Userspace ist ein Speicherbereich und Ausfuhrungskontext fur Useranwendungen.

Kernelspace ist ein Speicherbereich und Ausfuhrungskontext fur den Kern des Betriebs-system.

Kernel-Thread ist ein Prozess, der vollkommen in Kernelspace ausgefuhrt wird undkeinen direkten Zugriff auf Adressraum eines User-Prozesses hat. Die Kernel-Threadswerden wie normale Threads in eigenen Threadskontext mit den eigenen Funktions-Stacks aber mit einer hohere als bei normalen Threads Prioritaten ausgefuhrt.

Interrupt (Deutsch: Unterbrechung) ist ein Ereignis, das den Instruktionsfluss aufeiner CPU unterbricht und Ausfuhrung einer Interrupt-Routine (Interrupt handler)auf dieser CPU verursacht.

DMA (Deutsch: Speicherdirektzugriff) bezeichnet eine Art des Specherzugriffes, dieuber Bussystem ohne Beteiligung der CPU realisiert ist [12].

Memory-Mapping ist eine Funktionalitat des Betriebssystem, deren Aufgabe es ist,mehrere virtuelle Adressraume auf einen bestimmten physischen Speicherraum ab-zubilden.

Pointer: Zeiger

5

Systemload ist der prozentuelle Zeitanteil, den CPUs im Systemmodus (protected mode,Ring-0 ) verbringen.

Overhead: Uberflussige Rechenzeiten, Bustransaktionen und Daten, die auf nicht dereigentlichen Aufgabe dienende Prozesse verwendet werden mussen.

Descriptor (Deutsch: Deskriptor) ist eine Datenstruktur, die zur Beschreibung undAdressierung eines Speichersegmentes dient. Descriptor enthalt die Anfangsadres-se des Segmentes und, eventuell, die Lange, die Zugriffsrechte, und andere fur dasSpeichersegment relevante Informationen.

Frame ist Paket auf link-layer Ebene. In dieser Diplomarbeit werden die Begriffe “Paket”und “Frame” als Synonyme benutzt.

NIC (Network Interfeace Controller) Netzwerkadapter. In dieser Diplomarbeit istunter diesem Begriff der Intel Ethernet Gigabit Adapter gemeint (siehe 1.1.2).

1.4 Struktur der Diplomarbeit

Das nachste Kapitel Grundlagen prasentiert Hardware- und Software-Aspekte von Packet-Capturing. Dabei werden zunachst die Funktion der Hardware vorgestellt, die fur dieCapturing-Performance relevant ist. Dies betrifft die Netzwerkkarte, das RAM und denSystem-Bus. Unter Software-Aspekten wird der schematisches Entwurf des Adapter-Treibersund des Berkley-Packet-Filters dargestellt. Außerdem werden in dem Kapitel die Entwurfs-Anforderungen fur den neuen Packet-Capturing-Stack formuliert.

Im Kapitel Entwurf werden Algorithmen zur Verbesserung des FreeBSD Capturing Stacksvorgestellt. In dem Kapitel werden lediglich logische Losungen der Probleme, die bei Cap-turing auftauchen, vorgeschlagen. Die Losung wird zwar abstrakt dargestellt, basiert den-noch wird auf der konkreten fur die Diplomarbeit vorausgesetzten Hardware.

Im Kapitel Implementierung wird die Struktur der entwickelten Software vorgestellt.Hierbei werden im Speziellen die Software-Komponenten gezeigt und kurz erklart, die furdie Umsetzung der im Entwurf vorgestellten Algorithmen implementiert sind.

Im Kapitel Leistungsbewertung findet man die Ergebnisse des Vergleichs der Perfor-mance des FreeBSD-Capturing-Stack im “generischen” Fall mit dem neuen, im Rahmender Diplomarbeit verbesserten, Capturing-Stack.

Im Kapitel Schlussfolgerung wird das wichtigste aus der Diplomarbeit in Kurzformdargestellt.

6

2 Grundlagen

Beim Capturing wird jedes aus dem Netz empfangenen Paket zuerst in den internen Spei-cher des Netzwerk-Adapter kopiert. Sobald es moglich ist, macht der Adapter den DMA-Transfer der vorhandenen Pakete in den RAM und meldet dies durch ein Interrupt. Weiterwerden die Paket-Daten von der CPU bearbeitet, wobei mehrere Datentransporte uberden Prozessorbus zwischen RAM und CPU auftreten konnen. Nach der Bearbeitung bzw.Filterung konnen die Pakete auf der Festplatte gespeichert oder ggf. auf dem Terminaldargestellt werden.

In diesem Kapitel wird die fur Capturing relevante Hard- und Software dargestellt. Es wirddabei analysiert bei welchen Capturing-Komponenten unter welchen Umstanden Engpassebei der Paketerfassung auftretten konnen. Anhand der herausgefundenen Problemen wer-den Anforderungen und Ansatze fur den Entwurf der neuen Capturing-Software formuliert.Zu beachten ist, dass die dargestellten Aspekte sich vollkomen auf die fur die Diplomarbeitvorausgesetzten Hardware und Software beziehen. (siehe Abschnitt 1.1.2).

Obwohl die eigentliche Aufgabe der Diplomarbeit in der Analyse und Verbesserung derSoftwarekomponenten liegt, dennoch ist es unentbehrlich , die Funktionsweise der darun-terliegenden Hardwarekomponenten zu kennen. Dies folgt daraus, dass die Hardware dieRolle eines Betriebsmittels fur die Software-Anwendungen spielt, und deshalb die Softwaremoglichst effektiv die zur Verfugung gestellte Hardware-Ressourcen nutzen muss. Dafurmuss bekannt werden, wie die einzelne Hardware-Bestandteile funktionieren.

2.1 Hardwareaspekte bei Capturing

In diesem Abschnitt wird die Funktionsweise der Hardware-Komponenten eines Capturing-Systems vorgestellt. Dabei werden hauptsachlich die fur Performance des Capturing rele-vanten Aspekte betrachtet. Und es wird versucht herauszufinden, welche der Komponentenden Capturing-Prozess performancemaßig negativ beeinflussen konnen, und unter welchenUmstanden dies auftritt.

2.1.1 Netzwerkadapter

In diesem Abschnitt wird beschrieben wie der Adapter die Pakete empfangt und wie er siein den RAM weiterleitet. Dieses Wissen ist notwendig fur die Auswertung der Capturing-Performance, weil die Engstellen, die auf diesem ersten Datenweg vorhanden sind, diehohste theoretische Grenze fur Performance des gesamten Capturing-Prozess auf demCapturing-System bilden. Außerdem, ist die Kenntnis der Netzwerkadapter-Funktionenauch fur das Implementieren der Capturing-Software unentbehrlich, denn um die Softwa-re fur den Zugriff auf ankommende Daten implementieren zu konnen, muss man zuerstwissen, auf welche Art und Weise die Hardware diese Daten zur Verfugung stellt.

Außerdem wird in diesem Kapitel das Interrupt-Coalescing-Mechanismus des Intel Gi-gabit Adapters erlautert. Interrupt-Coalescing erlaubt die Interrupt-Rate des Adapters zusteuern und damit die Capturing-Performance zu beeinflussen.

7

Special Error Sta tus Checksum Length

Adress des Puffers für ein Packet

063

Abbildung 2: DMA-Deskriptor von Intel Ethernet Adapters

Paketempfang und DMA-Transfer in RAM

Der Empfang eines Paketes an einem Netzwerkadapter schließt das Erkennen des Pake-tes auf dem “wire”, das Anwenden von Adressfilterung, das Speichern des Paketes aufdem Adapter-Speicher und dann Transfer des Paketes in den RAM ein. Im RAM wirdpro Paket ein Paket-Puffer alloziert. Die Große des Paket-Puffers ist hardwareabhangigund wird durch das Setzen der entsprechenden Bits in Receive Control Register (RCTL)des Adapters festgelegt [20]. In dem Fall, wenn der Paket großer als der Paket-Puffer ist,werden mehrere Paket-Puffer fur die Speicherung des Paketes verwendet.

Der Datentransport in den RAM wird per DMA (Direct Memory Access) durchgefuhrt. Esgibt unterschiedliche DMA-Arten: die “klassische” Register-Based-DMA und die Deskriptor-Based-DMA [31]. Der Intel Gigabit Adapter verwendet die zweite Variante. Beim Deskriptor-Based-DMA werden alle fur DMA benotigte Daten (Ziel-Adresse, Lange des Speicherseg-ments, etc. . . ) nicht direkt in den DMA-Registern gespeichert, sondern in einem Arrayim RAM abgelegt. Jedes Element des Arrays tragt den Namen “Deskriptor”. Der De-skriptor enthalt die Adresse des Puffers im RAM, an die die Daten beim DMA-Transfergeschrieben werden und andere Bit-Blocke, die sowohl fur die Steuerung des DMA-Enginedes Adapters, als auch zur Benachrichtigung des Capturing-Prozesses uber den Status derDMA-Operation und uber Integritat der empfangenen Daten dienen(siehe Abbildung 2).Fur jeden Puffer im RAM, an den die Daten vom Gerat transferiert werden, bzw. furjeden DMA-Transfer, steht genau ein Deskriptor zur Verfugung, wobei jeder Deskriptornach Abschluss des Transfers erneut fur DMA-Transfers wiederverwendet werden kann.

Deskriptor-Format

In Abbildung 2 ist das Format des Deskriptors des Intel Gigabit Adapters dargestellt. Diegrau unterlegten Bereiche bezeichnen Felder, die beim Transfer des Paketes in den RAM,von der Hardware verandert werden. Wenn der Adapter das Paket aus seinem Adapter-Speicher in den Paket-Puffer im RAM kopiert, setzt er im entsprechenden Deskriptor dieLange (Length) der in Puffer gespeicherten Daten, die Prufsumme (Checksum) des ganzenPaketes, den Status der DMA-Operation und Fehlerinformationen (Errors) 1.

Die Software kann durch das Lesen der vom Adapter in den Deskriptor geschriebenenWerte den Zustand des DMA-Transfers und die fur das empfangene Paket relevanten In-formationen herausfinden. Außerdem kann die Software auch den neuen Paket-Puffer al-lozieren und die Adresse des neuen Puffer im gerade benutzten Deskriptor setzten, sodassbeim nachsten Benutzen des Deskriptor, der DMA-Transfer in den neuen Puffer stattfindetund die Daten im “alten” Paket-Puffer nicht uberschreibt.

1Siehe Software Developer’s Manual [20], Seiten: 20-24

8

BASE

BASE + SIZE

Gehör t zu Hardware

Freie Puffer

RDH (HEAD)

RDT (TAIL)

Abbildung 3: Receive Deskriptor Ringpuffer

Deskriptor-Ringpuffer

Der Adapter betreibt Deskriptoren als einen Ringpuffer (siehe Abbildung 3). Der Adapterenthalt zwei Register: Receive Descriptor Head Register (RDH) und Receive DescriptorTail Register (RDT), welche die Rolle von HEAD- und TAIL-Pointers im Ringpuffer spie-len und die Speicherbereiche mit Deskriptoren referenzieren. Jedes mal, wenn der Adapterein neues Paket in den RAM schreibt, wird der Wert im RDH-Register inkrementiert,sodass dieser Wert dem Deskriptor fur den nachsten DMA-Transfer entspricht. Wenn dieSoftware die Daten aus dem Paket-Puffer gelesen hat, soll sie den Wert im RDT-Registerinkrementieren, aber so, dass dieser Wert dem Deskriptor entspricht, der den Paket-Puffermit dem gerade gelesenen Daten referenziert. Daraus folgt:

• RDH = RDT ⇐⇒ Der Ring ist “voll”:Es gibt keine freien Deskriptoren fur einen DMA-Transfer. In diesem Fall stopptdie Hardware den Datentransfer in den RAM und wartet bis die Software die Pa-kete in den Paket-Puffern liest (bzw. bearbeitet) und den Wert im RDT-Registerentsprechend erhoht.

• RDT = (RDH − 1) mod SIZE ⇐⇒ Der Ring ist “leer”:Die Software hat alle Pakete, die vom Adapter in den RAM geschrieben wurden, be-arbeitet und wartet jetzt auf das Ankommen von neuen Daten bzw. auf das Erhohendes Wertes im RDH-Register vom Adapter.

In der Abbildung 3 ist ein Deskriptor-Ringpuffer dargestellt. Die weiss gezeichnete Felderzwischen RDH und RDT, bezeichnen die Deskriptoren, die fur DMA-Transfer der neuenPakete bereitstehen. Demgegenuber bezeichnen die graue Felder die Deskriptoren, welchedie Paket-Puffer mit den neuen Paketen referenzieren, die von der Software noch nichtgelesen wurden.

Deskriptor-Fetching

Um die Werte in den Deskriptoren zu aktualisieren, und um der Software bzw. dem Ad-apter die aktualisierten Werte in den Deskriptoren zur Verfugung zu stellen, werden die

9

Deskriptoren zwischen RAM und Adapter hin- und her kopiert.

Wenn die Software auf den Paket-Puffer mit dem neuen Paket zugegriffen hat, erhohtsie den Wert im RDT-Register, und stellt damit dem Adapter den Deskriptor, der denvorher gelesenen Paket-Puffer referenziert, zur Verfugung. Der Adapter kopiert bei Gele-genheit den Deskriptor in seinen dazu geeigneten internen Speicher. Und, spater, wahrenddes Transfers der aus dem Netz empfangenen Paketes in den RAM wird der Deskrip-tor lokal auf dem Adapter aktualisiert und wieder zuruck in den Deskriptor-Ringpuffergeschrieben.

Interrupt

Die Anwesenheit von neuen Paketen im RAM wird vom Adapter durch einen Interruptgemeldet. Die Interrupts, genau gesagt, die Art und Weise, wie die Interrupts behandeltwerden, spielen fur die Capturing-Performance eine bedeutende Rolle. Wahrend der Be-handlung eines Adapter-Interrupts sind die Interrupt-Ereignisse des Adapters gesperrtund das Capturing-System ist nicht mehr in der Lage, das Ankommen von neuen Paketenzu melden und darauf zu reagieren. Das hat zur Folge, dass, je langer die Behandlungdes Interrupts dauert, die Wahrscheinlichkeit umso hoher ist, dass bevor die Interrupts-Behandlung abgeschlossen ist, alle freie Paket-Puffer mit neuen Paketen “gefullt” werden.Das fuhrt unvermeidlich zum Verlust der nachsten ankommenden Pakete.

Aus diesem Grund muss die Interrupt-Behandlung-Routine moglichst effizient implemen-tiert werden und moglichst schnell abgearbeitet werden. Die Laufzeit des Interrupt-Handersist aber noch nicht alles. Wegen des “Overhead”, den jeder Interrupt mit sich bringt, spieltauch die Interrupt-Rate eine große Rolle fur Capturing-Performance.

Auf FreeBSD Betriebssystem enthalt die Bearbeitung jedes Interrupts die folgende Schrit-te [26]:

1. Hardware und Software Kontextwechsel2 , die Speicherung von CPU-Register, dasWechsel des aktuellen Stack

2. Zugriff auf die Hardware-Register und Herausfinden der zustandigen Interrupt-Service-Routine (ISR)

3. Aktualisieren der Interrupt-Counters

4. Ausfuhren der Interrupt-Service-Routine(ISR)

Die Ausfuhrungszeit von ISR (Schritt 4) ist variabel und hangt von der Komplexitat derim Interrupt-Kontext ausgefuhrten Funktionen ab. Dagegen bleibt die Ausfuhrungszeit derSchritte 1 bis 3 (eigentlicher Interrupt-Overhead) konstant und wird bei jeder Interrupt-Behandlung immer dabei sein. Die Ausfuhrungszeit der Schritte 1 bis 3 betragt auf einemkonventionellen PC einige Mikrosekunden [22], was verursacht, dass bei einer hohe Ratevon Interrupt-Ereignissen (z.B. mehr als 100000/sec) ein dominierender Anteil der CPU-Ressourcen nur fur den Interrupt-Overhead verwendet werden kann. Beim Capturing ver-ursacht das Paket-Verluste.

Außerdem kann eine hohe Interrupt-Rate das Capturing-System in den receive-livelock -Zustand bringen [28]. Receive-livelock ist ein Zustand, in dem das Rechnersystem die

2Gemeint ist Umschalten der CPU zwischen Ring-0- und Ring-1-Modus [27]

10

ganze CPU-Zeit lediglich fur die Interrupt-Bearbeitung verbraucht und dadurch keineCPU-Ressourcen fur die Ausfuhrung anderer Capturing-Prozesse freigibt. Falls die Rateder ankommenden Pakete so hoch ist, dass die dadurch enstehende Interrupt-Load die an-deren Prozesse stark vernachlassigt, konnen Paketverluste enstehen, denn die Capturing-Software wird unter FreeBSD sowohl im Interrupt-Kontext als auch im Userspace aus-gefuhrt.

Interrupt-Coalescing

Zur Beseitigung des receive-livelock-Problems und Minimierung des gesamten Interrupts-Overhead gibt es die unterschiedliche Losungsansatze [28, 19]. Eine davon, Interrupt-Coalescing, wird auf dem Intel Gigabit Adapter verwendet. Unter dem Begriff Interrupt-Coalescing versteht man das Zusammenfassen von Interrupts von mehreren Ereignissen zueinem einzigen Interrupts. In unserem Fall bedeutet dies, dass im Lauf einer Interrupts-Behandlung nicht nur ein, sondern mehrere empfangene Pakete zusammen bearbeitet wer-den konnen. Damit lasst sich die Interrupt-Rate reduzieren, was auch zur Minimierungden gesamten Interrupt-Overhead und gleichzeitig zur Vergroßerung des Datendurchsatzesbei Capturing fuhrt.

Interrupt-Coalescing wird auf dem Adapter mit Hilfe von drei Timern realisiert [19]:

Absolute-Delay-Timer: Verzogert das Interrupt-Ereignis um ein bestimmtes Zeit-Interval(siehe Abbildung 4). Der Timer wird nach dem Transfer des ersten Paketes in denRAM initialisiert und gestartet. Der Timer wird generiert nach dem Ablauf des imRADV-Register [20] gesetzten Interval einen Interrupt. Nach dem Interrupt, sobald dasneue Paket in den RAM transferiert wird, wird der Absolute-Timer wieder reinitia-lisiert und gestartet. Der Wert im RADV-Register kann durch den sysctl-Befehl [18]gesetzt werden:

# sysctl dev.em.0.rx_abs_int_delay N (1)

Packet-Delay-Timer: Wie auch der Absolute-Delay-Timer verzogert auch dieser Timenach dem Empfang eines Paketes das Interrupt-Ereignis um ein bestimmtes Zeit-Interval (siehe Abbildung 5). Der Packet-Timer wird aber nach jedem Transfer einesneuen Paketes in den RAM jedes mal reinitialisiert und wieder gestartet. Der Inter-rupt des Timers findet daher nach Ablauf des Zeit-Intervals nur dann statt, wennwahrend des Zeitintervalls keine neue Pakete vom Adapter in den RAM ubertragenwerden. Das Zeit-Intervall fur Packet-Timer wird im RDTR-Register [20] gesetzt:

# sysctl dev.em.0.rx_int_delay N (2)

Interrupt-Throttle-Timer: Bestimmt eine minimale inter-Interrupt-delay fur den Ad-apter. Damit wird gleichzeitig fur receive und transmit eine maximale Interrupt-Rate garantiert. Der minimale Zeit-Interval zwischen zwei Interrupts wird in ITR-Register [20] gesetzt.

Fur das Setzen des Wertes in den ITR-Register ist kein sysctl vorgesehen. Um ITR

zu setzen, muss man in den Code des Treibers uber die folgende Makrodefinition diemaximale Anzahl der Interrupts pro eine Sekunde eingeben:

#define MAX_INTS_PER_SEC 8000 (3)

11

Time

Pakete

Absolute Timer

Timer Start

Interrupt

Abbildung 4: Absolute Delay Timer

Time

Pakete

Packet Timer

Timer Start Timer Restart

InterruptInterrupt

Abbildung 5: Packet Delay Timer

Die obengenannten Timer minimieren die Interrupt-Rate durch Verzogerung der Interrupt-Ereignisse. Bei einer hohen standigen Paket-Rate ist der Absolute-Timer die primareInterrupt-Quelle. Dagegen ist der Packet-Timer die Ursache der meisten Interrupts, wenndie Paket-Rate klein ist, oder, wenn der Verkehr kurze Bursts enthalt. Die beiden Timerkonnen aber nicht immer die eine vorhersagbare Interrupt-Rate garantieren. Erstens gites fur das Senden von Daten ein identisches Paar von Timern fur die fur die Transmit-Interrupts. Diese zwei Timer-Paare arbeiten unabhangig voneinander und konnen infol-gedessen gegenseitig Ihr Verhalten storen. Zweitens ist der Verkehr in Netzen meistensunvorhersagbar. Dies kann beim Benutzen von Absolute- und Packet-Timers eine nichtstandige oder sogar explosive Interrupt-Rate verursachen. Dieser Effekt wird durch Be-nutzung von Interrupt-Throttling beseitigt. Interrupt-Throttling funktioniert unabhangigvon allen anderen Interrupt-Quellen und wird nicht durch die Verkehrsrate beeinflusst [19].

Adapter: Einfluss auf Capturing

Die Aufgabe des Netzwerk-Adapters beim Capturing ist es, die Pakete aus dem Netz zuempfangen, sie in den RAM zu schreiben und durch das Interrupt dem RechnersystemBescheid uber die neue Pakete im RAM zu geben.

Der Durchsatz beim Datentransfer vom Adapter in den RAM ist zum großen Teil durchPerformance-Eigenschaften des Bussystems beeinflusst. Der Adapter selbst kann auf unter-schiedlicher Art und Weise die zur Verfugung stehende Bussystem nutzen. Dieses Vorgehenist aber auf dem Adapter “hardgecodet” und kann nicht optimiert werden.

Anders sieht es mit mit den Interrupts aus. Die Interrupt-Rate kann durch sysctl-Variablenauf dem Adapter beliebig geandert werden. Interrupt-Coalescing-Mechanism erlaubt durch

12

das Verzogerung der Interrupt-Ereignisses den gesamten Interrupt-Overhead zu minimie-ren un dadurch den Datendurchsatz bei Capturing zu erhohen.

Zu beachten aber, dass zu große Verzogerung des Interrupt-Ereignisses auf dem Adap-ter auch einige Nachteile bringen kann:

• Da mehrere Pakete in einem Interrupt bearbeitet werden, kann die InterruptverzogerungZeitliche Paket-Verhaltnisse verfalschen, was weniger korrekte Paket-Zeitstempelnund dadurch die ungenaue Verkehrsanalyse verursachen kann.

• Bei einer hohen Verkehrsrate konnen zu große inter-Interrupt-delays, auch Paketver-luste verursachen.

Aus den obengenannten Grunden folgt, dass die Interrupt-Rate sowohl nicht zu groß alsauch nicht zu klein gesetzt werden muss, um die Paketverluste und Timing-Verfalschungenzu vermeiden.

Per default im aktuellen FreeBSD-7.x fur Interrupts-Verzogerung wird lediglich Interrupt-Throttling benutzt. Per Default wird Throttling so gesetzt, dass der Adapter maximal 8000Interrupts pro Sekunde generieren kann. Das Benutzen der Paket- und Absolut-Timernwird im aktuellen FreeBSD von den Treiber-Entwickler nicht empfohlen [16].

2.1.2 Bussystem: PCI, PCI-X, PCIe

Das PCI-Bus verbindet den Netzwerkadapter mit dem RAM. Daraus folgt, dass der Da-tendurchsatz beim Datentransfer vom Adapter in den RAM von der maximalen Lei-stungsfahigkeit des Busses begrenzt wird.

Es gibt unterschiedliche PCI-Varianten: PCI, PCI-X, PCIe. Die theoretischen Datentrans-ferraten der klassischen PCI und PCI-X scheinen auf dem ersten Blick fur den Netzver-kehr 1Gbit/sec ausreichend zu sein [11]. Das ist aber leider nicht immer der Fall. Die Da-tenubertragung an den beiden Bussystemen hat bei jedem Datentransfer einen bestimmtenOverhead, der aus den folgenden Faktoren entsteht [27]:

• Handshaking:

– Fur die Verbindungsaufbau werden einige Bus-Transaktionen benotigt.

• Zeitmultiplexing:

– Der Bus kann nicht gleichzeitig fur mehrere parallele Datentransfers benutztwerden. Außerdem stehen die Busleitungen sowohl fur die Daten als auch furdie Adressen zur Verfugung und konnen bei einer Bus-Transaktion entwederfur Datentransfer oder fur Adressentransfer benutzt werden.

• Arbitrierung:

– Da der Bus nicht gleichzeitig von mehreren Hardware-Komponenten benutztwerden kann, werden einige Bus-Transaktionen fur Arbitrierung gebraucht.

Das hat zur Folge, dass die effektive Datentransferrate eines Busses umso niedriger ist,je mehr Bus-Transaktionen fur die Ubertragung der Datenmenge benotigt werden. DerPCI-Bus kann aber eine Datenmenge, die kontinuierlich in den RAM geschrieben werdensoll, im Burst-Modus, ohne zusatzliche Adressubertragung fur jeden Datenwort-Transfer,

13

erledigen. Dies kann beim Transfer grosser Datenmengen die Anzahl der benotigen Bus-Transaktionen und damit den Overhead wesentlich verringern.

PCIe ist mit dem Unterschied zu dem konventionellen PCI kein shared Bussystem, son-dern eine separate serielle Punkt-zu-Punkt-Verbindung. Einzelne Komponenten werdenuber Switches verbunden. Das ermoglicht die direkte Verbindungen zwischen einzelnenGeraten herzustellen, so dass die Kommunikation einzelner Gerate untereinander die er-reichbare Datenrate anderer Gerate nicht beeinflusst.

Bussystem: Einfluss auf Capturing

Die minimale Datentransfer-Einheit fur den Intel Gigabit Adapter ist ein Paket-Puffer. Je-de Datenubertragung in den Paket-Puffer benotigt eine Reinitialisierung des DMA-Enginedes Adapters und den Aufbau des Transfers uber PCI-Bus. Wenn wir davon ausgehen, dassdie Paket-Große kleiner als die Paket-Puffer-Große ist, und dadurch pro Paket genau einenPaket-Puffer verwendet wird, skaliert der Bus-Transaktion-Overhead beim Datentransferhauptsachlich mit der Paketanzahl, nicht mit der ubertragenen Datenmenge.

Wenn die “gecapturte“ Datenmenge hauptsachlich aus den kleinen Paketen entsteht, dannverursacht sie einen großeren Overhead bei ihrem Transfer uber den Bus in den RAM alsdie gleiche Datenmenge, die aber aus den großeren Paketen entstehen wurde. Das hat zurFolge, dass der Datenweg uber den PCI-Bus umso enger wird, je kleiner die Pakete beimCapturing sind.

2.1.3 RAM

Erst nach dem Transfer in den RAM stehen die erfassten Pakete fur die Software-Anwendungenzur Verfugung. Die Software greift auf die Daten im RAM zu, filtert bzw. bearbeitet sieund danach ggf. trifft die Entscheidung uber Darstellung der Informationen aus den Pa-keten oder Speicherung diesen auf der Festplatte.

Die Geschwindigkeit, mit der die im RAM befindlichen Daten bearbeitet werden konnen,ist von der Leistung des RAM-Speichers und des Prozessorbusses abhangig, weil die CPUfur die Ausfuhrung der Operationen auf Daten, erstmal diese Daten aus dem Speicherholen muss.

Die effektive Datentransferrate bei der Datenubertragung zwischen den RAM und CPUkann sich von den theoretischen Werten sehr stark unterscheiden. Es gibt einige Bench-marks wie Stream [8] und lmbench [5], die es erlauben, die effektive Datentransferratezwischen CPU und RAM zu messen.

RAM: Einfluss auf Capturing

Zu beachten ist, dass die mit Hilfe der Benchmarks gemessene effektive Speicherbandbrei-te nicht der einzige Faktor fur Performance der Bearbeitung der im RAM befindlichenPakete ist. Der Software-Prozess kann wahrend Paketbearbeitung fur jedes Paket mehrereKopie-Operationen durchfuhren, was die Menge der durch den Prozessor-Bus transferie-renden Daten vergroßern und damit diesen Datenweg zur einer Engstelle machen kann.

In unserem Fall bedeutet das, dass um herauszufinden, ob der RAM beim Capturing

14

eine Engstelle ist, muss man genau den Capturing-Algorithmus kennen, und zwar wievieleKopie-Operationen pro Paket gemacht werden.

2.1.4 CPU

Die CPU-Leistung ist in den letzten Jahrzehnten wesentlich starker gewachsen als die deranderen Hardwarekomponenten eines Computers. Damit ist es eher unwahrscheinlich, dassdie CPU die Engstelle beim Capturing darstellt, außer, wenn die Software-Anwendung siesehr ineffizient benutzt (z.B. durch Ausfuhren mehrerer unnotigen Operationen).

Dennoch gibt es einige Kriterien an den modernen CPU-Architekturen, welche die Perfor-mance eines Rechen-Prozesses negativ beeinflussen konnen. Es handelt sich vor allem umdie Multi-Core-Prozessoren. Sie konnen simultan mehrere Prozesse gleichzeitig ausfuhren,was einen Performance-Zuwachs ermoglicht. Auch wegen der Problemen mit der Datenlo-kalitat, konnen die Multi-Core-Systeme die Ausfuhrungszeiten von einigen Datenbearbei-tungsfunktionen verlangern.

Die Losung dafur ist Prozessoraffinitat. Unter diesem Begriff versteckt sich ein Mecha-nismus, mit dem das Betriebssystem fur jeden Thread im System einen bestimmten CPU-Core fur seine Ausfuhrung zuweisen kann. Damit lassen es sich Prozesse, die auf gleicheDaten im RAM zugreifen, moglichst auf dem gleichen CPU-Core auszufuhren.

CPU: Einfluss auf Capturing

Weil das Capturing mit Hilfe von mehreren Prozessen (ISR, BPF, Libpcap-Anwendungen,etc. . . ) ausgefuhrt wird und auch gemeinsam benutzte Datenstrukturen beansprucht, solldie Verteilung von diesen Prozessen auf unterschiedlichen CPU’s so sein, dass die Zeitfur die Interprozesskommunikation die gesamte Performance mit wachsender Anzahl vonProzessoren nicht verschlechtert.

Im aktuellen FreeBSD-7.2 ist einen neuen Scheduler ULE [29] per Default gesetzt, derzusammen mit dem Programm cpuset [30] vielfaltige Funktionen zum Einstellen der Pro-zessoraffinitat zur Verfugung stellt und erlaubt, fur die Threads-Gruppen eine bestimmteCPU zu zuweisen.

2.2 Softwareaspekte bei Capturing

In diesem Abschnitt wird der Entwurf des Packet-Capturing-Stack im aktuellen FreeBSD-7.x und der konkurierenden Entwurf “Zero-Copy BPF Buffers” vorgestellt. In FreeBSDbesteht der Capturing-Stack aus mehreren Komponenten. Das sind der Adapter-Treiber,die Software fur die Paketfilterung (BPF), und die User-Anwendungen, die ggf. Libpcap-Funktionen fur den Zugriff auf empfangene Pakete benutzen (siehe Abbildung 6). Wirwerden in folgenden Abschnitten die Hauptkonzepte der genannten Komponenten kennen-lernen, und versuchen, herauszufinden wo die “Engstellen” fur die Capturing-Performancebei ihnen auftreten konnen.

Die Funktion des FreeBSD-Packet-Capture-Stacks ist in einigen Papers [23, 32] und Ma-nuals [25] ausfuhrlich beschrieben. Deshalb enthalt der weitere Text nur eine einfuhrendeBeschreibung des Themas. Eingehend werden lediglich die Aspekte betrachtet, die furAnalyse und Verbesserung der Performance des aktuellen Capturing-Stack relevant sind.

15

Adapte r

Kern

Hardware

Userspace

uiomove( )

Adapter -Speicher

Paket-Puffer

User-Puffer

STORE-HOLD

bcopy( )

Funktionsaufrufe Datentransfer

Adapter -

Treiber

Paket f i l terung

ISR

Kernel-Thread

Netzwerkstack

BPF

Libpcap-

Funkt ionen

Userspace-

Anwendungen

DMA Transfer

Systemauf ru fe

Abbildung 6: FreeBSD Packet Capturing Stack

Zu beachten, dass die in den folgenden Abschnitten betrachteten Software-Aspekte sichvollkommen auf die im aktuellen FreeBSD-7.x vorhandene Software beziehen. Es handeltsich vor allem um den em-Treiber, den Berkley-Packet-Filter und die Libpcap-Library.

2.2.1 Packet Capturing in FreeBSD

Die erste Komponente des Packet-Capturing Stacks (siehe Abbildung 6) ist der Adapter-Treiber. Nachdem ein Paket vom Adapter in den Paket-Puffer im RAM kopiert wurde,meldet der Adapter die Anwesenheit von neuen Daten im RAM durch ein Interrupt, undverursacht damit den Aufruf der Interrupt-Service-Routine (ISR) des Adapter-Treibers.Die ISR stellt die Ursache des Interrupts fest und plant zu einem spateren Zeitpunkt dieAusfuhrung eines Kernel-Threads, dessen Aufgabe ist es, die Datenintegritat der emp-fangenen Pakete zu prufen und die Pakete den Funktionen des Protokoll-Stacks und desBerkley Packet Filters zu ubergeben.

Eine weitere Komponente des Capturing-Stacks ist der Berkley Paket Filter (BPF) [23, 9],eine Software, die die Funktionalitat zur Paketfilterung enthalt. Die BPF-Funktionen wer-den anhand der vorhandenen Filter-Regeln fur jedes Paket ausgefuhrt, um zu entscheiden,ob das Paket geloscht oder weiter durch den Capturing-Stack geleitet wird. Außerdementhalt die BPF-Implementierung die Systemaufrufe, die es dem Userspace-Prozess erlau-ben, auf die Pakete zu zugreifen und die Paketfilterung zu steuern.

Der Userspace-Prozess greift auf die gefilterten Pakete mit dem read-Systemaufruf zu.Die Pakete konnen aber sowohl, direkt, mit dem Systemaufruf als auch (indirekt) durch

16

In ter ruptsursache-Herausf inden

Ausschlaten Adapter - In terrupts

Planen Kernel -Thread

ISR (star t )

Kernel-Thread

ISR

Abbildung 7: Adapter-Treiber: Interrupt Service Routine

den Aufruf von Libpcap-Funktionen in den Userspace geholt werden3. Wenn der Userspace-Prozess die Pakete in seinem virtuellen Speicherraum hat, erledigt er die restliche Bear-beitung der empfangenen Daten.

Im Folgenden betrachten wir die einzelne Komponenten des FreeBSD- Packet-Capturing-Stack etwas genauer. Angefangen wird mit der Interruptbehandlung.

2.2.2 Interruptbehandlung

Wahrend der Ausfuhrung der Interrupt Service Routine (ISR) sind die Interrupts vomAdapter deaktiviert. Daruberhinaus sind alle derzeit laufenden Prozesse auf der aktuellenCPU4 unterbrochen. Dies kann das Capturing negativ beeinflussen, wenn es mit Hilfe vonmehreren Prozessen realisiert wird. Solange das Capturing-System sich mit der Interrupt-Behandlung beschaftigt, kann es aufgrund der Interrupts-Sperre, maximal, nur so vielePakete empfangen, wie es noch Platz auf dem Adapter-Speicher und im RAM gibt undnur wenn fur deren Speicherung keine Unterbrechung der aktuellen CPU benotigt wird.Die Kapazitat dieser Speicher-Elemente ist begrenzt. Deshalb ist es fur die Vermeidungvon Paketverlusten sehr wichtig, dass die ISR effizient implementiert ist und dadurch einemoglichst kurze Ausfuhrungszeit hat.

Trennung des Interrupt-Handlers in zwei Teile: ISR und Kernel-Thread

Da es nicht immer moglich ist, die Ausfuhrungszeit einer ISR zu minimieren, kann man inFreeBSD den Interrupthandler in zwei Teile trennen [26]. Der erste Teil ist die eigentlicheISR5, deren Ausfuhrung das Sperren aller anderen Aktivitaten auf der aktuellen CPU ver-ursacht. Der andere Teil ist ein Kernel-Thread6, dessen Ausfuhrung mit etwas niedrigererPrioritat zu einem spateren Zeitpunkt stattfindet (siehe Abbildung 7).

Die ISR des em-Treibers hat lediglich die Aufgabe durch das Lesen des Interrupt-Cause-Registers (ICR) [20] die Interrupt-Ursache herauszufinden, die Interrupts des Adaptersauszuschalten und die Ausfuhrung eines Kernel-Threads fur die weitere Paketbearbeitungzu planen(siehe Abbildung 7).

3Libpcap ist eine freie Bibliothek, die eine Sammlung von Funktionen zum bequemen Zugriff auf dievom Netzwerk empfangene Pakete anbietet.

4gemeint ist die CPU, die gerade die ISR des Adapters ausfuhrt.5Wird auch oft in der Literatur als Fast Interrupt handler oder top-half of interrupt genannt [14].6wird auch als NON-Fast Interrupt handler oder down-half of interrupt genannt [14].

17

Die Aufgabe des Kernel-Threads ist es, die neue durch DMA in die Paket-Puffer geschrie-ben Pakete zu lesen, diese auf Fehler zu prufen, in mbuf-Strukturen [35, 26] einzupackenund dem Protokoll-Stack und BPF zu ubergeben (siehe Abbildung 8). Der Kernel-Threadbearbeitet maximal eine bestimmte Anzahl von Paket-Puffern. Dieser Wert kann ubersysctl-Befehl folgender massen gesetzt werden:

# sysctl dev.em.0.rx_processing_limit 100 (4)

Wenn es nach dem Interrupt mehr als rx_processing_limit neue Paket-Puffer im RAMgibt, wird Kernel-Thread mehrmals geplant. Wahrend des ersten Ablaufs des Threads sinddie Interrupts des Adapter noch gesperrt. Nach seinem Ablauf entsperrt der Kernel-Threaddie Adapter-Interrupts, sodass die restlichen Thread-Ablaufe mit erlaubten Interruptsstattfinden und jeder Zeit von neuen Adapter-Interrupts unterbrochen werden konnen.Der Grund des Sperrens der Interrupts nur fur den ersten Thread-Ablauf ist nirgendwobeschrieben. Ich vermute, dass es fur dieses Vorgehen folgende Erklarungen gibt:

• Wenn die Interrupts fur alle Thread-Ablaufe gesperrt waren, konnte dann zu langeInter-Interrupt-Verzogerung entstehen was, den Paketverlusten fuhren wurde.

• Hatte man vor begin der ersten Thread-Ablauf die Interrupts entsperrt, dann konntebei einer zu hohen Interrupt-Rate dazu kommen, dass der Thread standig durch neueInterrupts unterbrochen wurde und dadurch nie seine Arbeit erledigt hatte.

Die Arbeit, die der Kernel-Thread pro Puffer erledigt besteht aus (siehe auch Abbildung8):

1. Allozieren des neuen Paket-Puffer fur den aktuellen Deskriptor

2. Fehlerprufung des Paketes im alten Paket-Puffer

3. Einpacken des Paketes in mbuf-Struktur

4. Ubergeben des Paketes an den Protokoll-Stack

5. Ubergeben des Paketes an den BPF

6. Inkrementieren des Wertes in RDT-Register:

RDT = (RDT + 1) mod SIZE (5)

SIZE - Anzahl von Deskriptoren.

Interruptbehandlung: Einfluss auf Capturing

Die großte Rechenaufwand bei der Interruptbehandlung findet wahrend der Ausfuhrungdes Kernel-Thread statt. Die ISR dient nur zum Herausfinden der Ursache des Interrupts,und enthalt dadurch keine Funktionalitat, die optimiert werden kann.

Von allen Aufgaben, die der Kernel-Thread erledigt, sind die Speicher-Allozierungen,wahrscheinlich, diejenigen die den Großteil der CPU-Zeit beanspruchen. Wahrend desCapturing-Ablaufs alloziert der Kernel-Thread fur jeden fur einen DMA-Transfer benutz-ten Deskriptor einen neuen Paket-Puffer (siehe Abschnitt 2.2.2).

18

ISR

count = rx_processing_l imit

Kernel -Thread (star t )

count = count - 1

Fehlerprüfung für Paket [RDT + 1 ]

Kopieren das Paket [RDT + 1 ]

in Protokol-Stack

Kopieren das Paket [RDT + 1 ]

in Captur ingl -StackBPF

Allozieren des neuen Paket-Puffer

fü r Deskr ip tor [RDT+1]

count = 0

NO

YES

Einschlaten NIC- Interrupts STOP

RDT = RDT + 1

1

2

das Paket [RDT + 1 ]

in mbuf -St ruktur e inpaken3

4

6

5

7

Abbildung 8: Adapter-Treiber: Kernel-Thread

19

Durch das Allozieren des neuen Puffer fur den Deskriptor werden die Pakete vor derUberschreibung durch die neue empfangene Daten gerettet. Dies hat aber auch einenNachteil, der sich in Vergroßerung des pro-Paket-Puffer-Overhead zeigt. Die Paket-Puffer-Allozierung kann man eigentlich beseitigen. Wenn in der Initialisierung-Phase des Treiberseine große Anzahl an Paket-Puffer alloziert wird, konnten dann diese pre-allozierten Paket-Puffer im Lauf des Capturing, der Reihe nach mehrmals wiederholt benutzt werden.

2.2.3 Berkley Packet Filter

Der BPF [9] ist die zweite Komponente des FreeBSD Packet-Capturing-Stacks. Seine Auf-gaben sind unter anderem:

• Transfer und Empfang von Paketen

• Paketfilterung

• Ermoglichen des Zugriffes von Userspace-Prozessen auf die gefilterten Pakete

Der BPF registriert im System fur jeden Prozess, der die Pakete erfassen will ein sym-bolisches Device: /dev/bpf[0-9], und bietet dazu eine Menge von Systemaufrufen (read,ioctl, etc. . . ) fur den Zugriff auf die Pakete und zur Steuerung der Paketfilterung. Au-ßerdem stellt BPF eine Menge von Kernel-Funktionen zur Verfugung, die aus dem Trei-ber aufgerufen werden und die eigentliche Filterung und Weiterleitung des Paketes durchCapturing-Stack zum User-Prozess ausfuhren [24].

Die Pakete werden vom BPF gefiltert, und diejenigen, die durch die Filterregeln akzep-tiert wurden, werden in den STORE-HOLD-Puffer kopiert (siehe Abbildung 6). Aus demSTORE-HOLD-Puffer werden die Pakete durch den read-Systemaufruf in Userspace ko-piert7.

BPF: Einfluss auf Capturing

Den pro-Paket-Overhead bei der Ausfuhrung der BPF-Routinen kann man in zwei logischeFunktionen unterteilen:

• Paket-Filterung

• Kopieren des akzeptierten Paketes in LOAD-STORE-Puffer

Der BPF wird auf dem aktuellen FreeBSD vollkommen in Kernelspace ausgefuhrt. Es gibtaber auch in der Libpcap-Library eine BPF-Implementierung, was zur Folge hat, dass diePaketfilterung, eigentlich nicht nur im Kernelspace sondern auch im Userspace ausgefuhrtwerden kann. Aber das Ausfuhren von Filterung-Routinen im Kern, sofort nach dem Pake-tempfang, hat seine Vorteile. Die Kopier-Operationen haben mit dem Unterschied zu denanderen CPU-Operationen wesentlich langere Ausfuhrungszeiten. Deshalb eliminiert dasmoglichst fruhe Ausfuhren der Filterung das unnotiges Kopieren von Daten, die anhandder vorhandenen Filterregeln nicht akzeptiert wurden.

Die “teuren” Kopier-Operationen lassen sich durch Memory-Mapping eliminieren. Durchdas Einblenden eines Speichersegments in die Adressraume unterschiedlicher Prozesse,lasst sich die Inter-Prozesskommunikation ohne Kopier-Operationen umsetzen. Auf dieserIdee basiert der konkurierende FreeBSD-Capturing-Stack, der aus dem Projekt “Zero-Copy BPF Buffers” entstanden ist (sieh Abschnitt 2.3).

7Die genaue Beschreibung ist in bpf(9) Manual [24] und in den Papers von Fabian Schneider [32, 34] zufinden.

20

2.2.4 Libpcap

Libpcap ist eine Programm-Bibliothek, die eine Menge von Funktionen zum bequemenZugriff auf empfangene Pakete anbietet [21]. Mehrere bekannte Sniffer wie tcpdump oderEthereal benutzen fur erledigen ihrer Aufgaben die Libpcap. Auf FreeBSD benutzen dieLibpcap-Funktionen selber BPF-Systemaufrufe fur die Paketfilterung und fur Zugriff aufgefilterte Pakete, und stellen den User-Anwendungen eine bequeme und einfache Schnitt-stelle fur Capturing.

Uber Libpcap gibt es zahlreiche Manuals und Dokumentationen [21]. Deshalb folgt hiernur eine kurze Beschreibung der Libpcap-Funktionen, die dem User-Prozess den Zugriffauf die gefilterten Pakete ermoglichen:

pcap next() wird benutzt, um einen Zeiger auf den Puffer mit dem nachsten erfasstenPaket zu bekommen.

pcap dispatch() ruft die pcap bpf read() auf.

pcap read bpf() kopiert durch den read-Systemaufruf auf dem bpf-Device den ganzenHOLD-Pufer in den Userspace. Infolge des read-Systemaufrufes wird die uiomove-Kernel-Funktion, welche die Daten aus dem HOLD-Puffer in Userspace kopiert, aus-gefuhrt (siehe Abbildung 6).

In der User-Anwendung kann eine callback -Funktion Implementiert werden. Der Zeiger aufdiese Funktion wird an pcap loop() und pcap dispatch() als Argument ubergeben. Dannwird diese callback-Funktion fur jedes empfangene Paket mit dem Zeiger auf den Anfangdes Paketes aufgerufen. So bekommt ein User-Prozess den Zugriff auf die erfasste Pakete.

Libpcap: Einfluss auf Capturing

Die User-Anwendung holt die erfassten Pakete mit dem read-Systemaufruf auf dem bpf -Device. Der pro-Systemaufruf-Overhead entsteht dabei aus:

• Kontext-Wechsel zwischen Kernelspace und Userspace.

• Puffer-Kopieren.

Die Pakete werden nicht einzeln geholt sondern, der ganzen HOLD-Block wird durch denread()-Aufruf in den Userspace kopiert (siehe Abbildung 6). Dies hat den Vorteil, dassder Kontext-Wechsel und die Kopier-Operation nicht fur jedes einzelne Paket, sondern furganze Paketbundel ausgefuhrt werden. Trotzdem reduziert dieser Systemaufruf-Overheaddie Capturing-Performance dadurch, dass er die Rechenresourcen fur sich in Anspruchnimmt. Um dieser Overhead zu reduzieren, mussen die Systemaufrufe moglichst seltenerauftreten. Dies kann man durch Vergroßerung des HOLD-Puffer erreichen.

Laut [33, 34] betragt die optimale HOLD-Puffer-Große bei konventioneller Hardware etwa10MByte. Die Vergroßerung des Puffers uber diesen Wert, bringt keine weitere Verbesse-rung der Capturing-Performance.

Der im Abschnitt 2.3 vorgestellte “Zero-Copy BPF Buffers”-Projekt hat das Ziel, denmit den Kontext-Wechsel und Kopie-Operationen verbundenen Overhead zu beseitigen.

21

Adapte r

Kern

Hardware

Userspace

Adapter -Speicher

Paket-Puffer

bcopy( )


Adapter -

Treiber

Paket f i l terung

ISR

Kernel-Thread

Netzwerkstack

BPF

Libpcap-

Funkt ionen

Userspace-

Anwendungen

DMA Transfer

STORE-HOLD

STORE-HOLD

Abbildung 9: Zero-Copy BPF Buffers

2.3 Zero-Copy BPF Buffers

Im Rahmen des “Zero-Copy BPF Buffers”-Projektes wurde ein neuer Capturing-Stackfur das Betriebssystem FreeBSD entworfen und implementiert [3]. Im diesem Stack wirddas Kopieren der Daten aus dem STORE-HOLD-Puffer in den Userspace, durch Memory-Mapping eliminiert (siehe Abbildung 9). Dies hat zwei Vorteile: Erstens, werden keineKopier-Operationen mehr gebraucht. Zweitens, wird dadurch der read-Systemaufruf sel-ber nicht mehr gebraucht, was auch den Kontext-Wechsel spart und damit die Zugriffszeitauf die Daten beschleunigt.

Das Benutzen von Memory-Mapped-Buffers erfordert allerdings ein neues Konzept fur denZugriff auf Daten. Deshalb wurden im Rahmen des Projektes auch die Libpcap-Funktionenfur den Zugriff auf Pakete im Shared-Buffer angepasst. Damit sind fur Capturing-Anwendungen,die auf Libpcap basieren, keine Anderungen erforderlich.

2.4 Capturing-Analyse und Anforderungen

Einer der Ziele der Diplomarbeit liegt in der Verbesserung der fur das Capturing rele-vanten Software-Komponenten des Betriebssystem FreeBSD. Unter Verbesserung verste-hen wir die Erhohung des Datendurchsatzes beim Paket-Capturing (siehe Kapitel Einlei-tung). In den vorherigen Abschnitten wurden die fur Capturing-Performance relevantenHardware- und Software-Eigenschaften dargestellt. Dabei wurde versucht herauszufinden,welche der vorgestellten Komponenten unter welchen Umstanden die Performance desCapturing negativ beeinflussen konnen. In diesem Abschnitt wird anhand der herausge-

22

fundenen Capturing-Performance-Problemen die konkrete Anforderungen an den prakti-schen Teil der Diplomarbeit gestellt.

Die Hardware-Komponenten eines Capturing-Systems stellen die hochste theoretische Gren-ze fur die Capturing-Performance dar. Wir haben aber gesehen, dass in der Realitat diePerformance bei der Datenbearbeitung wesentlich schlechter als die theoretischen Wertesein kann. Das kann man z.B. besonders gut beim Vergleich der theoretischen [11] undeffektiven [7] Speicher-Bandbreiten sehen. Einer der Grunden dafur ist es, das die Softwareineffizient die zur Verfugung stehenden Hardware-Ressourcen nutzt.

Aufgrund der Unmoglichkeit der Verbesserung von Hardware-Komponenten im Rahmeneiner Diplomarbeit und einer relativen Einfachheit der Software-Losungen hat sich fur denpraktischen Teil der Diplomarbeit die Softwarebasierende Losung entwickelt. Wir wolleneinen neuen Paket-Capturing-Stack implementieren, in dem moglichst alle in dem aktuel-len Stack gefundene Performance-Probleme eliminiert werden.

For allem handelt es sich um die Eliminierung der Kopie-Operationen und Beseitigungdes Systemaufrufes fur den Datenzugriff, denn genau diese Funktionen sind es, die imVergleich zu den anderen Funktionen, eine relativ große Ausfuhrungszeit anfordern. Daskann mit dem Memory-Mapping gemacht werden. Dafur muss aber einen Konzept fur denZugriff auf Daten, die im “gemappten” Puffer liegen, erarbeitet werden.

2.4.1 Capturing-Stack-Analyse

Betrachten wir noch mal in Abbildung 6 dargestellten Capturing-Stack des aktuellenFreeBSD. Stellen wir uns den Fall vor wenn alle Pakete durch die BPF-Filterung ak-zeptiert wurden. Dann haben wir pro Paket drei Kopie-Operationen:

1. DMA Transfer in den RAM

• wird mit Hilfe der Hardware erledigt

2. Kopieren in STORE-HOLD-Puffer

• wird mit Hilfe der Kernelfunktion bcopy(9) gemacht.

3. Kopieren in Userspace (mit dem Kontextwechsel)

• wird durch den Systemaufruf mit der Ausfuhrung von uiomove(9) gemacht.

Das Eliminieren der dritten Kopie-Operation und Beseitigen des Systemaufrufes war dasZiel des BPF Zero-Copy Buffer - Projektes (siehe Abschnitt 2.3). Wir wollen aber nochweiter gehen und den Capturing-Stack auch von den restlichen Engpassen.

Die erste Kopier-Operation, die durch DMA-Transfer des Paketes in den RAM erledigtwird, ist unvermeidlich. Wenn wir die restlichen beiden Kopien des Paketes durch dasMemory-mapping vermeiden wollen, dann mussen die Paket-Puffer in den Adressraumeines User-Processes eingeblendet werden (siehe Abbildung 10), was auch die Ausfuhrungvon BPF im Kernel unpraktisch macht. Die fruhere Ausfuhrung der Paket-Filterung imKern ist in dem Fall vorteilhaft, wenn danach die “teuren” Kopie-Operationen und Kon-textwechsel folgen. In dem Fall werden lediglich die Daten Kopiert die durch Filterungakzeptiert wurden.

23

Wenn wir aber die Paket-Puffer in Userspace einblenden, dann hat der User-Prozess diePakete in seinem virtuellen Speicherraum sofort nach dem DMA-Transfer des Paketes oh-ne jeglicher Aufwand. Und dann kann der User-Prozess selber entscheiden ob und wannund wie er die Pakete filtert. Da der BPF auch in Libpcap implementiert ist, sollte furUser-Prozess die Paket-Filterung kein großes Problem sein.

Durch das Einblenden der Paket-Puffer in Userspace wird auch das standige Allozierender neuen Paket-Puffer fur die “gebrauchten” Deskriptoren (siehe Abschnitt 2.2.2) imKernel-Thread ineffektiv und unpraktisch, denn diese neu allozierten Puffer mussen auchstandig in den Userspace eingeblendet werden, was einen zusatzlichen Overhead fur jedeBearbeitung eines Puffers verursacht. Um den genannten Overhead zu minimieren, wollenwir die Paket-Puffer ein Mal bei der Treiber-Initialisierung allozieren und fur die ganzeCapturing-Zeit nur diese Puffer der Reihe nach benutzen. Dies impliziert aber, dass beimwiederholten Benutzen des Deskriptors die in dem vom Deskriptor referenzierten Paket-Puffer vorhandene alte Daten komplett uberschrieben werden. Die Daten werden aber imPaket-Puffer solange vor der Uberschreibung gerettet, bis der Software-Prozess den Wertim RDT-Register (TAIL-Pointer) entsprechend erhoht hat (siehe Abschnitt 2.1.1). Wennaber die Userspace-Anwendung die Daten fur die langere Zeit braucht, sollte sie die Datenaus dem Paket-Puffer durch Kopieren in einen anderen Speicherbereich retten.

2.4.2 Anforderungen

1. Alle Paket-Kopie-Operationen im Capturing-Stack sollen eliminiert werden (Abbil-dung 10)

• Die Pakete sollen sofort nach dem DMA-Transfer im virtuellen Adressraum desUser-Capturing-Prozesses zugreifbar sein.

2. Keine Speicherallozierungen fur die neue Paket-Puffer wahrend des Capturing

• Alle Paket-Puffer sollen bei der Initialisierung des Treiber alloziert werden undfur die ganze Laufzeit des Treibers fur Empfang der neuen Pakete der Reihenach benutzt werden.

3. Keine Systemaufrufe fur den Datenzugriff und Paketbearbeitung wahrend des Cap-turing

• Dafur mussen außer den Paket-Puffern noch andere Datenstrukturen mit denfur das Capturing relevanten Daten in den Userspace eingeblendet werden, da-mit der Userspace-Prozess ohne Systemaufrufe die Daten vom Treiber bekommtund auch Informationen an den Treiber liefern und damit das Capturing steuernkann.

• Systemaufrufe sind nur wahrend der Initialisierung des Capturing-Prozessesund wahrend der Abwesenheit von neuen Paketen fur das Blockieren des aufdie Pakete wartenden Prozesses erlaubt.

4. Eine Userspace-Capturing-Anwendung pro Netzwerk-Interface

• Wir begrenzen uns auf eine gleichzeitig aktive Userspace-Capturing-Anwendungpro Interface, um den Entwurf und die Implementierung einfach zu halten.

5. Protokoll-Stack ausschalten

• Wir wollen den neuen Treiber nur fur Capturing benutzen

24

6. BPF aus dem Kernel entfernen.

• Der BPF ist auch in der Libpcap implementiert. Das hat zur Folge, dass es keinProblem ware, die Paketfilterung im Userspace anzuwenden.

Da der neue Stack anders als der Standard-FreeBSD-Capturing-Stack die empfangene Pa-kete den Userspace-Prozessen zur Verfugung stellt, mussen die Userspace-Prozesse andersauf die Pakete zugreifen. Um der neue Stack einsetzbar zu machen soll am besten dieLibpcap-Library fur ihn angepasst werden, sodass fur alle Capturing-Anwendungen, dieauf Libpcap basieren, keine Anderungen benotigt werden.

2.4.3 Namenskonventionen

Um die Unverstandlichkeiten mit den Bezeichnungen zu vermeiden, geben wir hier dieNamen, unter denen die standard FreeBSD-Capturing-Stack und der neuen im Rahmender Diplomarbeit entwickelten Capturing-Stack in den Weiteren Abschnitten auftauchenwerden:

ringmap : Wird als Bezeichnung fur die im Rahmen der Diplomarbeit entwickelte Capturing-Software benutzt. Zum Beispiel:

• ringmap-Adapter-Treiber: Der neue Treiber, der im Rahmen der Diplomar-beit fur den Intel Gigabit Adapter entworfen und implementiert wurde.

• ringmap-Capturing-Stack: Bezeichnet die alle im Rahmen der Diplomarbeitentworfenen und implementierten Software-Funktionen, die fur Capturing benotigtwerden.

generic : Wird als Bezeichnung fur die FreeBSD-7.x-Standard- Capturing-Software be-nutzt:

• generic-Treiber: em-Treiber fur den Intel Gigabit Adapter.

• generic-Capturing-Stack: em-Treiber, BPF, Libpcap

2.5 Zusammenfassung

In diesem Kapitel wurden die fur das Verstandnis der Capturing-Problematik relevantenHintergrunde dargestellt. Es wurden sowohl die Software- als auch die Hardware-Aspekte,welche die Capturing-Performance beeinflussen konnen, betrachtet und analysiert. DieHardware-Eigenschaften eines Capturing-System sind deshalb wichtig, weil fur die Diplom-arbeit eine konkrete Hardware vorausgesetzt wurde (siehe Abschnitt 1.1.2), und die Pro-blemlosung fur das Erreichen der maximalen Capturing-Performance Hardware-Abhangigsein durfte.

Außerdem es wurden einige Hardware-Eigenschaften erlautert die zwar keinen Einflussauf die Implementierung des neuen Paket-Capturing-Stack haben, aber vom Benutzer desBetriebssystem geandert werden konnen und dadurch die Capturing-Performance beein-flussen. Es handelt sich dabei um Interrupt-Coalescing (Abschnitt 2.1.1) und Prozessoraf-finitat (Abschnitt 2.1.4). Die Notwendigkeit diese Eigenschaften zu kennen liegt darin, dasssie unabhangig von Effizienz der Implementierung der Capturing-Software die Capturing-Performance beeinflussen und dadurch bei ungunstigen Einstellungen reduzieren konnen.

Beim Betrachten der unterschiedlichen Hardware- und Software-Komponenten wurde auch

25

Adapte r

Kern

Hardware

Userspace

Adapter -Speicher

Paket-Puffer


Adapter -

Treiber

ISR

Kernel-Thread

Libpacp-

BPF

Libpcap-

Funkt ionen

Userspace-

Anwendungen

DMA Transfer

Paket-Puffer

Abbildung 10: Der neue ringmap-Capturing-Stack. Ziel der Diplomarbeit

analysiert unter welchen Umstanden Engstellen beim Capturing auftreten konnen, und an-hand der herausgestellten Problemen wurden die Anforderungen fur den praktischen Teilder Diplomarbeit definiert (Abschnitt 2.4).

Das Ziel des praktischen Teiles der Diplomarbeit ist die Implementierung eines neuenCapturing-Stacks fur das Betriebssystem FreeBSD. Dafur soll eine neue Software imple-mentiert werden, deren Aufgaben es ist, die gefundenen Engstellen, die bei der Bearbeitungder im RAM liegenden Pakete entstehen konnen, zu beseitigen. Es handelt sich vor allemum die Kopier-Operationen und die Systemaufrufe, die bei Paket-Filterung oder beimPaket-Zugriff verwendet werden.

Die Capturing-Performance-Probleme die wahrend der Speicherung der Pakete auf dieFestplatte und der Darstellung der Pakete auf dem Terminal auftreten konnen wurdennicht Betrachtet und sind nicht Gegenstand dieser Arbeit.

26

3 Entwurf

In diesem Kapitel werden die Datenstrukturen und Algorithmen des neuen im Rahmen derDiplomarbeit entwickelten ringmap-Packet-Capturing-Stack fur Betriebssystem FreeBSDdargestellt. Das Ziel des Entwurfes war einen neuen Capturing-Stack mit verbesserterPerformance zu erarbeiten. Dafur wurden durch Analyse im Kapitel 2.4 die Probleme desaktuellen generic-Capturing-Stack herausgestellt. Anhand der gefundenen Probleme wur-den die Anforderungen fur den neuen ringmap-Stack, mit dem Ziel den Datendurchstzbeim Capturing zu erhohen, erstellt.

3.1 Datenstrukturen

Die im ringmap-Capturing-Stack verwendete Daten-Strukturen dienen zur Modellierungaller fur Paketempfang verantwortlichen Paket-Puffer in Form eines Ringpuffers. Die Grundefur die Auswahl der Ringpuffer-Struktur sind in folgenden Abschnitten dargestellt. DerStacks sind fur die Paketzustellung und den Paketzugriff im Ringpuffer und auch fur dieSteuerung des Capturing-Prozesses zustandig.

3.1.1 Verwendungszwecke fur Ringpuffer

Die Ringpuffer-Daten-Struktur wird bevorzugt wenn es um den Datenzugriff in einemArray oder einer Liste handelt, bei der die Elementenanzahl konstant bleiben soll undneue Speicherallozierungen unerwunscht waren. Daruberhinaus werden Ringpuffer fur dieLosung einiger klassischen Problemen, z.B. Erzeuger-Verbraucher-Problem [10], empfoh-len [15].

3.1.2 Grunde fur die Ringpuffer-Struktur im ringmap-Capturing-Stack

Die Grunde fur die Auswahl der Ringpuffer-Struktur fur den Paket-Capturing basieren vorallem auf den im Kapitel 2.4 fur den ringmap-Capturing-Stack gestellten Anforderungen(Anforderungen 1. und 2.). Außerdem spielen fur die Auswahl der Ringstruktur auch dieandere folgende Faktoren und die Hardware-Eigenschaften eine wichtige Role:

• Der Capturing-Prozess ist dem Erzeuger-Verbraucher-Modell [10] ahnlich:

– Es gibt ein “Datenerzeuger”: der Netzwerkadapter-Treiber, der die Pakete inden Ringpuffer fur folgende Bearbeitung bzw. Filterung vorbereitet.

– Es gibt ein “Datenverbraucher”: die User-Anwendung, die auf die in den Paket-Puffer befindlichen Pakete zugreift, sie bearbeitet, speichert oder darstellt.

• Der Netzwerkadapter verwaltet die Deskriptoren als ein Ringpuffer (siehe Abschnitt2.1.1). Der Netzwerkadapter enthalt die RDT- und RDH-Register, welche die Role derHEAD und TAIL-Pointers im Deskriptor-Ringpuffer speilen und dadurch, dass jederDeskriptor einen Paket-Puffer referenziert, konnen diese Register auch als HEADund TAIL fur den Paket-Puffer-Array nutzlich sein.

3.1.3 Memory-mapped Paket-Ringpuffer fur ringmap-Capturing-Stack

Alle Paket-Puffer werden in den Adressraum eines Capturing-Prozesses eingeblendet, da-mit der Capturing-Prozess ohne Kopie-Operationen und ohne Systemaufruf auf die Pa-kete zugreifen kann. Mit jedem Paket-Puffer werden zwei weitere Daten-Strukturen in

27

RING

+HEAD

+TAIL

+SIZE

RING_SLOT

+TIME_STAMP

+SLOT_COUNTER

ADDRESS

+KERN_ADDR

+USER_ADDR

+PHYS_ADDR

SIZE1 11

1

1

1

1

PAKET

MBUF

DESKRIPTOR

Abbildung 11: Datenstrukturen des Ringpuffer

den Userspace eingeblendet. Das sind mbuf [25] und Deskriptor. Diese Strukturen werdenim Userspace deshalb gebraucht, weil sie die fur Paketbearbeitung und Paketfilterung re-levante Informationen enthalten. Auf diese obengenannten Datenstrukturen wird sowohlvom Kernelspace als auch vom Userspace zugegriffen. Um dies zu ermoglichen werden dreiandere Datenstrukturen zur Adressierung vorgesehen, welche sowohl die Kernelspace- alsauch die Userspace-Adressen von den Paket-Puffer, mbuf’s und Deskriptoren enthalten.Das sind: PAKET, MBUF und DESKRIPTOR (siehe Abbildung 11).

Jedes Paket im RAM wird durch den Tripel [PAKET, MBUF, DESKRIPTOR] reprasentiert.Jedes Tripel wird in einer Datenstruktur RING_SLOT gekapselt. Und die Instanzen vonRING_SLOT bilden ein Array, der in der RING-Struktur enthalten ist. Die RING_SLOT-Struktur enthalt unter anderem die Platzhalter fur Timestamp und Counter vom re-prasentierten Paket.

RING-Struktur enthalt den Array von RING_SLOT-Instanzen und die HEAD- und TAIL-Pointers, welche die HEAD- und TAIL-Slots im RING_SLOT-Array referenzieren. Damitbildet RING eine Datenstruktur die es erlaubt, alle Paket-Puffer als ein Ringpuffer zubetreiben.

Die RING-Struktur wird mit den Paket-Puffer in den Adressraum eines Userspace-Capturing-Prozesses eingeblendet, und erlaubt ihm den Zugriff auf alle Paket-Puffer und das Betrei-ben aller Paket-Puffer als ein Ringpuffer.

28

3.2 Funktionalitat

Der neue Capturing-Stack enthalt die folgende Funktionalitaten:

• Paketzustellung:

– Zustellung der Pakete in den Ringpuffer wird mit Hilfe des Netzwerkadapter-Treibers realisiert.

• Paketzugriff :

– Zugriff auf die im Ringpuffer befindlichen Pakete wird beim Userspace-Capturing-Prozesses gemacht.

• Systemaufrufe fur:

– Memory-Mapping.

– Capturing-Steuerung: Capturing-Anhalten und -Fortsetzen.

– Blockierendes Warten auf neue Pakete.

Aufgrund der Anforderung 4. (siehe Kapitel 2.4), darf in einem Capturing-Stack nur einPaketzugriff-Prozess sein. Weil es nur einen Zustellung-Prozess (den Treiber) und nur einenPaketzugriff-Prozess gibt, werden keine race conditions beim Zugriff auf Paket-Puffer auf-treten, und dadurch werden keine Synchronisation-Maßnahmen benotigt [15].

Nach der Anforderung 3. durfen wahrend des Ablaufs des Capturing keine Systemaufrufeauftreten. Gemeint sind die Systemaufrufe die fur den Zugriff auf empfangene Pakete ge-braucht waren. Durch Memory-Mapping werden die Systemaufrufe fur den Paketzugriffeliminiert. Es gibt aber die Systemaufrufe die nicht zu beseitigen sind. Das sind die, welchefur die Realisierung vom Memory-Mapping selbst benotigt werden. Außerdem wurdenauch die Systemaufrufe fur die Capturing-Steuerung und blockierendes Warten aufneue Pakete implementiert. Theoretisch konnte man die Capturing-Steuerung durchdie Interaktion mit dem Kernelspace uber die eingeblendete Speicherbereiche realisieren.Das blockierende Warten ist auch nicht die einzige Losung, wenn der Userspace-Prozessauf die neue Pakete warten soll. Er kann ja auch aktiv, in einer Schleife, warten. Das Ver-meiden von Systemaufrufen fur die zwei obengenannten Probleme (Capturing-Steuerungund blockierendes Warten) ist zwar losbar, hat aber einen zusatzlichen Aufwand und stelltden Performance-Gewinn unter die Frage:

• Capturing-Steuerung uber Shared-Memory: Wenn der Capturing-Prozess nichtuber den Systemaufruf, sondern uber die Shared-Memory eine Anfrage an Treiberstellt, soll er darauf warten, bis der Treiber-Prozess die CPU fur seinen Ablauf be-kommt. Da die Funktionen des Treibers, die nicht in folge eines Systemaufrufes,sondern in folge eines Interrupts aufgerufen werden, in den unvorhersagbaren Zeit-punkten stattfinden, kann es dazu fuhren, dass der Capturing-Prozess keine sofortigeReaktion vom Treiber nach seiner Anfrage bekommt. Dieses Problem kann mit Hilfeeines Kernel-Watchdog [13] gelost werden, was aber nicht nur einen Implementierung-Aufwand mit sich bringt, sondern auch den Systemload erhoht.

• Das aktive Warten auf die neue Pakete: Das aktive Warten beansprucht kei-nen Systemaufruf dennoch vermeidet das keinen Kontextwechsel-Overhead, denndas Betriebssystem blockiert selber im Lauf des Prozess-Scheduling den laufendenProzess um den anderen Prozessen die CPU zur Verfugung zu stellen. Außerdem re-duziert das Betriebssystem die Prioritat des aktiv wartenden Prozesses wegen seinerstandigen CPU-Nutzung, was die Capturing-Performance negativ beeinflussen kann.

29

Jeder Systemaufruf bringt unvermeidlich mit sich einen Overhead (Kontextwechsel undggf. Daten-Kopieren) mit sich. Wie kritisch dieser Overhead fur Capturing-Performanceist, hangt von der Haufigkeit des Auftretens der Situationen, in denen die Systemaufrufegebraucht werden. Das Memory-Mapping im FreeBSD kann nur mit Hilfe eines System-aufrufes in die Tat gebracht werden, deshalb fur dieses Vorgehen ist der Systemaufruf nichtzu vermeiden. Die Capturing-Steuerung ist eher ein seltenes Ereignis, denn es wird janicht standig gebraucht, softwaremassig den Capturing anzuhalten und fortzusetzen. Des-halb ist die Verwendung der Systemaufrufen fur Capturing-Steuerung eher unkritisch.Wenn es aber um Warten auf neue Pakete geht, dann ist aufgrund der unvorhersagbarenNetz-Verkehr das Auftreten des wartendes Zustandes auch nicht berechenbar ist. Den-noch fur das Warten auf neue Pakete wird in ringmap blockierendes Warten verwendet.In den folgenden Abschnitten werden die Algorithmen der im Capturing-Stack beteiligtenFunktionalitaten dargestellt.

3.2.1 Paketzustellung in den Ringpuffer. Netzwerktreiber

Die Paket-Zustellung in den Ringpuffer wird beim Netzwerkadapter-Treiber erledigt. Dieeigentliche Zustellung macht naturlich der Adapter durch den DMA-Transfer selbst. DerTreiber bereitet nur die in den RAM geschriebene Daten fur die weitere Bearbeitung undden Zugriff auf ihnen. Da aus dem Sicht des Userspace-Prozesses, der auf die empfangenePakete zugreift, die Hardware-Funktionalitat unsichtbar ist, spielt der Treiber die Rolledes Paket-Zusteller.

Die folgende Beschreibung von der Funktionalitat des neuen im Rahmen der Diplom-arbeit implementierten ringmap-Netzwerkadapter-Treiber trennen wir auf zwei logischenTeile. Das sind: Treiber-Initialisierung und Capturing-Ablauf.

Bei Treiber-Initialisierung werden alle fur Capturing benotigte Speicherbereiche (Paket-Puffer, Deskriptoren, etc. . . ) alloziert und initialisiert.

Wahrend des Ablauf von Capturing bestehen die Aufgaben vom Treiber darin, jedenneuen in den RAM geschriebenen Puffer zu “checken”, TAIL- und HEAD-Pointer mitden RDH- und RDT-Register zu synchronisieren und den fur die neue Pakete wartendenUserspace-Capturing-Prozess ausblockieren.

Treiber-Initialisierung

Die Initialisierungsfunktionen von Treiber werden beim Laden des Treibers ausgefuhrt. InAbbildung 12 ist der Flow-Chart-Diagram des Initialisierung-Prozesses dargestellt. Fol-gend beschreiben wir den den auf dem Diagram dargestellten Algorithmus.

1. Es wird den Speicher fur RING-Struktur alloziert.

2. Der Speicher fur alle Deskriptoren wird alloziert. Die physische Adresse des erstenElementes von Deskriptor-Array wird in ein Register des Netzwerkadapters gesetzt,um dem Netzwerkadapter den Zugriff auf Deskriptoren zu ermoglichen [20].

3. Der Speicher fur Paket-Puffer wird alloziert.

4. Die physische Adresse des allozierten Paket-Puffer wird in den Address-Feld desDeskriptors geschrieben (siehe Abbildung 2).

5. Wiederhole die Schritte 3. und 4. fur alle RING-Slots (bzw. Deskriptoren).

30

Allozieren Speicher

für a l le Descr iptoren

Allozieren Speicher

für RING-Struktur

S ta r t

Al lozieren Speicher für

Paket -Puf fer [count ]

Deskr ip tor [count ] .Address =

&Paket -Puf fer [count ]

count = count +1

count < RING.SIZE

YES

Stop

NO

1 .

2 .

3 .

4 .

count = 0

Abbildung 12: Treiber: Initialisierung

31

Nach der Initialisierung-Phase des Treibers sind die Deskriptoren kontinuierlich im phy-sischen Speicher alloziert und initialisiert. Daruber hinaus sind die Paket-Puffer alloziertund die physische Adressen von den Paket-Puffer sind in den Address-Felder der Deskrip-toren gesetzt (siehe Abbildung 2). Nach dem setzen der physischen Adresse des erstenDeskriptor in den RDBAL- und RDBAH-Adapter-Register, kann der Netzwerkadaptern mitdem Capturing anfangen.

Ablauf des Capturing

Die Flow-Chart-Diagram des Kernel-Threads ist in Abbildung 13 dargestellt. Der Kernel-Thread bearbeitet maximal rx_processing_limit Slots und beginnt mit dem Slot, dessenNummer in der globalen current_SLOT-Variable gespeichert ist. Die Variable current_SLOTwird nach der Bearbeitung jedes Ringslots inkrementiert, sodass sie der Nummer desnachsten Slot im Ringpuffer entspricht.

Folgend beschreiben wir den Algorithmus des neuen Kernel-Threads:

1. Speichern des RING.TAIL-Wertes in RDT-Register

• Der Userspace-Process soll nach dem Zugriff auf Paket den Wert RING.TAIL soerhohen, dass RING.TAIL der Nummer des zuletzt gelesenen Slots entspricht.

• Der Kernel-Thread setzt RING.TAIL-Wert in RDT-Register und ubergibt damitdem Netzwerkadapter die neue freie Deskriptoren fur den DMA-Transfer dernachsten Pakete (siehe Abschnitt 2.1.1).

2. Berechnen der Verkehrsstatistiken.

• Time-Stamp wird berechnet und in SLOT-Struktur gesetzt.

3. current_SLOT modulo RING.SIZE inkrementieren.

• current_SLOT ist dann die Nummer des nachsten fur Bearbeitung stehendenSlot.

4. Der wert von current_SLOT wird in RING.HEAD gesetzt.

• Damit wird fur den Userspace-Prozess noch ein Slot zur Verfugung gestellt. DieSlots von RING.TAIL + 1 bis zu dem Slot mit der Nummer RING.HEAD - 1

enthalten die neue Pakete, welche der Userspace-Prozess noch bearbeiten soll(siehe Abschnitt 2.1.1).

5. count wird dekrementiert.

6. Der wartende Userspace-Capturing-Prozess wird ausblockiert wenn der Kernel-Threadalle rx_processing_limit Paket-Puffer oder alle neue nach dem letzten Interruptim RAM befindlichen Paket-Puffer bearbeitet hat.

Die graugezeichneten Boxen in Abbildung 13 bezeichnen die Operationen, die zur Verwal-tung von den TAIL- und HEAD-Ringpointers dienen. Dadurch, dass die RING-Struktur inden Userspace eingeblendet ist und damit sowohl im Userspace als auch im Kernelspacezur Verfugung steht, konnen der Treiber und der Userspace-Prozess durch das Setzen vonRING.TAIL- und RING.HEAD-Pointers einander uber die gemachte Arbeit benachrichtigen.

32

current_SLOT= (current_SLOT +1) mod RING.SIZE

RING.HEAD = current_SLOT

RDT = RING.TAIL

Berechne time stamp for RING.SLOT[current_SLOT]

count = rx_prozessing_limit

count = count - 1

STOP

START

1 .

5 .

2 .

4 .

count > 0

Yes

current_SLOT = RDH

Ausblockieren Userspace-Prozess

Yes

No

current_SLOT != RDH

Yes

6 .

3 .

Abbildung 13: Capturing-Ablauf. Kernel-Thread des ringmap-Netzwerkadapter-Treibers

33

Der Userspace-Prozess liest die neue Paket-Puffer bis zu dem Paket-Puffer mit der Num-mer RING.HEAD - 1, und wird blockiert fur das Warten auf neue Pakete. Nach jederBearbeiten des neuen Paket-Puffer setzt der Userspace-Prozess in RING.TAIL die Num-mer der gerade gelesenen Slot, und sobald der Kernel-Thread an der Reihe ist, liest derKernal-Tread diesen Wert und setzt ihn in RDT-Register.

Der Netzwerkadapter-Treiber beschreibt die Paket-Puffer mit den neuen Daten begin-nend von dem Slot, desser Nummer im RDH-Register bis zu dem Slot desser Nummer imRDT-Register gespeichert ist, und damit uberschreibt nicht die Paket-Puffer die von demUserspace-Prozess noch nicht bearbeitet wurden.

3.2.2 Systemaufruf-Funktionen

Die Systemaufrufe sind dazu gebraucht werden, um dem Interaktion zwischen den Netzwerkadapter-Treiber und Userspace-Capturing-Prozess zu ermoglichen. Dabei werden dem Userspace-Prozess die Funktionen zur Verfugung zu gestellt, die er aufgrund der Hardwarebegren-zungen nicht selber ausfuhren kann.

Die Systemaufrufe werden in unserem ringmap-Capturing-Stack fur die folgende Zweckegebraucht:

• Capturing-Steuerung

– Anhalten und Fortsetzen des Paketempfangs beim Netzwerkadapter

• Memory-Mapping

– Allozieren und Initialisieren der RING-Struktur (siehe Abbildung 11).

– Liefern dem Userspace-Prozess der physischen Adresse der RING-Struktur.

– Das eigentliche Memory-Mapping wird vom Userspace-Prozess durch den mmap-Systemaufruf auf dem device /dev/mem realisiert.

• Blockierendes Warten auf neue Pakete

– Sobald keine neue Pakete zur Bearbeitung fur den Userspace-Prozess im RAMliegen wird der Userspace-Prozess blockiert und erst nach dem Ankommen derneuen Pakete durch den Kernel-Thread wieder ausblockiert (siehe Abschnitt3.2.1, Abbildung 13)

Capturing-Steuerung

Capturing-Steuerung wird mit Hilfe des ioctl-Systemaufrufes realisiert. Die primare Auf-gaben dabei sind Capturing-Anhalten und Capturing-Fortsetzen. Die Idee liegt daran,dass der Userspace-Prozess einen ioctl-Systemaufruf macht, dann wird die fur den Auf-ruf verantwortliche Funktion im Kernelspace ausgefuhrt, welche uber die Beschreiben desControl-Register des Netzwerkadapters den Paketempfang anhalt oder fortsetzt.

Die Details sind im Kapitel Implementierung im Abschnitt 4.2.1 beschrieben.

34

Memory-Mapping

Die Memory-Mapping wird mit dem mmap-Systemaufruf auf dem Device /dev/mem rea-lisiert. Als Argument bekommt der mmap die physische Adresse und die Byte-Lange desSpeicherbereiches, der in den Userspace eingeblendet wird, und liefert dem Userspace-Prozess die gultige Userspace-Adresse des eingeblendeten Speicher-Bereich zuruck.

Das heißt, der Userspace-Capturing-Prozess soll fur das Einblenden der Paket-Puffer undRING-Struktur erstmal im Besitz der physischen Adressen zu sein. Diese konnen aufgrundder funktionalen User-Mode-Begrenzungen nur im Kernelspace bekommen werden. Dashat zur Folge, dass es außer mmap noch ein Systemaufruf zum Bekommen der physischenAdressen gebraucht wird.

Die Aufgaben der fur diesen Systemaufruf im Kernelspace verantwortlichen Funktion sindfolgende:

• Allozieren des Speicherbereiches fur RING-Struktur

• Initialisieren der RING mit den physischen Adressen von den Paket-Puffern und De-skriptoren

• Die physische Adresse der RING-Struktur zuruckgeben

Sobald der Userspace-Prozess die physische Adresse der RING-Struktur hat, kann er RINGin seinen Adressraum einblenden. Dann hat er auch die physische Adresse der Paket-Puffer und Deskriptoren, weil diese im RING gespeichert wurden. Mit dem Kenntnis derphysischen Adressen ist es dem Userspace-Prozess moglich die Paket-Puffer und die De-skriptoren in seinen Adressraum einzublenden und mit dem Capturing anfangen.

Blockierendes Warten auf neue Pakete

Dem Userspace-Capturing-Prozess soll es moglich sein, wahrend des Warten auf neue Pa-kete blockiert zu werden. Ohne Kernel-Unterstutzung ware es nicht moglich, denn nurKernel des Betriebssystem in der Lage ist die Prozesse zu blockieren. Deshalb, soll demUserspace-Prozess einen Systemaufruf zur Verfugung gestellt werden, der ihm sich zublockieren erlaubt hatte.

Im FreeBSD gibt es schon dafur einen Systemaufruf nanosleep(2). Dieses Systemaufruferlaubt nur einen Prozess fur eine bestimmte Zeit zu blockieren. Wir wollen aber etwasmehr und deshalb wurde fur unsere Zwecke einen neuen Systemaufruf implementiert.

Die Aufgaben der fur diesen Systemaufruf im Kernelspace verantwortlichen Funktion sindfolgende:

• Die fur Capturing relevante Statistiken zu aktualisieren

• Den Wert von RING.TAIL in RDT-Register setzen. Damit bekommt der Netzwerkad-apter neue Deskriptoren fur den Transfer in den RAM neu angekommenen Pakete.

• Den Prozess fur bis zu dem Auftreten des nachsten Interrupts “im Schlaf” legen,und dabei fur diesen Prozess die hochste Prioritat zu setzen.

Unser Systemaufruf erlaubt uns wahrend Warten auf neue Pakete die fur Capturing rele-vante Statistiken zu aktualisieren, ohne dabei auf dem Interrupt zu warten. Außerdem wird

35

den Inhalt der RDT-Registers aktualisiert, was dem Netzwerkadapter die Zusatzliche De-skriptoren zur Verfugung stellt. Und was sehr wichtig ist, bekommt der schlafende Prozessdie hohste Prioritat, was dazu fuhrt, dass, nach dem Interrupt, beim Umschalten des Sy-stem in User-Mode wird der Prozess als einer der ersten wartenden Prozessen aufgewachtund damit mit der kleinste Verzogerung mit der Bearbeitung der neuen Pakete anfangt.Dies kann sehr wichtig im Fall der hohe Verkehrsrate sein, denn in dieser Situation wirdvom Userspace-Capturing-Prozess unverzugliche Bearbeitung der Pakete und damit diemoglichst schnelle Befreiung der benutzten Deskriptoren erwartet.

3.2.3 Userspace-Anwendung

Paketzugriff-Prozess wird im Userspace ausgefuhrt. Die Aufgabe des Userspace-Capturing-Prozesses ist es, die Pakete in den eingeblendeten Paket-Puffer zu zugreifen mit dem Zieldiese zu bearbeiten und eventuell zu speichern. Um den Zugriff auf die Pakete zu bekom-men, soll der Userspace-Prozess zuerst die Einblendung der der Paket-Puffer in seinenAdressraum zu initiieren. Dies wird in der Initialisierungsphase des Prozesses geschehen.

Wenn die Paket-Puffer in Userspace eingeblendet sind, kann es mit dem Capturing an-gefangen werden. Der User-Prozess liest bzw. bearbeitet alle Paket-Puffer (Ring-Slots)die Reihe nach, und wenn keine neue Pakete im RAM vorhanden sind, wird er solangeblockiert bis die neue Pakete ankommen.

User-Capturing-Prozess. Initialisierung

In Abbildung 14 ist das Algorithmus der Initialisierungsphase des User-Prozess dargestellt.Bevor der User-Prozess den Zugriff auf die Pakete bekommt, soll er die Initialisierung unddie Einblendung der RING-Struktur in sein Adressraum initiieren. Dafur wird die physischeAdresse des RING-Struktur gebraucht.

Um die RING-Struktur zu initialisieren und die physische Adresse von ihr zu bekommenwurde extra Funktionalitat entworfen (siehe Abschnitt 3.2.2). Um diese Funktionalitatzu benutzen soll der Paketzugriff-Prozess einen Systemaufruf machen, der entsprechendeFunktion im Kernelspace ausfuhrt. Im Userspace wird dieser Systemaufruf mit der read()-Funktion mit Eingabe des symbolischen Devise des Treibers gemacht (siehe Kapitel 4.2.1).

Das Ausfuhren des Systemaufrufes verursacht das Allozieren der RING-Struktur, Initia-lisierung der RING mit den physischen Adressen der Paket-Puffer und Ruckgabe der phy-sischen Adresse der RING-Struktur. Mit dem Kenntnis der physischen Adresse machtder Userspace-Capturing-Prozess durch mmap-Systemaufruf die Einblendung der RING-Struktur in seinen virtuellen Speicherraum. Dann hat er den Zugriff physische Adressender Paket-Puffer und blendet diese dann auch auf gleicherweise seinen Speicherraum ein.

Sobald der Capturing-Prozess den Zugriff auf Paket-Puffer hat, kann er mit dem Cap-turing anfangen.

User-Capturing-Prozess. Capturing

In Abbildung 15 ist der Ablauf des Capturing in Userspace dargestellt. Der Userspace-Capturing-Prozess liest die RING_SLOT’s in der RING-Struktur der Reihe nach. Nimmt ausden Slots die benotigte Adresse der Paket-Puffer, mbuf’s, Deskriptoren, und danach be-arbeitet bzw. filtert die Pakete, die in den Paket-Puffer enthalten sind. Beim Bearbeiten

36

Bekommen Physische Adresse von RING

Systemaufruf: read()

Einblenden RING in Userspace

Systemaufruf: mmap

i = 0

Einblenden in Userspace:

RING.RING_SLOT[i].PAKET

Systemaufruf: mmap()


RING.RING_SLOT[i].MBUF



RING.RING_SLOT[i].MBUF


i < RING.SIZE

START

STOP

i = i + 1

YES

NO

Abbildung 14: User-Prozess. Initialisierung

37

Start

Block und Warte

bis neue Pakete im RAM sind RING.TAIL = (RING.HEAD -1 ) mod RING.SIZE

Bearbeite Paket im

RING.RING_SLOT[RING.TAIL + 1]

RING.TAIL = RING.TAIL + 1

YES

NO

Abbildung 15: User-Prozess. Capturing-Ablauf

jedes Paketes beschreibt der Capturing-Prozess den RING.TAIL mit der Nummer des ge-rade gelesenen Paket-Puffer. Sobald der RING.TAIL den RING.HEAD nachgeholt hat, wasdie Abwesenheit von neuen Paketen im RAM bedeutet, wird der Prozess blockiert. Sobalddie neue Pakete in den RAM ankommen, wird nach der Interruptbehandlung der Prozesswieder erweckt.

Dadurch, dass der Userspace-Capturing-Prozess sowohl die Paket-Puffer als auch die mbuf’sund Deskriptoren in seinem virtuellen Speicher hat, kann er aufwendige Paket-Bearbeitungmachen. Uber die Deskriptor-Felder ist jetzt dem Userspace-Prozess unterschiedliche De-tails, die der Netzwerkadapter zur Verfugung stellt (Checksum, Lenght, Error, etc. . . )bekannt. Das heißt, man braucht keine CPU-Lastige Systemaufrufe um den Zugriff auf dieInformationen zu bekommen.

3.3 Zusammenfassung

In diesem Kapitel wurde den Entwurf des neuen ringmap-Paket-Capturing-Stack vorge-stellt. Die Funktionen des Stacks sind fur Paketzustellung, Paketzugriff und Capturing-Steuerung zustandig. Die Zustellung- und Zugriff-Prozess benutzen gemeinsam mehre-re Speicher-Bereiche (shared-Memory), die mit Hilfe der RING-Struktur in Form einesRingpuffers modelliert sind. Die RING-Struktur und die fur Paketempfang verantwortlichePaket-Puffer sind in Adressraum sowohl des Zustellung-Prozesses als auch des Zugriff-Prozesses eingeblendet. Dies ermoglicht den Paketzugriff ohne das teure Kopieren undohne Systemaufrufe.

Der Zustellung-Prozess wird im Kernelspace und der Zugriff-Prozess im Userspace aus-gefuhrt. Aufgrund dass es nur einen Zustellung-Prozess und nur einen Zugriff-Prozess gibtentstehen keine race conditions. Deshalb werden Synchronisation-Massnahmen benotigt.

38

Fur den Zugriffsprozess ist die Funktionalitat entworfen, die es ihm erlaubt im blockiertenZustand auf die neue Pakete zu warten, das Capturing anzuhalten und wieder fortzu-setzen und die Einblendung der fur Paketempfang verantwortlichen Speicherbereichen zuinitiieren. Diese Funktionalitat soll im Kernelspace ausfuhrbar sein und dadurch uber dieSystemaufrufe zur Verfugung stehen.

Die Implementierungsdetails des Entwurfes sind im folgenden Kapitel dargestellt.

39

4 Implementierung

Das in diesem Kapitel vorgestellten Material wird die Implementierungs-Details des neuenringmap-Paket-Capturing-Stack darstellen. Die vorgestellten hier Code-Abschnitte habenkeine exakte ubereinstimmung mit dem implementierten Code: es sind nur die wichtigsteDetails dargestellt, die sich im Zusamenhang mit den im Kapitel Entwurf vorgestell-ten Algorithmen stehen. Fur das eingehende Verstandnis des Codes gibt es ausfuhrlicheKommentare im Code.

4.1 Datenstrukturen

Die in diesem Kapitel dargestellten Datenstrukturen sin in der fiveg_da.h Datei dekla-riert.

4.1.1 Ringpuffer

RING

struct r ing {unsigned int kernrp ;unsigned int user rp ;unsigned int s i z e ;struct r i n g s l o t s l o t [SLOTS NUMBER ] ;

} ;

Listing 1: RING-Struktur

• kernrp: RING.HEAD - HEAD-Pointer. Soll nur im Kernelspace geandert werden.

• userrp: RING.TAIL - TAIL-Pointer. Soll nur im Userspace geandert werden.

• size: RING.SIZE - Anzahl der Slots im Ringpuffer.

• slot: RING.RING_SLOT-Array - Array von Slots.

RING SLOT

struct r i n g s l o t {struct address d e s c r i p t o r ;struct address mbuf ;struct address packet ;struct t imeval t s ;unsigned long long cnt ;

} ;

Listing 2: RING-SLOT-Struktur

• descriptor: DESKRIPTOR - Fur Adressierung der Deskriptoren

• mbuf : MBUF - Fur Adressieren der mbuf’s

• packet: PAKET - Fur Adressieren des Paket-Puffers

• ts: TIME_STAMP - Paket-Timestamp. Wird beim Treiber berechnet.

• cnt: SLOT_COUNTER - Paket-Counter

40

ADDRESS

struct address {bus addr t phys ;vm o f f s e t t kern ;vm o f f s e t t user ;

} ;

Listing 3: ADDRESS-Struktur

• phys: PHYS_ADDR - Physische Adresse des adressierten Elementen

• kern: KERN_ADDR - Kernelspace-Adresse des adressierten Elementen

• user: USER_ADDR - Userspace-Adresse des adressierten Elementen

4.2 Funktionalitat

Die fur den ringmap-Paket-Capturing-Stack implementierten Funktionalitaten betreffensich Netzwerkadapter-Treiber, Libpcap-Library und Kernel-Funktionen, die in Folge derSystemaufrufen ausgefuhrt werden.

Alle Anderungen in der generischen Dateien des em-Treiber und Libpcap sind in uberMakrodefinition __FIVEG_DA__ eingetragen. Zum Beispiel:

. . .#ifdef FIVEG DA

adapter−>rm−>r ing . i n t e r r up t s coun t e r ++;/∗ Make i n t e r r u p t time stamp in the adapter s t r u c t u r e ∗/getmicrot ime (&adapter−>i n t r t s ) ;

#endif. . .

Listing 4: Code-Eintrage in Dateien des generischen em-Treiber

4.2.1 Treiber. Paketzustellung

Fur den ringmap-Treiber wurde als Basis der generische em-Treiber genommen. In denFunktionen des generischen em-Treibers wurden kleine Anderungen gemacht und dazunoch die neue Funktionen implementiert, die den Treiber der im Abschnitt 2.4 gestelltenAnforderungen entsprechend machen.

Die fur den ringmap-Treiber implementierten Funktionalitaten befinden sich zum grossenTeil in der Datei fiveg_da.c. In den generischen Dateien des Treibers wurden nur klei-ne Anderungen gemacht, die meistens nur die Funktionsaufrufe aus fiveg_da.c enthalten.

Die Funktionen des Treiber lassen sich in drei Kategorien Teilen:

• Initialisierung-Funktionen:

– werden beim Laden des Treibers aufgerufen.

• Systemaufruf-Funktionen

41

– Kernel-Funktionen, die infolge eines Systemaufrufes aufgerufen werden.

• Interruptsbehandlung-Funktionen

– Interrupt-Service-Routine und Kernel-Thread, die infolge eines Interrupt-Ereignissesaufgerufen werden und welche fur Capturing-Ablauf zustandig sind.

Initialisierung

Wahrend des Ladens des Treiber werden unter Anderem folgende Funktionen aufgerufen:

• em_probe(): Datei if_em.c. Ist fur das Erkennen der Netzwerkadapter-Modellesverantwortlich.

• em_attach(): Datei if_em.c. Diese Funktion ist fur alle Initialisierung-Prozessezustandig. Hier werden unter Anderem die Speicherbereiche fur Deskriptoren undPaket-Puffer alloziert.

• ringmap_attach(): Datei fiveg_da.c. Wird aus der em_attach() aufgerufen. Al-loziert den Speicher fur ring-Struktur und erzeugt ein neues symbolische Device/dev/ringmap. Uber dieses Device wird der Userspace-Capturing-Prozess mit Hilfeder Systemaufrufen read und ioctl Capturing-Steuerung, Mempory-Mapping undBlokierendes Warten anfordern (siehe Abschnitt 3.2.2).

Fur das Kompilieren aller Software fur den ringmap-Capturing-Stack und Laden des Trei-bers wurde den Skript ringmap_build_and_load implementiert. Der Skript befindet sichim Verzeichnis scripts/8 im Code-Repository.

Treiber. Systemaufruf-Funktionen

Um dem Userspace-Prozess die Interaktion mit dem Treiber und dadurch die Capturing-Steuerung zu ermoglichen, registriert der Treiber bei der Initialisierung das symbolischeDevice /dev/ringmap und bietet eine Menge von Kernel-Funktionen an, die in folge derSystemaufrufen auf dem device /dev/ringmap ausgefuhrt werden:

• ringmap_open(): wird in foge des open-Systemaufrufes ausgefuhrt. Checkt die furden Capturing benotigte Datenstrukturen. Pruft ob alle Speicher-Bereiche alloziertund zugreifbar sind.

• ringmap_read(): Wird in folge des read-Systemaufrufes ausgefuhrt. Initialisiert diering-Struktur mit den physischen Adressen von den Paket-Puffer und Deskriptoren.Und liefert dm Userspce-Prozes die physische Adresse der ring-Struktur.

• ringmap_ioctl(): wird in Folge des ioctl-Systemaufrufes ausgefuhrt. Erlaubt demUserspace-Prozess uber die Eingabe der folgenden ioctl-Werten unterschiedliche Funk-tionalitaten ausfuhren:

– IOCTL_DISABLE_RECEIVE: Schaltet den Paketempfang bei Netzwerkadapter aus.

– IOCTL_ENABLE_RECEIVE: Schaltet den Paketempfang bei Netzwerkadapter wie-der ein.

– IOCTL_DISABLE_FLOWCNTR: Sperrt Flow-Control-Mechanismus bei Netzwerka-dapter.

8SVN-URL: https://svn.net.t-labs.tu-berlin.de/svn/alexandre-da/src/70/scripts/

42

– IOCTL_SLEEP_WAIT: Bringt den Userspace-Prozess in den blockierenden Zu-stand. Dabei wird fur den Prozess den hochsten Prioritat gesetzt. Der Pro-zess wird erst im ringmap_handle_rxtx() (Kernel-Thread) wieder aufgewachtdurch den Aufruf von wakeup()-Funktion.

– IOCTL_SET_RDT: Synchronisiert RDT-Register mit dem ring.userrp (TAIL-Pointer).

Capturing-Ablauf. Interruptsbehandlung-Funktionen

Der fur den Ablauf des Capturing verantwortliche Code des Treibers wird in den Interruptsbehandlung-Funktionen ausgefuhrt. Das sind:

• em_irq_fast(): Datei if_em.c. Das ist die eigentliche Interrupt-Service-Routine.Die Funktion wird im Interrupt-Kontext, mit den gesperrten allen anderen Akti-vitaten auf der aktuellen CPU ausgefuhrt. Hier werden die Ursache der Interrupter-Ereignisses herausgestellt, Interrupts des Netzwerkadapters gesperrt und den Kernel-Thread geplant.

• ringmap_handle_rxtx(): Datei: fiveg_da.c. Das ist der Kernel-Thread. Hie wirdes folgendes erledigt:

– IFF_DRV_RUNNING-Flag prufen

– em_rxeof() aufgerufen

– ggf. noch Mal ringmap_handle_rxtx() planen

– Interrupts des Netzwerkadapters entsperren

• em_rxeof(): Datei if_em.c Die Aufgabe der Funktion unter Anderem ist es, diePaket-Puffer (maximal rx_processing_limit) mit den neuen Pakete zu prufen unddas RDT-Register mit userrp zu synchronisieren.

4.2.2 Anpassung der Libpcap

Um den Userspace-Anwendungen die Pakete mit dem ringmap-Treiber erfassen zu ermoglichenwurde die Funktionalitat der Libpcap-Library entsprechend fur diese Aufgabe angepasst.Dadurch brauchen alle Anwendungen, die Libpcap fur Paket-Capturing benutzen, keineAnderungen im Code zu haben.

Die neue Funktionen zur Libpcap befinden sich in der Datei fiveg_da_pcap.c. Die Dateiwird statisch beim Kompilieren zur Libpcap gelinkt.

Initialisierung

Bevor es mit dem Captruing angefangen wird, sollen die Paket-Puffer und ring-Strukturin den virtuellen Speicher des Userspace-Capturing-Prozesses eingeblendet werden. Weilfur die Userspace-Anwendungen der Einsatz des ringmap-Treiber transparent sein soll, istdie Funktionalitat fur die Memory-Mapping vollkommen in Libpcap implementiert. Dafurwurden einige Anderungen sowohl in pcap-Datenstruktur als auch in den pcap_open_live()

gemacht.

Die pcap-Datenstruktur enthalt unter Anderem folgende neue Variablen:

• pkt_counter: Anzahl der empfangenen Pakete.

43

• nic_statistics: Pointer zu der Datenstruktur, die ebenfalls mit der ring-Datenstrukturin Userspace eingeblendet wird und die Statistik-Daten, die von den Netzwerkadapter-Register im Treiber abgelesen werden, enthalt. Dadurch bekommt der Userspace-Capturing-Prozess einen lesenden Zugriff auf Netzwerkadapter-Statistik-Register [20].

• ring: Pointer auf ring-Struktur (siehe Listing 1).

Fur die Einblendung der benotigten Speicherbereichen in Userspace wurden in der pcap_open_live()folgende Zeilen hinzugefugt:

#ifdef FIVEG DAi f ( check module ( dev i ce ) < 0)

goto bad ;i f ( f i v e g s e t i f a c e p r o m i s c ( dev i ce ) < 0)

goto bad ;i f ( in it mmapped captur ing ( device , p ) < 0)

goto bad ;#endif /∗ FIVEG DA ∗/

Listing 5: Initiierung von Memory-Mapping

• check_module(): Pruft ob der neue ringmap-Treiber installiert ist. Macht den open-Systemaufruf.

• fiveg_set_iface_promisc(): Setzt den Interface fur Capturing in Promiscuous-Mode.

• init_mmapped_capturing(): Bekommt uber read-Systemaufruf die physische Adres-se der ring-Struktur. Blendet die ring uber den mmap-Systemaufruf in den User-space ein. Liest im ring die physischen Adressen von den Ring-Puffer und blendetalle Paket-Puffer uber mmap in den Userspace.

Capturing-Ablauf

Der Userspace-Capturing-Prozess bekommt den Zugriff auf die empfangene Pakete uberden Aufruf von pcap_loop() oder pcap_dispatch() Funktionen. Als Parameter bekom-men diese Funktionen einen Pointer auf eine callback -Funktion die fur jedes empfangenesPaket aufgerufen wird und als Eingabeparameter den Pointer auf den Paket-Puffer, wosich das aktuell bearbeitende Paket befindet, bekommt.

Der Aufruf von pcap_loop() oder pcap_dispatch() verursacht in der generischen Libp-cap den Aufruf von pcap_read_bpf(). Im neuen ringmap-Treiber wird stattdessenpcap_read_ringmap() aufgerufen. Die Aufgabe der pcap_read_ringmap() unter An-derem ist es, die Packet-Puffer mit den neuen Paketen zu lesen, die benotige Trafik-Statistiken zu berechnen, und fur jedes empfangene callback -Funktion aufrufen.

4.3 Makrodefinitionen

Alle Makrodefinitionen sind sowohl fur Treiber als auch fur Libpcap im fiveg_da.h im-plementiert. Die Makrodefinitionen konnen geandert werden, wodurch kann aber auch dieCapturing-Performance beeinflusst werden. Die Detailierte Beschreibung der Makrodefini-tion ist in der fiveg_da.h zu finden. Hier sind die einige wichtigste Definitionen gelistet:

44

RING_SAFETY_MARGIN: Minimale distance zwischen den TAIL- und HEAD-Slot. Erlaubtdem User-Prozess eine bestimmte Anzahl an vorhergelesenen Slots vor Uberschreibungmit neuen Daten zu retten.

SLOTS_NUMBER: Anzahl von Slots im Ringpuffer

_KERNEL: Code, der nur im Kernelspace ausgefuhrt wird

__FIVEG__DA__: Code der im Rahmen der Diplomarbeit implementiert wurde. Beim set-zen dieses Makro auf 0 werden alle Anderungen im Code zuruckgesetzt, sodass Libp-cap zum ihren klassischen Stand zuruckkommt.

4.4 Schwierigkeiten und Probleme wahrend des Implementierung-Prozess

4.4.1 Mangel an Dokumentation

Die von dem FreeBSD-Projekt angebotene Dokumentation fur System-Entwickler [2] warwahrend der Implementierung-Phase der Diplomarbeit zum großen Teil nicht “up-to-date”.Viele Aspekte die sowohl fur Netzwerk-Treiber-Programmierung als auch fur die Netzwerk-datenerfassung relevant sind, sind in diesem Buch nicht mehr aktuell. Ein anderes Buchfur Systementwickler unter FreeBSD ist “The Design and Implementation of the FreeBSDOperating System” [26]. Es beschreibt die nicht mehr aktuelle Version 5.3 (aktuell: 7.2)und hat relativ wenige Code-Beispiele. Ferner, die Implementierung von Traffic Capturingim Kernel ist kaum (oder gar nicht) beschrieben.

Aufgrund der bestehenden Dokumentation-Mangel habe ich intensive die freebsd-hackers-Mailing-Liste [4] benutzt. Die Mailingliste freebsd-hackers-Mailing-Liste [4] bot dagegeneine wertvolle Informationsquelle, entweder durch historischen Artikeln oder durch Ant-worten an meinen Fragen.

Das Buch Linux Device Drivers [14] war fur das allgemeine Verstandnis der Kernel-Programmierung sehr hilfreich. Leider sind die Unterschiede zwischen Linux und FreeBSDzu groß um dem Buch konkrete Implementierungshinweise zu entnehmen.

Die Arbeit von Fabian Schneider [32, 34] basiert auf dem aktuellen Stand der Technikder Verkehrerfassung unter BSD-Systemen. Die Autoren beschreiben die Probleme diemit dem aktuellen Stack verbunden sind.

In vielen Details waren die man-pages und die Kernelquellen die einzig verfugbare Do-kumentation.

4.4.2 Komplexitat der Hardware

Eine sehr detaillierte Dokumentation der von uns benutzten Netzwerkadapter (Intel Gi-gabit Ethernet) ist in dem Software Developer’s Manual (SDM) [20] enthalten. Eine Ein-leitung (Tutorial) in der Materie fehlt leider in diesem Buch. Das Buch fuhrt einige relativneue Konzepten ein:

• Interrupt-Coalescing (Abschnitt 2.1.1)

• Descriptor-Based-DMA (Abschnitt 2.1.1)

Interrupt Coalescing ist in “Interrupt Moderation Using Intel GbE Controllers” [19] sehrgut beschrieben. Eine gute Beschreibung der Descriptor-based DMA befindet sich in dem

45

Patent Linked List DMA Descriptor Architecture [31].

Wenn die Dokumentation nicht ausreichend war, mussten die Fragen durch das aufwandigeund intensive Lesen der Kenrelquellen beantwortet werden.

4.5 Zusammenfassung

In diesem Kapitel wurden die fur die Implementierung des neuen ringmap-FreeBSD-Packet-Capturing-Stacks wichtigsten Details dargestellt. Die ersten Abschnitte des Ka-pitels beziehen sich vollkommen auf den Entwurf und stellen die Datenstrukturen unddie Funktionen dar, mit deren Hilfe die, im Abschnitt Entwurf beschriebenen, Algorith-men implementiert sind. Die beiden Kapiteln sollte man fur ein besseres Verstandnis desCodes parallel lesen.

Der Source-Code der Funktionen und Datenstrukturen des ringmap-Capturing-Stack istsehr groß und komplex. Dadurch besteht keine Moglichkeit alle Details im schriftlichenTeil der Diplomarbeit zu beschreiben. Fur diejenigen, die den Code fur eigene Zweckeverwenden wollen oder an der Weiterentwicklung interessiert sind, stehen ausfuhrlicheKommentare im Code zur Verfugung.

Außerdem ist der Source-Code des Projektes auf Google-Code unter BSD-Lizenzen veroffentlichtund kann dort problemlos heruntergeladen werden. Fur Ruckfragen bei der Weiterentwick-lung stehe ich gerne zur Verfugung.

46

Cheetah

Linux-SMPFreeBSDeth1r ingmap0

Kontroll-Trafik

Testdatenfluss

PaketgeneratorCapturer

Teststeuerungssystem

Abbildung 16: Netzwerk-Diagramm des Testsbeds

5 Leistungsbewertung

In diesem Kapitel werden die Ergebnisse des Leistungsvergleichs zwischen den generischenund den im Rahmen der Diplomarbeit entwickelten ringmap-Packet-Capturing-Stacks dar-gestellt. Fur die Tests wurde ein Netzwerk mit drei Hosts aufgebaut. Das Netzwerkdia-gramm der Testsumgebung ist in Abbildung 16 dargestellt. Auf dem Paketgenerator wurdeVerkehr mit unterschiedlichen Charakteristiken erzeugt und auf dem Zielsystem (FreeBSD)erfasst. Dabei werden die Paketverluste und die Systemlast wahrend der Datenerfassunggemessen.

Das ringmap-Stack wird nicht nur mit unterschiedlichen Verkehrsmustern untersucht. Furdie Teststablaufe werden verschiedene Konfigurationsparameter fur das Betriebssystemund den Treiber eingesetzt, mit dem Ziel eine optimale ringmap-Konfiguration, die einebestmogliche Leistung ermoglicht, herauszufinden.

Die Performance des generischen Stacks wurde bereits in mehreren wissenschaftlichenExperimenten untersucht [32, 34, 33]. Aus diesem Grund werden mit dem generischen-Stack nur wenige Experimente durchgefuhrt, um die Performance von ringmap und genericvergleichen zu konnen.

5.1 Messaufbau

Im Folgenden beschreibe ich die fur Tests eingesetzten Knoten (Abbildung 16):

1. PaketgeneratorLinux-SMP :

• Ein leistungsfahigen Rechner zum Generieren des Test-Verkehrs:

– CPU: 8 x Intel(R) Xeon(R) CPU 2.50GHz

– Netzwerkadapter: PCIe, Intel PRO/1000 EB Ethernet Adapter

– Betriebssystem: Linux Debian Lenny, Kernel 2.6.26-2-686, SMP

47

Zeit

Verkehrserzeugung

auf Linux-SMP-Host

empty Capturing empty

Testbegin end

Star t Systemload-Messung

auf FreeBSD-Host

Start Captur ing-Prozess

auf FreeBSD-Host

Stop Systemload-Messung

auf FreeBSD-Host

Stop Captur ing-Prozess

auf FreeBSD-Host

Abbildung 17: Testablauf

2. Capturing-HostFreeBSD :

• Wahrend der Experimente erden fur das Capturing zwei Rechner eingesetzt:

(a) FreeBSD-1:

– CPU: AMD Athlon(tm) 64 Processor 2214.45-MHz

– Netzwerkadapter: PCI, Intel Dual Port Gigabit Ethernet Controller

(b) FreeBSD-2:

– CPU: 4 x Intel(R) Xeon(R) CPU 1.60GHz

– Netzwerkadapter: PCIe, Intel HP NC360T PCIe DP Gigabit ServerAdapter

– auf beiden Rechnern: FreeBSD-7.2, i386-Kernel (32 Bit)

– auf beiden Netzwerkadaptern wurde fur Interrupt-Throttling9 eingesetzt:

∗ 8000 Interrupts pro Sekunde maximal

3. TeststeuerungssystemCheetah:

• Virtuelle Maschine fur die Teststeuerung.

5.1.1 Testablaufspezifikationen

Fur die Testablauf-Steuerung wird ein Shellskript10 eingesetzt. Der Skript wird auf Chee-tah gestartet, und steuert durch SSH-Verbindungen zu Capturer - und Paketgenerator -Hostden Ablauf jedes Testes.

Folgend beschreibe ich den Ablauf der Tests in Einzelschritten (siehe Abbildung 17):

1. SSH-Login auf FreeBSD :

9Die Details zur Interrupt-Throttling finden sich im Abschnitt 2.1.110SVN-URL: https://svn.net.t-labs.tu-berlin.de/svn/alexandre-da/src/70/scripts/dotests.

sh

48

(a) Starten Capturing-Prozess.

(b) Starten Systemload-Messung.

2. SSH-Login auf Linux-SMP :

(a) Starten Verkehrserzeugung-Prozess

• Es wird Testdatenfluss generiert. Dabei wird eine bestimmte Anzahl vonPaketen gleicher Lange erzeugt und zu dem Capturer gesendet.

(b) Speichern in einer Temp-Datei der Charakteristiken des erzeugten Verkehr: Bit-Rate, Paket-Rate.

3. SSH-Login auf FreeBSD :

(a) Stop Capturing-Prozess

(b) Stop Systemload-Messung.

(c) Speichern in einer Temp-Datei der Systemload-Mess-Daten und Anzahl derempfangenen Pakete.

4. SSH-Login auf FreeBSD und Linux-SMP :

• Kopieren der gespeicherten Test-Daten von den FreeBSD und Linux-SMP aufCheetah

Jeder Test wird funf mal wiederholt. Fur die gemessenen Werte wird das ArithmetischesMittel und Standardabweichung berechnet, welche auf den Grafiken in den folgenden Ab-schnitten dargestellt sind.

5.1.2 Erzeugung von Verkehr

Der Verkehr fur die Tests wird mit Linux-Kernel-Packet-Generator(pktgen) [36] erzeugt.pktgen ist ein Linux-Kernel-Module, das benutzt wird um die UDP-Pakete zu generierenund diese ins Netz zu senden. Fur die Steuerung von pktgen wird das /proc-Filesystembenutzt.

Der Linux-Kernel-Paket-Generator wurde fur die Experimente ausgewahlt, weil er meh-rere Vorteile mit dem Unterschied zu den anderen Software (z.B. Nemesis, Scapy, Iperf,etc. . . ) fur die Erzeugung des Netz-Verkehr bietet. Vor allem handelt es sich dabei um einesehr hohe Paket-Rate, die mit pktgen erzeugt werden kann. Diese Eigenschaft ist deshalbsehr wichtig fur uns, weil wir die moglichst hohe Daten-Rate bei unseren Experimentenim Testdatenfluss erzeugen wollen, um den ringmap-Capturing-Stack zu testen und ihnmit dem generic-Capturing-Stack im Bezug auf Capturing-Performance zu vergleichen.

Um eine hohe Paket-Rate bei Intel Ethernet Gigabit Adapter zu erzeugen, mussen ei-nige Eigenschaften des Netzwerkadapters beachtet werden, und zwar, handelt es sich umFlow-Control-Mechanismus.

Flow-Control

Unter dem Begriff Flow-Control verstecken sich unterschiedliche Verfahren, die es erlau-ben, die Datenubertragung in einem Netz, die nicht synchron ablauft, so zu steuern, dasseine moglichst kontinuierliche Datenubermittlung ohne Paket-Verluste erfolgen kann. Das

49

erfolgt sich dadurch, dass die Paketsendung im Fall eines schnelles Senders und eines lang-samen Empfanger zeitweise unterbrochen wird.

Beim Intel Gigabit Netzwerkadapter ist der Flow-Control-Mechanismus per Default einge-schaltet, und das kann bei der Verkehr-Generierung zu einigen Problemen fuhren. Erstenswird der Flow-Control-Verkehr nicht von der Capturing-Software wahrgenommen, benutztaber Bandbreite, die wir fur unsere Test-Ablaufe maximal benutzen wollen. Zweitens, daunser Ziel im Erreichen maximal hohe Paket-Rate liegt, ist in unserem Fall der Flow-Control nur ein Hindernis, der die Datentransferrate begrenzt. Deshalb muss es vor Beginnder Experimente sowohl auf dem Capturing-Host, als auch auf dem Paket-Generator-Hostausgeschaltet werden.

Ausschalten von Flow-Control auf dem Intel Gigabit Netzwerkadapter

Unter Linux kann die Abschaltung von Flow-Control beim Laden des pktgen-Modules ander Kommandozeile erfolgen:

# modprobe e1000 FlowControl=0 (6)

Unter FreeBSD wird Flow-Control aus dem Treiber durch direkte Beschreibung des Receive-Control-Register (RCTL) ausgeschaltet (Listing 6):

void r ingmap d i sab l e f l owcont r ( struct adapter ∗adapter ){

unsigned int c t r l ;c t r l = E1000 READ REG(&( adapter)−>hw, E1000 CTRL ) ;c t r l &= (˜(E1000 CTRL TFCE | E1000 CTRL RFCE ) ) ;E1000 WRITE REG(&( adapter)−>hw, E1000 CTRL , c t r l ) ;

}

Listing 6: Funktion zur Ausschaltung des Flow-Control-Mechanismus. Die Funktion wirdim ringmap-Treiber verwendet.

5.1.3 Messung der CPU-Auslastung und der Paketverluste beim Capturing

Auf dem FreeBSD-Host werden beim Test-Ablauf die auf dem Linux-SMP-Host generiertenund gesendeten Pakete erfasst. Dabei wird die Anzahl der empfangenen Pakete und dieSystemload beim Capturing auf dem FreeBSD-Host gemessen.

Messung von Paketverlusten

Fur das Packet-Capturing wird eine einfache Anwendung implementiert, die fur den Pa-ketzugriff die Bibliothek Libpcap benutzt. In dieser Capturing-Anwendung ist ein callback -Funktion enthalten, die fur jedes empfangene Paket aufgerufen wird, und derer Aufgabeunter anderem ist es, die Pakete zu zahlen. Das Paketverlust (Plos) wird als Differenz zwi-schen den Anzahl der empfangenen (Prcv) und der gesendeten Pakete (Psend) berechnet:

Plos = Psend − Prcv (7)

Messung von CPU-Auslastung

Die CPU-Last wird auf FreeBSD uber die sysctl-Variable kern.cp_time abgefragt:

50

FreeBSD:% s y s c t l kern . cp timekern . cp t imes : 27281 1333 301046 513 1001093319

Bei der Abfrage der kern.cp_time-Variable werden auf dem Standard-Output die Zeitenausgegeben, welche die CPUs seit dem Start des Betriebssystem jeweils im user-, nice-,syst-, intr- und idle-Modus verbracht haben.

Beim Prasentieren der Tests-Ergebnisse wird aber nicht die volle CPU-Last, die aus denuser- nice- syst- intr- idle-Load besteht, sondern lediglich die Systemload (syst)angegeben. Da die Implementierung des neuen Stack hauptsachlich Kernel-Code betrifft,interessiert uns vor allem die Systemload (syst). Die Messung der Userload (user, nice)liegt deshalb außerhalb unserer Interessen, weil der großte Teil der Funktionalitat zur Pa-ketbearbeitung (z.B. Paketfilterung) im neuen Stack in den Userspace verschoben wurde.Dadurch ist die Userload jetzt komplett von den Paketbearbeitung-Aufgaben, fur welchesich der Userspace-Prozess entscheidet, abhangig. Daraus folgt, dass man, um eine sinn-volle Userload-Messung machen zu konnen, zuerst konkrete Szenarien fur das Verhaltendes Userspace-Prozesses erarbeiten muss, was aber nicht das Ziel dieser Diplomarbeit ist.Unser Ziel ist die Eliminierung der Engstellen im Capturing-Stack, die sich im Kernel-space befanden, wofur ein Entwurf erarbeitet wurde. Und der Absicht der Tests ist dasPrufen, ob unsere Entwurf-Ansatze korrekt sind, und ob sie zu dem gewunschten Zielfuhren. Anders gesagt, zu prufen, ob die Ausfuhrung des Kernel-Codes vom neuen ring-map-Capturing-Stack eine niedrigere Systemlast als beim alten generic-Capturing-Stackverursacht.

Im System-Mode wird auch die Interrupt-Service-Routine(ISR) des Netzwerkadapters aus-gefuhrt (siehe Abschnitt 2.2.2). Weil bei allen Tests fur die Interrupt-Rate-SteuerungInterrupt-Throttling (siehe Abschnitt 2.1.1) verwendet wurde, blieb die Interrupt-Ratewahrend unserer Tests immer konstant, was auch immer eine konstante Interrupt-Load(intr: etwa 3%) verursacht hat. Aus diesem Grund konnen wir die Interrupt-Load inunseren Vergleichen ignorieren.

Systemload-Messung

Um die Systemload (syst) wahrend eines Test-Ablaufs zu messen, werden die Werte dessyst-Counters vor Begin des Tests (tbegin) und nach dem Test (tend) gespeichert. Durch dieDifferenz ergibt sich die Zeit, die CPUs wahrend des Tests mit dem Ausfuhren des syst-Codes zugebracht haben. Diese Zeit entspricht aber nicht exakt dem Testablauf, denn essowohl zwischen den Messungsbeginn und Capturing als auch zwischen Capturing-Endund dem Mess-Ende (kurze) Zeitintervalle (tempty) gibt, in denen der syst-Counter Zeit-Statistiken sammelt, die nicht wahrend Capturing entstehen, was das Endergebnis etwasverfalscht (siehe Abbildung 17). tempty lasst sich messen, und zwar dadurch, dass maneinen Test ohne Paketversand veranstaltet.

Aber dadurch, dass das Auftreten der Ereignisse, die das Ausfuhren des Kernel-Codesverursachen (z.B. Interrupts oder Traps) unvorhersagbar ist, und, dass die Anzahl vonsolchen Ereignissen pro Zeitintervall meistens variabel bleibt, ist dieser Wert nicht exaktbestimmbar. Daher wurden vor Beginn aller Tests mehrere Messungen von tempty gemachtund ein durchschnittliches Wert tempty berechnet.

Dann berechnet sich die Zeit (Tsyst), die sich CPUs wahrend des Capturing im syst-Mode

51

verbracht haben durch:

Tsyst = tend − tbegin − tempty (8)

Auf gleiche Weise lassen sich die CPU-Zeiten fur user- nice- idle- und intr-Mode be-rechnen. Dann berechnet sich die Systemload (S) als der prozentuelle Zeitanteil, den dieCPUs im syst-Mode wahrend des Tests verbracht haben durch:

S =Tsyst ∗ 100

(Tuser + Tnice + Tsyst + Tintr + Tidle)(9)

5.2 Test-Parameter

Fur jeden Testablauf werden unterschiedliche Parameter eingesetzt, die sowohl den Paket-Generierungs-Prozess als auch den Capturing-Prozess beeinflussen. Fur die Tests, die zumVergleich des generic- und ringmap-Capturing-Stacks durchgefuhrt wurden, werden ledig-lich die Paket-Generator-Parameter geandert, wahrend die Konfiguration der Treiber aufdem Capturing-Host konstant blieb.

Fur die Auswertung der Performance des ringmap-Stack wird eine großere Menge an Testsdurchgefuhrt, um eine Konfiguration herauszufinden, bei der ringmap-Stack mit optimalerPerformance funktioniert.

5.2.1 Parameter fur die Generierung des Netz-Verkehrs

Die Parameter, die fur Linux Kernel Pakete Generator gesetzt werden, erlauben es, diePaket-Große und die Paket-Rate (dadurch auch Bit-Rate) des generierten Verkehr zu steu-ern. Die Konfiguration von pktgen lauft uber das /proc-Filesystem ab.

In den Tests wurden folgende pktgen-Parameter eingesetzt11:

pkt_size

• Die Lange der erzeugten und gesendete Pakete. Beeinflusst auch die Paket-und Bit-Rate des Verkehrs, denn je kleiner die Pakete sind , desto großer wirdder CPU-Aufwand fur das Erzeugen einer bestimmten Datenmenge und destohoher die Anzahl der Bus-Transaktionen um diese Datenmenge vom RAM zumNetzwerkadapter transferieren und ins Netz zu senden.

dstmac

• Destination-MAC-Adresse. Wurde bei den Tests des generic-Capturing-Stackabsichtlich auf eine nicht dem NIC entsprechende MAC-Adresse gesetzt, da-mit die empfangenen Pakete nicht vom Protokoll-Stack bearbeitet werden, unddadurch keine zusatzliche Systemload beim Capturing erzeugen.

delay

• Zeitintervall in Nanosekunden zwischen den gesendeten Paketen. Beeinflusst diePaket- und damit auch die Bit-Rate des erzeugten Verkehr.

count

• Anzahl der zu erzeugenden und zu sendenden Pakete.

11Eine detailierte Beschreibung der pktgen-Parameter findet sich in der Dokumentation [36]

52

5.2.2 Treiber-Parameter

Die Parameter die fur den ringmap-Treiber gesetzt werden, beeinflussen seine Performance,und konnen dadurch auf die Capturing-Performance einwirken. Einige Parameter werdenuber sysctl-Befehl [18] gesetzt, die anderen aber nur als Makrodefinitionen im Source-Code.

SLOTS_NUMBER

• Ringpuffer-Große: Anzahl der Ring-Slots bzw. der Paket-Puffer. Wird als Ma-krodefinition in der Datei fiveg_da.h12 gesetzt.

rx_processing_limit

• Die maximale Anzahl der Pakete, die ein von der ISR geplanter Kernel-Threadbearbeiten darf. Wird uber sysctl-Befehl gesetzt.

5.3 Ergebnisse

In diesem Kapitel werden die Ergebnisse der im Rahmen der Diplomarbeit durchgefuhrtenExperimente dargestellt. Der erste Abschnitt stellt die Ergebnisse der Experimente mitdem neuen im Rahmen des praktischen Teil der Diplomarbeit implementierten ringmap-Packet-Capturing-Stacks dar. Es werden die Systemload und Paketverluste beim Captu-ring in Abhangigkeit von der Paket-Rate und den der Einstellung der Treiber-Parameterdargestellt. Durch die Analyse der Ergebnisse werden dabei Parameter fur den neuen ring-map-Treiber ermittelt, die es erlauben, die Capturing-Performance zu maximieren (Ab-schnitt 5.3.1).

Im Abschnitt 5.3.2 vergleichen wir die Performance des ringmap- mit dem generic-Capturing-Stack, um den Performance-Gewinn durch den neuen Capturing-Stack quantitativ zu be-stimmen.

5.3.1 Ringmap-Paket-Capturing-Stack

Bei diesen Experimenten wurde die Capturing-Performance des ringmap-Capturing-Stackim Abhangigkeit von den folgenden Parameter gemessen:

• Treiber-Konfigurationsparameter: rx_processing_limit, SLOTS_NUMBER.

• Daten-Rate des erfassten Verkehr.

• FreeBSD-Kernel-Parameter: SMP-Kern vs. single-CPU-Kern.

• Type des Bussystems: PCI vs. PCIe.

Performance in Abhangigkeit von der Anzahl der Slots im Paket-Ringpuffer:SLOTS NUMBER

Die Anzahl der Slots in unserem Paket-Ringpuffer entspricht der Anzahl der (DMA- )De-skriptoren (siehe Abschnitt 3.1.3). Sie ist abhangig vom Modell des Netzwerkadaptersund darf nur auf Zweierpotenz-Werte gesetzt werden, wobei 4096der großtmogliche Wertist [20].

Das Ziel dieses Experimentes ist es, die optimale Werte fur die Anzahl der Slots (SLOTS_NUMBER)

12https://svn.net.t-labs.tu-berlin.de/svn/alexandre-da/src/70/em/fiveg_da.h

53

0

20

40

60

80

100

0 500 1000 1500 2000 2500 3000 3500 4000

Pa

ke

tve

rlu

ste

(%

)

Anzahl der Slots im Paket-Ringpuffer

PaketverlusteStandard Abweichung

Abbildung 18: Paketverluste in Abhangigkeit von der Anzahl der Slots im Paket-Ringpuffer

im Paket-Ringpuffer zu finden, bei welchen die Paketverluste und die Systemload minimalsind.

Konfiguration auf dem Capturer (FreeBSD-Host):

• Hardware: FreeBSD-213

• Betriebssystem: FreeBSD 7.2, single-CPU-Kernel

• Treiber:

– Maximale Anzahl der Pakete pro Kernel-Thread:rx_processing_limit= 200

Verkehrsparameter:

• Paketlange: 64-Bytes

• Paketmenge: 15000000

• Bit-Rate: etwa 696MB/sec

Beil allen durchgefuhrten Tests wird der Wert von rx_processing_limit auf 200 gesetztund der Wert SLOTS_NUMBER zwischen 8 und 4096 geandert.

Paketverluste: In Abbildung 18 sind die Paketverluste dargestellt. Auf der X-Achsewird die Anzahl der Slots dargestellt. Auf der Y-Achse die prozentuelle Anzahl der Paket-verluste. In allen durchgefuhrten Experimenten mit 256 oder mehr Slots sind die Paket-verluste relativ konstant und liegen unter 0.02%, d.h. die Erhohung der Anzahl der Slotsab 256 bringt keinen weiteren Gewinn mehr.

13siehe Beschreibung im Abschnitt 5.1

54

Systemload: Bei allen durchgefuhrten Experimenten ist die Systemload unter 12%. Beiden Puffer-Großen unter 256 Slots hat die Systemload auch niedrigere Werte. Das lasstsich dadurch erklaren, dass durch die Paketverlusten, die bei der geringeren Slotsanzahlentstanden haben, war das System auch weniger belastet.

Ergebnis-Analyse. Die Grunde fur die Paketverluste bei so einer geringen Systemload(> 12%) liegen nicht in der Software, sondern eher bei Hardware. PCIe-BUS hat einevollkommen ausreichende Performanz fur den Transport unseres Verkehrs in den RAM.Die Paketverlusten werden moglicher Weise aufgrund der geringen Große des Paket-Pufferauf dem Netzwerkadapter (20K) entstehen.

Performance in Abhangigkeit von der maximalen Anzahl der pro Kernel-Thread-Ablauf bearbeitende Paketen: rx processing limit

Das Ziel dieses Experimentes ist es, die optimale Werte fur die Variable rx_processing_limitzu finden, bei welchen die Paketverluste und die Systemload minimal sind.




• Treiber:

– Paket-Ringpuffer-Große: SLOTS_NUMBER= 1024

– Bit-Rate: etwa 696MB/sec

Verkehrsparameter:



Bei Experimenten wird der wert von rx_processing_limit zwischen 1 und 300 geandert.

Paketverluste: Bei allen durchgefuhrten Experimenten ergibt sich ein sehr kleiner Pa-ketverlust geringer als 0.02% aller generierten Pakete.

Systemload: Die Ergebnisse des Systemload-Messungs-Experimentes sind in Abbildung19 dargestellt. Auf der X-Achse werden die Werte der Variable rx_processing_limit

dargestellt, auf der Y-Achse die Systemload bei der Verkehrserfassung. Eine hohe Anzahlvon Paketen pro Ablauf des Kernel-Threads verursacht eine geringe Systemlast. UnsereMessungen zeigen dass bei einer Einstellung > 50 die Systemlast relativ Konstant unter12% bleibt. Die weitere Erhohung des Wertes bringt keinen Gewinn mehr.

Performance in Abhangigkeit von Paketlange

Das Ziel des Experimentes ist es, die maximalen Werte fur die Systemload und Paket-verluste beim Capturing herauszufinden. Dabei wird auch versucht zu analysieren, vonwelchen Bedingungen die Systemload wahrend der Verkehrserfassung abhangt.


55

0

10

20

30

40

50

60

70

80

90

100

0 50 100 150 200 250 300

Syste

mlo

ad

(%

)

max. Anzahl der Pakete pro Kernel-Thread-Ablauf

SystemloadStandard Abweichung

Abbildung 19: Systemload in Abhangigkeit von der maximalen Anzahl der pro Kernel-Thread-Ablauf bearbeitende Pakete



• Treiber:

– Maximale Anzahl der Pakete pro Kernel-Thread: rx_processing_limit= 200


Verkehrsparameter:

• Paketlangen: 64- , 200-, 300-Bytes

• Paketmengen: 5000000, 10000000, 15000000

Paketverluste: Bei allen Experimenten ergibt sich fur Paketgroßen uber 200 Bytes diePaketerfassungsrate 100%. Nur in den Experimenten mit der kleinsten Paketgroße von64-Bytes und nur bei der hochsten erreichte Bit-Rate von 627MB/sec ergibt sich ein sehrkleines Paketverlust geringer als 0.02% aller generierten Pakete.

Systemload: Die Ergebnisse der Systemload-Messung werden in den Abbildungen 20und 21 dargestellt. Die maximal erreichte Systemload beim Capturing in allen Experi-menten liegt unter 12% und wird erreicht beim Capturing des Verkehrs mit den kleinsten64-Bytes-Paketen.

In Abbildung 21, wird die Systemload in Abhangigkeit der Paket-Rate dargestellt. Beidiesen Ergebnissen kann man deutlich sehen, dass die Systemload beim Capturing von

56

4

5

6

7

8

9

10

11

12

0 100 200 300 400 500 600 700 800 900 1000

Syste

mlo

ad

(%

)

Bit-Rate (MBit/sec)

300 Bytes Pakete200 Bytes Pakete64 Bytes PaketeStandard Abweichung

Abbildung 20: Systemload in Abhangigkeit von Bit-Rate beim Capturing

der Paket-Rate und nicht von der Paket-Große beeinflusst wird. Drei Verkehrsstrome mitunterschiedlichen Paketlangen verursachen fast identisch gleiche Systemload (die Unter-schiede sind geringer als 0.5%) wenn die Paketraten in diesen drei Verkehrsstromen gleichsind.

Dies lasst sich einfach erklaren. Im neuen ringmap-Treiber wurden alle Paket-Kopie-Operationen und Paket-Filterung entfernt. Der Userspace-Prozess bekommt den Zugriffauf die Pakete sofort nach dem DMA-Transfer in den RAM. Aus diesen Grunden kannkeine großere Systemload entstehen, beim Capturing mit dem ringmap-Treiber wird imKernelspace die geringstmogliche Arbeit erledigt, die pro Paket-Puffer skaliert und nichtvon der Paket-Große abhangt.

Performance in Abhangigkeit von der Anzahl der CPU’s

Das Ziel des Experiments ist es, die Paketverluste beim Capturing in Abhangigkeit vonder Anzahl der CPUs auf dem Capturing-System zu messen.



• Betriebssystem: FreeBSD 7.2, single-CPU-Kernel, SMP-Kernel

• Treiber:



57

4.5

5

5.5

6

6.5

7

50000 100000 150000 200000 250000 300000 350000 400000

Syste

mlo

ad

(%

)

Paket-Rate (pps)

300 Bytes Pakete200 Bytes Pakete64 Bytes PaketeStandard Abweichung

Abbildung 21: Systemload in Abhangigkeit von Paket-Rate beim Capturing

Verkehrsparameter:



Bei diesem Experiment werden fur das Capturing unterschiedliche FreeBSD-Kerne einge-setzt. Bei einem Experiment lauft das Capturing mit dem SMP-Kernel, bei dem anderenwird ein Kernel ohne SMP-Funktionalitat verwendet. Fur beide Tests wird der Verkehraus 64-Byte-Paketen generiert und gesendet. Die Ergebnisse des Experiments sind in Ab-bildung 22 zu sehen. Auf der X-Achse ist die generierte Datenrate dargestellt. Auf derY-Achse die absolute Zahl der Paketverluste. Die durchschnittliche Anzahl der Paketver-luste fur die Experimente mit einem SMP-Kernrel wird mit blauen Plus-Zeichen, die mitdem Single-Kernel mit grunen Quadraten dargestellt. Die Paketverluste sind in beidenFallen im Verhaltnis zur generierten Paketrate gering, steigen im Fall des SMP-Kernelsaber ab 400MBit/s stark an, bis auf 800 verlorene Pakete pro Experiment.

Der SMP-Kernel Zeigt etwas schlechteres Performance. Der Grund dafur kann ein Daten-lokalitats-Problem sein. Die unterschiedliche CPU-Kerne haben mindestens einen eigenenDaten-Cache-Level, was Cache-Misses bei der Datenbearbeitung verursachen kann. Dieswar wahrscheinlich der Grund fur die hoheren Paketverluste auf dem SMP-System. Den-noch ist die Systemload beim Capturing mit einem Single-CPU-Kernel geringer als 12%.Das heißt, dass eine CPU problemlos das Capturing des Verkehrs bis 1Gbit schafft.

Capturing-Performance beim konventionellen PCI

Das Ziel des Tests ist es die Capturing-Performance des ringmap-Stack in Abhangigkeitvon PCI-BUS-Variante des Capturing-Systems zu messen.

58

0

200

400

600

800

1000

0 100 200 300 400 500 600 700

Pa

ke

tve

rlu

ste

(p

kts

)

Bit-Rate (MB/s)

64-Bytes Pakete SMP-Kern64-Bytes Pakete single-CPUStandard Abweichung

Abbildung 22: Paketverluste in Abhangigkeit von Paket-Rate beim Capturing auf einemSMP und single-CPU-System


• Hardware: FreeBSD-1 vs. FreeBSD-2


• Treiber:



Verkehrsparameter:


• Paketmengen: 5000000, 1000000, 15000000

Paketverluste: Die Ergebnisse des Tests sind in Abbildung 23 zu sehen. Auf der X-Achse wird die generierte Datenrate dargestellt. Auf der Y-Achse der prozentuelle An-teil der Paketverluste. Der Rechnersystem mit dem konventionellen PCI zeigt wesent-lich schlechtere Paketerfassungsrate beim Capturing als PCIe. Die Paketverluste entste-hen sogar bei den Verkehr mit großen Paketen (700- und 1500-Bytes) wenn die Bit-Rateuber 800MB/sec liegt. Verkehr, der ausschließlich die kleinsten 64-Bytes-Pakete enthalt,wird zu auf etwa 50% erfasst. Das ist auch verstandlich. Denn mit den kleinsten Pake-ten wird auch die hochste Paket-Rate erzeugt (> 1000000pkts/sec). Und dadurch, dassPCI-Bussystem einen großen Overhead beim Transfer von Daten in den RAM hat (sieheAbschnitt 2.1.2) schafft es es nicht, den Datentransfer bei einer so hohen Daten-Rate inden RAM zu bewaltigen.

59

0

10

20

30

40

50

60

0 100 200 300 400 500 600 700 800 900 1000

Pa

ke

tve

rlu

ste

(%

)

Bit-Rate (MBit/s)

64-Bytes Pakete700-Bytes Pakete1500-Bytes PaketeStandard Abweichung

Abbildung 23: Paketverluste in Abhangigkeit von der Bit-Rate beim Capturing auf demRechner mit dem konventioneller PCI-Bus

Systemload: Die Ergebnisse des Tests sind in Abbildung 24 prasentiert. Die maximalerreichte Systemload liegt unter 13%, und damit in der selben Großenordnung beim Ver-kehrerfassung auf dem Rechnersystem mit dem PCIe-Bus. Da die Systemload so kleinist, ist sichergestellt, dass die deutlichen Paketverluste beim 64-Bytes-Paket-Verkehr, nichtwegen der Ineffizienz der Software oder zu niedrigeren Prozessor-Bus-Bandbreite (Kopie-Operationen) entstehen. Die Ursache der Paketverlusten liegt bestimmt auf der Hardware-seite und bei diesen Experimenten ist der PCI-Bus-System sehr wahrscheinlich der Grunddafur.

5.3.2 Vergleich generic- mit ringmap-Paket-Capturing-Stack

Das Ziel dieses Testes ist es, die Capturing-Performance von ringmap-Capturing-Stackmit dem generic-Capturing-Stack zu vergleichen.




• Treiber:



– BPF-Puffer-Große: 10MB

Verkehrsparameter:

60

3

4

5

6

7

8

9

10

11

12

13

0 100 200 300 400 500 600 700 800 900 1000

Syste

mlo

ad

(%

)

Bit-Rate (MBit/s)

64-Bytes Pakete700-Bytes Pakete1500-Bytes PaketeStandard Abweichung

Abbildung 24: Systemload in Abhangigkeit von Bit-Rate beim Capturing. KonventionellerPCI-Bus

• Paketlangen: 64-, 200-, 300-Bytes

• Paketmengen: 5000000-, 10000000-, 15000000 Pakete

Paketverluste: In Abbildung 25 sind die Paketverluste dargestellt. Auf der X-Achsewird die generierte Datenrate dargestellt. Auf der Y-Achse der prozentuelle Anzahl derPaketverluste. Bei allen Tests entstanden die Paketverlust bei generic-Stack lediglich furPakete der Großen 200 und 64 Bytes. Dabei kann der generic-Stack fur die 64-Bytes-Pakete bei der Bit-Rate von 393Mbit/s und hoher (entsprechende Paket-Rate > 819545)nur eine konstante Anzahl von Paketen erfassen, etwa 262147 Pakete, unabhangig von dergenerierte Paketmenge.

Systemload: Die Ergebnisse der Systemload-Messung sind in Abbildung 26 dargestellt.Auf X-Achse wird die generierte Datenrate dargestellt. Auf der Y-Achse die Systemload.Bei Erfassung der Verkehr mit dem generic-Stack liegt die Systemload wesentlich hoherals beim ringmap-Stack. Dies erklart sich dadurch, dass der generic-Stack fur jedes Paketmehrere Kopie-Operationen im Kernelspace ausfuhrt und fur den Paketzugriff von derUserspace einen Systemaufruf verwendet. Bei hohen Daten-Raten ist diese Vorgehensweisedes generic-Stack nicht mehr effizient.

61

0

20

40

60

80

100

0 100 200 300 400 500 600 700 800 900 1000

Pa

ke

tve

rlu

ste

(%

)

Bit-Rate (MBit/s)

64-Bytes Pakete ringmap200-Bytes Pakete ringmap300-Bytes Pakete ringmap64-Bytes Pakete generic200-Bytes Pakete generic300-Bytes Pakete genericStandard Abweichung

Abbildung 25: Paketverluste in Abhangigkeit von Bit-Rate beim Capturing. Vergleichringmap- und generic-Packet-Capturing-Stacks

0

10

20

30

40

50

60

70

80

90

100

0 100 200 300 400 500 600 700 800 900 1000

Syste

mlo

ad

(%

)

Bit-Rate (MBit/s)

64-Bytes Pakete ringmap200-Bytes Pakete ringmap300-Bytes Pakete ringmap64-Bytes Pakete generic200-Bytes Pakete generic300-Bytes Pakete genericStandard Abweichung

Abbildung 26: Systemload in Abhangigkeit von Bit-Rate beim Capturing. Vergleichringmap- und generic-Packet-Capturing-Stacks

62

6 Zusammenfassung

Das Ziel dieser Diplomarbeit ist es, die fur Capturing relevante Software des Betriebssy-stem FreeBSD zu untersuchen, die Probleme, die zur Reduzierung der Capturing-Performancefuhren, herauszufinden und aufgrund der gefundenen Problemen den neuen (ringmap)-FreeBSD-Packet-Capturing-Stack zu erarbeiten, zu implementieren und auszuwerten. Dieneue Losung basiert auf der fur die Diplomarbeit vorausgesetzte Hardware (siehe Ab-schnitt 1.1.2).

Die Diplomarbeit ist in drei Phasen abgelaufen: Einarbeitung, Implementierung und Te-sten. Wahrend der Einarbeitungszeit habe ich viele neue Kenntnise in Themen, dieuber das normales Informatiksstudium hinausgehen, erworben. Es handelt sich vor allemum Wissen uber die Funktionsweise moderner Netzwerkadapter und Betriebssystemkern-und -Treiber-Programmierung. Unter Anderem habe ich dabei neue Konzepte uber dieHardware-Gegebenheiten und Software-Implementierung der modernen Interrupt- undDMA-Mechanismen (siehe Kapitel Grundlagen, Abschnitt 2.1.1) gelernt.

Außerdem wurden von mir mehrere Arbeiten [32, 34, 33, 23] uber Capturing-Problematikdurchgearbeitet mit dem Ziel, die beim Capturing vorhandene Probleme zu analysieren,um die Anforderungen fur den neuen ringmap-Packet-Capturing-Stack zu erstellen. Furdie Capturing-Performance-Probleme wurde in den Arbeiten hauptsachlich die Anzahlder Paket-Kopie-Operationnen und die hohe Interrupt-Rate bei der Verkehr-Erfassungals Grunde genannt. Als eine mogliche Losung zur des Interrupt-Overhead wird die Ver-wendung des Polling-Mechanismus [17] vorgeschlagen. Wegen der Instabilitat der BSD-Polling-Implementierung fur SMP-Kernel [1] habe ich fur den Entwurf des neuen Stacksallerdings das normale Interrupt-Driven-Modell eingesetzt. Neben der Anzahl der Kopie-Operationen, wurden im generic-Capturing-Stack einige andere Implementierungsdetailsentdeckt, welche die Capturing-Performance bei hohen Paket-Raten beeinflussen konnen.Vor allem die Speicher-Allozierungen welche der generic-Treiber fur jedes neue Packetdurchfuhrt, beeinflussen die Performanz negativ. Mit dem Ziel die herausgefundene Capturing-Performance-Probleme zu eliminieren wurden die Anforderungen und den Entwurf der Im-plementierung des neuen ringmap-Packet-Capturing-Stack erstellt (Kapitel Grundlagen,Abschnitt 2.4).

In der Implementierung-Phase wurde der neue ringmap-Packet-Capturing-Stack fur dasBetriebssystem FreeBSD programmiert (siehe Kapitel Implementierung). Dafur wurde derCode fur Adapter-Treiber, Systemaufruf-Funktionen und Libpcap-Library implementiert.Wahrend der Implementierung habe ich tiefgehende Kenntnisse und viel praktische Er-fahrung in Kernel- bzw. Treiberprogramming fur UNIX-artige-Systeme erworben.

In der Test-Phase wurde der neue ringmap-Packet-Capturing-Stack getestet und mit demgeneric-Stack in Bezug auf leistungsfahigkeit vergliechen. Fur das Testen des ringmap-Stack wurden unterschiedliche Verkehr-Raten generiert, unterschiedliche Treiber-Parametereingesetzt und verschiedene Hardware fur den Tets verwendet (siehe Kapitel Leistungs-bewertung). Fur die Tests wurden Shell-Skripte implementiert die sowohl alle Testablufegesteuert haben als auch die Testergebnisse ausgewertet und in Form von Tabellen undgnuplot-Grafiken gespeichert haben.

63

6.1 Erreichte Ziele

6.1.1 Verbesserung der Capturing-Performance

Beim Einsatz des im Rahmen der Diplomarbeit implementierten ringmap-Stack wird dieCapturing-Performance unter gleichen Bedingungen hoher als beim generic-Stack. DieSystemload beim Capturing mit dem ringmap-Stack ist deutlich geringer als mit demgeneric-Stack. Bei allen durchgefuhrten Experimenten war die Systemload beim Capturingmit dem ringmap kleiner als 12%. Die Systemload bei der Verwendung von generic-Stackvariiert von 13% bis 100%. Bezuglich der Systemload zeigt der ringmap einen deutlichenGewinn.

Anders sieht es mit den Paketverlusten aus. Beide Stacks zeigen identisch gute (100%)Paketerfassungsrate fur den Fall wenn die Paketgroße uber 200 Bytes liegt. Bei Paketenkleiner als 200 Bytes, und daraus verursachten hoheren Paketraten, > 450000pkts/sec,verliert der generic-Stack (mit 10MB BPF-Puffer-Große) bis zu 100% aller der generier-ten Pakete. Selbst bei maximaler Belastung verliert der ringmap-Stack weniger als 0.02%der Pakete.

6.1.2 Stabilitat und Benutzbarkeit

Der ringmap-Capturing-Stack hat in der Tests-Phase (insgesamt mehr als 100 000 Testsmit den unterschiedlichen Treiber-Parameter) weder Segmentation faults noch keine Ker-nel panics verursacht. Das bedeutet, dass die fur Kernelspace und Userspace (Libpcap)implementierte Software sehr stabil ist.

Der ringmap ist sehr einfach einzusetzen. Im Verzeichnis scripts/ befinden sich zweiShell-Skripts:

• ringmap_build_and_load: Kompiliert und installiert ringmap-Software.

• generic_build_and_load: Bringt das System in den generischen Zustand.

Dadurch, dass der Userspace-Code in der Libpcap-Library eingesetzt wurde, erlaubt esallen Anwendungen, die auf Libpcap basieren, zum Beispiel tcpdump, ohne AnderungenNetzwerk-Pakete mit dem ringmap-Stack zu erfassen (siehe Einschrankungen im nachstenAbschnitt 6.2).

Zudem lasst sich der ringmap-Capturing-Stack, im Fall dass es auf dem System meh-rere unterschiedliche Intel Gigabit Adapters gibt, durch die Eingabe der PCI-Device-IDnur fur einen ausgewahlten Adapter einsetzen, sodass der generic-em-Treiber die restlicheAdapters steuert. Die PCI-Device-ID des Adapter wird als Makrodefinition DEV_ID in derDatei fiveg_da.h eingegeben. Dadurch ist es moglich ringmap- und generic-Software aufeinem System gleichzeitig zu benutzen.

6.2 Einschrankungen des ringmap-Packet-Capturing-Stack

Die Benutzung der ringmap-Software verursacht auf dem Capturing-System (bzw. fur dieAusgewahlte Adapter) folgende Einschrankungen:

Kein TCP/IP Protokollstack: Der ringmap-Adapter-Treiber besitzt zur Zeit keineVerbindung mit den TCP/IP-Protokoll-Stack-Funktionen. Das heißt, dass ein Netzwerk-Interface, das mit dem ringmap-Treiber gesteuert wird, zu diesem Zeitpunkt aussch-liesslich fur Paket-Capturing benutzt werden kann. Wenn aber im System mehrere

64

Netzwerk-Adapter mit den unterschiedlichen Device-ID’s vorhanden sind, dann istes moglich den Protokoll-Stack uber das andere Netzwerkinterface zu benutzen (sieheAbschnitt 6.1.2).

Keine Paketfilterung im Userspace: Die Paket-Filterung mit BPF im Userspace istderzeit nicht moglich. Das Benutzen von BPF-Filter sollte aber keine aufwendigeAufgabe zu sein, denn auch die Libpcap hat eine Implementierung fur BPF. Daherkann Filtern mit den Libpcap-Funktionen umgesetzt werden.

Libpcap Einschrankungen: Fur das Anpassen der Libpcap an den ringmap-Stack wur-den einige Code-Stucke im Libpcap-Quell-Code auskommentiert oder ersetzt. Da-durch ist die Funktionalitat der neuen ringmap-Libpcap ist nicht mit der generic-Libpcap identisch. Aus der generic-Libpcap sind die Funktionalitat entfernt, welcheden BPF im Kernelspace anfordern. Außerdem wurde der to_ms-Parameter [21] furdie pcap_open_live()-Funktion deaktiviert, aber aus Kompatibilitatsgrunden ge-blieben. Beim Capturing mit dem ringmap-Stack blockiert der Userspace-Prozesswenn es keine neue Pakete mehr gibt, bis weitere Pakete ankommen.

Alle genannte Einschrankungen sind in dem Sinne nicht kritisch, dass sie sich eliminierenoder, fur bestimmte Anforderungen, anpassen lassen. Der Source-Code von ringmap istauf Google-Code veroffentlicht und unter dem Namen ringmap auf dem Server zu finden.An der zukunftigen Weiterentwicklung des Projektes habe ich großes Interesse und bietemeine Hilfe an.

6.3 Zukunftige Themen

6.3.1 Performance-Vergleich mit dem Zero-Copy-BPF-Buffers

Im Lauf der Test-Phase der Diplomarbeit, war der Zero-Copy-BPF-Buffers Projekt nochim alpha-Stadium und nicht bereit fur das Testen (siehe Abschnitt 2.3). Inzwischen istder Zero-Copy-BPF-Buffers in der neusten FreeBSD-8.0-Version vorhanden und soll stabilsein. Daher soll die Auswertung von Zero-Copy-BPF-Buffers der nachste Schritt sein.

6.3.2 10Gbit Capturing

Der Source-Code des ixgbe-Adapter-Treibers [6] fur 10-Gigabit-Netzwerkanschlusse14 hateine ahnliche Struktur wie der Source-Code des em-Treiber. Deshalb sollte die ringmap-Software einfach fur den 10-Gigabit-Treiber anpassbar sein. Dafur muss aber eine Arbeitvom in FreeBSD-Kernel-Programming kompetenten Spezialisten geleistet werden, dennbeide Treiber sind nicht vollkommen identisch, und deshalb sollte dem Softwareentwickleralle Details von BSD-Treiber-Programming bekannt werden, um die Portierung auf 10Gbitzu machen. Auch hierzu biete ich meine Hilfe an.

14ixgbe - Treiber fur Intel 10-Gigabit-Netzwerkadapter

65

Literatur

[1] Device polling support for freebsd. http://info.iet.unipi.it/~luigi/polling/.

[2] Freebsd architecture handbook. http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/index.html.

[3] FreeBSD Developer Summit presentation describing Zero-copyBPF. http://www.watson.org/~robert/freebsd/2007asiabsdcon/

20070309-devsummit-zerocopybpf.pdf.

[4] freebsd-hackers – technical discussions relating to freebsd. http://lists.freebsd.

org/mailman/listinfo/freebsd-hackers.

[5] Lmbench - tools for performance analysis. http://www.bitmover.com/lmbench/.

[6] Netzwerkadaptertreiber fur pci-e 10-gigabit-netzwerkanschlusse unter freebsd*.http://downloadcenter.intel.com/confirm.aspx?httpDown=http://

downloadmirror.intel.com/14688/eng/ixgbe-2.0.1.tar.gz&agr=&ProductID=

&DwnldId=14688&strOSs=&OSFullName=&lang=deu.

[7] Stream: Standard results for pc-compatibles. http://www.cs.virginia.edu/

stream/peecee/Bandwidth.html.

[8] Stream: Sustainable memory bandwidth in high performance computers. http://

www.cs.virginia.edu/stream/.

[9] Wiki page: Berkeley packet filter. http://en.wikipedia.org/wiki/Berkeley_

Packet_Filter.

[10] Wiki page: Erzeuger-verbraucher-problem. http://de.wikipedia.org/w/index.

php?title=Erzeuger-Verbraucher-Problem&oldid=54553501.

[11] Wiki page: List of device bandwidths. http://en.wikipedia.org/wiki/List_of_

device_bandwidths.

[12] Wiki page: Speicherdirektzugriff. http://de.wikipedia.org/wiki/Direct_

Memory_Access.

[13] Wiki page: Watchdog. http://de.wikipedia.org/w/index.php?title=

Watchdog&oldid=67172973.

[14] Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman. Linux Device Dri-vers, volume 3. O’Reilly Media, 2005. http://lwn.net/Kernel/LDD3/.

[15] Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman. Linux Device Dri-vers, volume 3, chapter Lock-Free Algorithms, pages 123–124. O’Reilly Media, 2005.http://lwn.net/Kernel/LDD3/.

[16] Intel Corporation. FreeBSD Kernel Interfaces Manual EM(4), 2008. http:

//www.freebsd.org/cgi/man.cgi?query=em&apropos=0&sektion=0&manpath=

FreeBSD+8.0-RELEASE&format=html.

[17] Luca Deri. Improving passive packet capture: Beyond device polling. NETikos S.p.A,2004. luca.ntop.org/Ring.pdf.

[18] freebsd.org. SYSCTL(8) FreeBSD System Manager’s Manual, 2007.http://www.freebsd.org/cgi/man.cgi?query=sysctl&apropos=0&sektion=

0&manpath=FreeBSD+8.0-RELEASE&format=html.

[19] Intel. Interrupt moderation using intel GbE controllers. Technical report, Intel, 2007.

[20] Intel. PCI/PCI-X Family of Gigabit Ethernet Controllers Software Developer’s Ma-nual, 4.0 edition, 2009.

[21] Van Jacobson, Craig Leres, and Steven McCanne. FreeBSD Subroutines: pcap- Packet Capture library, 2004. http://www.freebsd.org/cgi/man.cgi?query=

pcap&apropos=0&sektion=3&manpath=FreeBSD+7.2-RELEASE&format=html.

[22] Mario Zagar Marko Zec, Miljenko Mikuc. Estimating the impact of interrupt coales-cing delays on steady state TCP throughput. Technical report, University of Zagreb,Faculty of Electrical Engineering and Computing, 2002.

[23] Steven McCanne and Van Jacobson. The bsd packet filter: A new architecture foruser-level packet capture. Lawrence Berkeley Laboratory, 1992. www.rawether.net/support/bpf-usenix9.pdf.

[24] Steven McCanne and Van Jacobson. FreeBSD Kernel Developers Manual: BerkeleyPacket Filter, 2007. http://www.freebsd.org/cgi/man.cgi?query=bpf&apropos=

0&sektion=0&manpath=FreeBSD+7.2-RELEASE&format=html.

[25] Steven McCanne and Van Jacobson. FreeBSD Kernel Interfaces Manual: BerkeleyPacket Filter, 2007. http://www.freebsd.org/cgi/man.cgi?query=bpf&apropos=

0&sektion=0&manpath=FreeBSD+7.2-RELEASE&format=html.

[26] M. McKusick and G. Neville-Neil, editors. Design and Implementation of the FreeBSDOperating System, The. Addison Wesley, 2004.

[27] Hans-Peter Messmer, editor. PC Hardware. Aufbau, Funktionsweise, Programmie-rung. Addison Wesley, 1997.

[28] Jeffrey Mogul and K.K. Ramakrishnan. Eliminating receive livelock in an interrupt-driven kernel. ACM Transactions on Computer Systems, 15:217–252, 1997. http:

//portal.acm.org/citation.cfm?id=263335.

[29] Jeff Roberson. Ule: A modern scheduler for freebsd. 2003. http://www.usenix.org/event/bsdcon03/tech/full_papers/roberson/roberson.pdf.

[30] Jeffrey Roberson. FreeBSD General Commands Manual: CPUSET(1), 2008.http://www.freebsd.org/cgi/man.cgi?query=cpuset&apropos=0&sektion=

0&manpath=FreeBSD+7.2-RELEASE&format=html.

[31] Andreas Schmidt. Linked list DMA descriptor architecture, 2004. http://www.

freepatentsonline.com/6782465.pdf.

[32] Fabian Schneider. Performance evaluation of packet capturing systems for high-speednetworks. Master’s thesis, Technische Universitat Munchen, 2005. http://www.net.t-labs.tu-berlin.de/papers/S-PEPCSHN-05.pdf.

[33] Fabian Schneider and Jorg Wallerich. Performance evaluation of packet capturingsystems for high-speed networks. ACM Press, pages 284–285, 2005. http://www.

net.t-labs.tu-berlin.de/papers/SW-PEPCSHN-05.pdf.

[34] Fabian Schneider, Jorg Wallerich, and Anja Feldmann. Packet capture in 10-gigabitethernet environments using contemporary commodity hardware. Lecture Notes inComputer Science, 4427:207–217, 2007. http://www.net.t-labs.tu-berlin.de/

papers/SWF-PCCH10GEE-07.pdf.

[35] Yar Tikhiy. FreeBSD Kernel Developers Manual: mbuf – memory management inthe kernel IPC subsystem, 2007. http://www.freebsd.org/cgi/man.cgi?query=

mbuf&apropos=0&sektion=0&manpath=FreeBSD+7.2-RELEASE&format=html.

[36] Uppsala Universitat. pktgen the linux packet generator, 2004. ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/pktgen_paper.pdf.

Listings

1 RING-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 RING-SLOT-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 ADDRESS-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 Code-Eintrage in Dateien des generischen em-Treiber . . . . . . . . . . . . . 415 Initiierung von Memory-Mapping . . . . . . . . . . . . . . . . . . . . . . . . 446 Funktion zur Ausschaltung des Flow-Control-Mechanismus. Die Funktion

wird im ringmap-Treiber verwendet. . . . . . . . . . . . . . . . . . . . . . . 50

optimierung des freebsd-packet-capturing-stacks filediplomarbeit optimierung des...

Documents