3.6 Case studies
3.6.1 Integrazione con OpenvSwitch
Nel seguito si cercheranno di valutare le prestazioni ottenibili da due sistemi che utilizzeremo come casi di studio, discutendo delle modifiche necessarie per ottenere delle buone prestazioni.
Il nostro primo esempio riguarda OpenvSwitch [54], un’implementazione software di uno switch layer-2 progettato per essere scalabile. Come molti sistemi di switching/routing moderni, OpenvSwitch (Figure 3.10) gestisce in modo separato il datapath che effettua le vere e proprie operazioni di switch dal controller, che `e in grado di gestire e controllare le tabelle di forwarding per il data plane. L’utilizzo di questo software come caso di studio `e interessante in quanto le operazioni che deve fare lo switch sui pacchetti sono abbastanza semplici, e l’effetto dovuto all’overhead del sistema operativo `e un componente rilevante sulle prestazioni del sistema e potrebbe beneficiare dal frameworknetmap. Inoltre OpenvSwitch supporta anche un datapath in user space permettendo di valutare le sue prestazioni nei casi kernel e user space.
Communication channel Interfaces
ofproto
datapath
OpenFlow protocolController
fast path slow path packet arrivalFigura 3.10: Struttura di OpenvSwitch, rappresentazione del flusso del traffico nel sistema.
Architecture
Il datapath implementa le funzionalit `a di base di uno switch Ethernet, con l’aiuto di una flow table locale che permette di decidere dove saranno diretti i pacchetti in ingresso. Se per un pacchetto in ingresso si ha un match nella flow table, esso viene processato direttamente nel datapath (il “fast path” indicato in figura) e viene inviato all’interfaccia di destinazione. I pacchetti per cui non si ha un match nella flow table, o che richiedono delle operazioni pi `u complesse, sono inviati al controller con l’aiuto di un altro modulo (chiamato “ofproto” nella figura). Quando i pacchetti vengono inviati al controller richiedono un utilizzo maggiore di risorse. Questo percorso `e chiamato “slow path”. Ad esempio, lo slow path `e utilizzato per i pacchetti che arrivano per la prima volta allo switch, quindi con un indirizzo sorgente (o destinazione) mai visto. Questi pacchetti sono inviati al controller che in base ad un qualche algoritmo decide la destinazione del pacchetto e aggiorna la flowing table, in modo tale da evitare lo slow path per i pacchetti successivi.
In Figura 3.11 viene descritta in dettaglio l’interazione tra il datapath e i blocchi ofproto. Il primo si oc- cupa di effettuare solo lo switch dei pacchetti, mentre l’ultimo gestisce lo slow path, la comunicazione con il controller e tutti gli eventi che avvengono sulle interfacce.
La distribuzione originale di OpenvSwitch fornisce due diverse implementazioni per il datapath: una im- plementata come un modulo del kernel di Linux, e un’altra come un componente userspace, sempre per Lunux, che utilizza le API del socket PF PACKET per scambiare pacchetti. Per gli esperimenti condotti per questo lavoro `e stato implementato un ulteriore modulo per il datapath, funzionante sul sistema FreeBSD e che utilizza la libreria di I/Olibpcap.
Flow table
Communication
channel
Interfaces
packets OpenFlow protocol flo table modificationFigura 3.11: La comunicazione tra il datapath e il blocco ofproto in OpenvSwitch.
Prestazioni del modulo nativo
Determinare le prestazioni del sistema base `e un passo fondamentale nel riuscire a valutare i miglioramenti che si hanno introducendo un meccanismo diverso di gestione dei pacchetti.
Per questo motivo per tutti i test argomento di questo documento sono stati utilizzati due sistemi con CPU Intel i7-870 (4 core, ma solo uno `e stato utilizzato nei test) con frequenze fino a 2.93 GHz. Ogni sistema ha pi `u interfacce di tipo Ethernet compresa una scheda dual-port 10 Gbit montata su un bus PCI express con 8 lanes, che permette di sostenere il traffico generato dalle interfacce10. Questa `e la stessa piattaforma utilizzata in [58] e per cui, nel Paragrafo 3.5, `e stato misurato un rate di forward di 7 Mpps in pi `u con l’uso di netmapcap.
La configurazione di OpenvSwitch utilizzata negli esperimenti `e un caso molto semplice che coinvolge un traffico di pacchetti da 64-byte unidirezionali, in un sistema composto da due sole interfacce. Le prestazioni di questo sistema naturalmente sono soggette anche ad un degrado delle prestazioni che dipende dal numero di interfacce presenti nel sistema, ma test che coinvolgano questi effetti non `e negli scopi di questo studio. Analogamente anche il comportamento del sistema con la presenza di flussi multipli e un’alta percentuale di traffico diretta al controller `e presentato in [54] ma non `e di interesse in questo studio.
I risultati dei primi test effettuati non hanno dato i risultati sperati, come si evince dalla tabella in Figu- ra 3.12. L’utilizzo della versione userspace di OpenvSwitch non porta ad avere grosse aspettative sui risultati, ma i valori ottenuti, di 50-65 Kpps sono almeno un ordine di grandezza inferiori rispetto ai risultati attesi. Anche la versione nel kernel non ha fatto emergere ottimi risultati, raggiungendo circa 300 Kpps, confrontata con le prestazioni del bridge nativo di FreeBSD di circa 690 Kpps.
Le prestazioni di OpenvSwitch riportate in letteratura non sono state utili ai nostri scopi. Pfaff [54, Section 4.2] confronta OpenvSwitch e il Bridging di Linux in varie condizioni. Con flussi di grandi dimensioni, in modo da rendere trascurabile l’overhead del controller, viene riportata una velocit `a di circa 450 Mbit/s: circa la met `a della velocit `a del link utilizzato nel test. Le dimensioni dei pacchetti utilizzate per questi test non sono riportate, probabilmente si tratta di flussi TCP, quindi con pacchetti da 1500-byte, che portano a risultati di circa 37.5 Kpps.
10Una banda sufficiente sul bus PCIe non implica che il NIC sia effettivamente in grado di operare alla velocit `a della rete
in tutte le condizioni. Come mostrato in [58], ci sono molti casi in cui il NIC non `e in grado di gestire i pacchetti alla velocit `a permessa dalla rete, anche se la CPU ed il bus possano permetterlo.
Linux userspace 50 FreeBSD userspace 65
Linux Kernel 300
Other systems
Configuration Kpps original Click userspace 400 native FreeBSD bridging 690 netmapcap forwarding 7,500 netmap forwarding 9,660
Figura 3.12: Prestazioni del forward dell’implementazione originale di OpenvSwitch e confronto con altre soluzioni.
La ricerca dei colli di bottiglia sulle prestazioni
Le scarse prestazioni ottenute in userspace hanno portato ad investigare sulle possibili fonti del problema. L’analisi dell’implementazione in userspace ha rivelato subito il problema: la versione del software utilizzata (dichiarata sperimentale dagli sviluppatori) gestiva gli eventi relativi al datapath e a ofproto in un unico loop come evidenziato in Figura 3.11. Questo vuol dire che il main loop deve essere in grado di gestire un numero elevato di file descriptors piuttosto che solo quelli relativi alle interfacce, e questo rende ogni iterazione molto lenta. In aggiunta a questo ogni passo del loop processa al massimo un pacchetto alla volta, richiamando tutti gli handler dei file descriptor, anche in assenza di pacchetti da elaborare.
Questo problema `e stato risolto utilizzando un thread apposito per implementare le funzioni del datapath e permettendo di processare pi `u di un pacchetto per interfaccia ad ogni iterazione. Sebbene concettualmente rilevante, l’intervento sul codice non ha comportato modifiche eccessive al programma. L’eventloop principale `e rimasto invariato, eccetto il fatto che il file descriptor relativo all’I/O dei pacchetti viene ora gestito dal thread del datapath. Le notifiche tra i due thread sono gestite utilizzando una pipe unix (i cui endpoing possono essere utilizzati come argomenti alla chiamatapoll()nei due eventloop) con cui sono scambiati i pacchetti dati che devono percorrere lo slow path e gli altri messaggi.
Con queste modifiche, le prestazioni raggiungono dei livelli ragionevoli: con l’utilizzo della libreria standard libpcap, il throughput `e tra 383 e 783 Kpps (Figura 3.13, colonna centrale) dipendente dal massimo numero di pacchetti per NIC (batch size) che processiamo ad ogni iterazione) Queste misure verranno prese come riferimento nel valutare le prestazioni introdotte dalla libreria ottimizzata dinetmap.
OpenvSwitch con netmapcap
In questo paragrafo verranno discusse le prestazioni ottenute utilizzando l’applicazione OpenvSwitch con l’utilizzo della libreria ottimizzata. Per questi test sarebbe necessario rimpiazzare le routine del kernel per l’I/O con la libreria dinetmap, ma grazie al layer realizzato di netmapcap `e bastato rimpiazzare la libreria di sistema libpcap con la versione apposita descritta nel Paragrafo 3.5. I risultati sono riportati nella colonna a destra della Tabella 3.13, e rappresentati in Figura 3.14. Cos`ı come si vede dai dati, il sistema `e da tre a quattro volte pi `u veloce, anche con batch di 50 pacchetti.
L’elemento che ha un maggiore impatto sulle prestazioni `e proprio la dimensione del batch utilizzato, quindi risulta conveniente incrementare il valore di questo parametro. Un problema che si potrebbe avere uti- lizzando batch di grosse dimensioni `e che i pacchetti possono essere spostati tra varie interfacce, generando overflow in caso di code troppo piccole. In pratica ad alti rate, i ring hanno delle dimensioni elevate, (256 o pi `u
1 373 250 2 510 466 3 579 619 5 638 882 10 709 1430 20 744 1970 50 764 2500 100 775 2730 500 781 2960
Figura 3.13: Prestazioni di forwarding del codice ottimizzato di OpenvSwitch con differenti dimensioni di batch e librerie di I/O.
0
500
1000
1500
2000
2500
3000
1
10
100
1000
Throughput (Kpps)
Batch size
netmapcap
libpcap
Figura 3.14: Prestazioni di forwarding del codice ottimizzato di OpenvSwitch (dati dalla Figura 3.13).
Il motivo per cui le prestazioni dinetmapcapcon dei valori di batch piccoli non sono migliori dilibpcappu `o non essere rilevante da un punto di vista operativo, ma lo `e sicuramente da un punto di vista accademico. I test effettuati hanno riguardato traffico di tipo unidirezionale, quindi uno dei descrittori passati alla funzione di sistemapoll()corrisponde ad un ring vuoto, e l’handler di basso livello, quando il ring `e vuoto, risulta essere molto pi `u costoso innetmap rispetto a quanto lo `e inlibpcap. Questo spiega la differenza di prestazioni con bassi valori di batch size. Eseguendo lo stesso test con una dimensione di batch di 1 e traffico di tipo bidirezionale si ottengono prestazioni fino a 900 Kpps per ogni direzione, che `e perfettamente in linea con le prestazioni attese.
Infine occorre evidenziare che le alte velocit `a raggiunte connetmapcapsono il risultato di una ulteriore riprogettazione del nuovo frameworknetmapnell’ottica di poter emulare in modo efficiente le API della libreria libpcap. L’eventloop della versione originale dinetmaprichiedeva una chiamata di sistema addizionale per ogni iterazione, utilizzata per recuperare il timestamp, e una chiamata per ogni interface/loop per inviare i pacchetti che sono poi accodati sul ring. Dopo un’accurata analisi sull’utilizzo pi `u frequente della API di netmap `e emersa l’esigenza di introdurre una serie di feature che permettono, ad esempio, di avere dalla poll()su un file descriptor dinetmapun timestamp aggiornato (che viene utilizzato da molti client libpcap) e l’invio dei pacchetti gi `a accodati sulla coda di trasmissione del ring associato al file descriptor.
Efficienza, non solo velocit `a
Le prestazioni di molte applicazioni sono in genere valutate dalla loro velocit `a di picco. In questo lavoro l’obiettivo non `e quello di misurare le velocit `a ottenibili dall’hardware cercando di farlo lavorare il pi `u possibile, ma quello di rendere il sistema efficiente nel suo complesso. Il seguente grafico illustra il problema dai due punti di vista.
0
500
1000
1500
2000
2500
3000
0
0.5
1
1.5
2
2.5
3
Throughput (Kpps)
Clock speed (GHz)
netmapcap
libpcap
Figura 3.15: Throughput versus frequenza dell CPU per il codice ottimizzato di OpenvSwitch (batch=50).
utilizzando le due librerie `e evidente a prescindere dal valore del clock della CPU, che significa che il packet rate pu `o essere processato connetmapcapad una frequenza bassa (e quindi riducendo i consumi)11
0
20
40
60
80
100
0
500 1000 1500 2000 2500 3000
CPU usage (%)
Offered load (Kpps)
libpcap
netmapcap
Figura 3.16: OpenvSwitch: utilizzo CPU versus carico offerto alla massima frequenza.
In Figura 3.16 `e rappresentata l’occupazione della CPU (calcolata contop) con diverso carico. In gen- erale questo tipo di dati deve essere raccolto e interpretato con cautela, in quanto pu `o essere affetto da errori. Ad esempio, la curva `e particolarmente rumorosa e devia dall’andamento che ci si aspetta, fondamen- talmente per due ragioni: i) innanzitutto la nostra sorgente ha un andamento a burst; il device driver utilizza l’interrupt mitigation [50], che aiuta a ridurre il carico della CPU ma pu `o causare dei fenomeni di sincroniz- zazione con la sorgente stessa; ii) i tick della CPU sono conteggiati tramite campionamento, ed, in base alle tempistiche, c’ `e la possibilit `a che si riferiscano al processo sbagliato.
Tenendo conto di tutto ci `o, le informazioni (almeno qualitativamente) che possiamo ricavare dalla Figu- ra 3.16 `e che l’esecuzione dinetmapcaputilizza circa 1/3 delle risorse CPU utilizzate con la libreria standard libpcap. Inoltre, occorre far notare che, anche nel caso in cui la CPU raggiungesse un carico del 100%, il sistema non raggiunge la saturazione. A questo livello infatti c’ `e un fenomeno di auto-adattamento per cui l’elaborazione in userspace impiega troppo tempo, causando poche chiamate di sistema, le quali ritornano batch di pacchetti lunghi, quindi un numero minore di chiamate che generano un basso overhead per pac- chetto. Il fenomeno `e pi `u evidente senza interrupt mitigation (non `e per `o il nostro caso), dove in genere il 100% di utilizzo `e raggiunto molto dopo il picco di rate di forward.