3.6 Case studies
3.6.2 Integrazione con Click
Il secondo caso studiato `e rappresentato dalla versione userspace del router modulare Click. Click [41] `e una piattaforma popolare per la definizione di sistemi in grado di processare pacchetti. Click permette all’utente di
11Il comportamento superlineare tra gli ultimi due punti (2.8 and 2.93 GHz) `e dovuto alla modalit `a “Turbo Boost” che
la CPU utilizza ad alte velocit `a. La CPU incrementa in modo autonomo la frequenza a 3.2 GHz, naturalmente se la temperatura lo permette. Per questo motivo il rate nominale a 2.93 GHz non coincide con la frequenza effettiva del clock.
`e libero di creare nuovi componenti, specifici per la propria elaborazione. Le porte di input e output sono utilizzate per il trasferimento dei pacchetti di dati, utilizzando dei meccanismi di tipo push o pull. Una porta di tipo push non `e altro che una chiamata alla funzione che processa un pacchetto in downstream; una porta di tipo pull implica un polling sulla porta di upstream per estrarre tutti i pacchetti disponibili. Tra l’insieme di elementi standard definiti da Click, ne abbiamo alcuni direttamente connessi alle interfacce hardware, in modo tale da iniettare il traffico di rete reale nel grafo di flusso definito da Click.
Figura 3.17: Configurazioni di Click create connettendo elementi in grado di effettuare diverse funzioni.
Click pu `o essere eseguito in due diversi ambienti: la versione userspace con un semplice processo (o un set di thread nelle versioni di Click pi `u recenti) che accede ai dispositivi utilizzando le librerielibpcapo equivalenti. La versione in-kernel, che `e la pi `u nota, non presenta differenze per quanto riguarda le funzionali `a fornite, ma eseguendo in kernel space `e in grado di accedere alle interfacce di rete utilizzando degli elementi (PollDevice and ToDevice) con prestazioni molto maggiori rispetto al corrispettivo in user space.
Nelle versioni attuali di Click ci sono degli elementi altamente ottimizzati, che utilizzano polling, pre- fetching e batching che permettono di ottenere delle prestazioni maggiori rispetto alle prestazioni dei device driver nativi.
In letteratura sono riportati dei rate di invio/ricezione per una configurazione kernel di Click, indicando dei rate fino a 3-4 Mpps per core. Questi valori non sono immediatamente confrontabili con quelli riportai nei vari paper, a causa delle diverse configurazioni tra i vari sistemi, ma in generale le performance di Click superano di 2-3 volte le prestazioni native di Linux. Data la convenienza di utilizzare la versione user space, sarebbe utile ottimizzare la versione user space dello strumento, con l’obbiettivo di raggiungere le stesse prestazioni della versione in kernel space.
Usermode Click - performance native
Cos`ı come gli altri case studies, occorre determinare le prestazioni del forwarding di una versione di Click non modificata in esecuzione in user space. Nei test effettuati viene utilizzato lo stesso hardware usato per i test di OpenvSwitch, ed `e stato utilizzato Click 1.8.0 con modifiche minimali per utilizzare la librerialibpcap su FreeBSD. In tutti i test `e stato utilizzato un singolo thread. La configurazione di Click `e molto semplice12:
FromDevice(ix0) -> Queue -> ToDevice(ix1) FromDevice(ix1) -> Queue -> ToDevice(ix0)
e replica il setup degli esperimenti condotti nel Paragrafo 3.5 dove veniva effettuato il forward diretto tra interfacce.
12I dettagli della configurazione vengono omessi, come ad esempio l’impostazione della scheda in modalit `a promiscua,
libpcap - 400 netmapcap - 1300 kernel (est.) - 3-4000 Modified Click version Burst Kpps libpcap 1 490 libpcap 50 495 netmapcap 1 3300 netmapcap 50 3950
Figura 3.18: Prestazioni di Click in user space in varie configurazioni, I risultato di Click in-kernel sono ricavati dalla letteratura.
In questa configurazione, il forwarding unidirezionale, raggiunge circa 400 Kpps, che `e vicino al through- put di altre applicazioni in user space che utilizzano libpcap. Questi risultati non portano a sospettare l’e- sistenza di altri colli di bottiglia, sebbene i problemi descritti di seguito richiedano comunque una maggiore investigazione.
Click ha uno scheduler interno che decide quale elemento occorre schedulare. Gli elementi girano in un ambiente di multitasking cooperativo, effettuando solo attivit `a non bloccanti, e poi ritornano allo scheduler, indicando se sono o no pronti ad un’altra iterazione. La quantit `a di lavoro fatta da ogni elemento dipende dall’elemento stesso, ma in molti casi corrisponde a processare solo un pacchetto dall’input all’output (e in caso di un elemento di tipo push, questo pu `o causare la chiamata diretta ad una funzione dell’elemento di downstream e cos´ı via). Alcuni elementi hanno un parametro BURST che decide quanti pacchetti vengono processati. Questa modalit `a operativa implica che l’esecuzione degli elementi viene effettuata insieme allo scheduler, e l’ultima costituisce un costo aggiuntivo che pu `o essere ridotto (ammortizzandolo) da valori di BURST pi `u alti. Il beneficio dipende chiaramente dal costo dell’operazione di scheduling confrontata con quella di esecuzione dell’elemento stesso.
L’elemento “ToDevice” relativo al dispositivo di output di default non ha un parametro che consente di impostare un valore per il BURST, precludendo la possibilit `a di effettuare alcune tipologie di test. Tuttavia i 400 Kpps raggiunti corrispondono a circa 2500 ns per pacchetto, molto pi `u elevati del costo di una decisione dello scheduler. Da qui quello che ci si aspetta, almeno per la configurazione degli esperimenti qui descritti: cambiamenti del valore di BURST non dovrebbero influenzare le prestazioni in modo considerevole.
In assenza di elementi pronti lo scheduler chiamapoll()attendendo un timeout oppure che un disposi- tivo diventi pronto. A differenza di OpenvSwitch, una modifica della dimensione di BURST non influisce sulla frequenza con cui viene invocata la poll(), in quando viene invocata solo quando non ci sono elementi pronti.
Click con netmapcap
Un primo test effettuato rimpiazzandolibpcap connetmapcapda un incremento delle prestazioni fino a 1.3 Mpps, circa tre volte pi˘‘ veloce rispetto al sistema originale di packet I/O. Senza altre informazioni si penserebbe di aver raggiunto un ottimo valore per quanto riguarda le prestazioni. Tuttavia considerando che Click `e configurato in modo da effettuare task molto pi `u semplici di quelli di OpenvSwitch, ci si aspetterebbe un risultato quantomeno simile, cio `e sui 2.5-3 Mpps.
Come primo possibile collo di bottiglia `e stato considerato lo scheduler, ed `e stato modificato l’elemento “ToDevice” aggiungendo un parametro di BURST in modo tale da processare i pacchetti ad ogni invocazione.
di sistema, sulla presenza di lock o su operazioni simili che possano introdurre latenza.
La risoluzione di questo problema ha richiesto un po’ di tempo in pi `u rispetto all’analisi di OpenvSwitch, dal momento che la causa del problema non `e stata individuata immediatamente, in quanto non `e emerso niente di rilevante dal codice: C++ che implementa gli elementi di Click. Un aiuto significativo nella ricerca del collo di bottiglia si `e avuto dall’analisi delle prestazioni in una configurazione molto pi `u semplice, che ha rimpiazzato uno o entrambi i dispositivi “FromDevice” e “ToDevice” con degli elementi “InfiniteSource” e “Sink”. Questi elementi non effettuano nessuna operazione di device I/O, e anche dopo aver rimosso la chiamata di sistema (gettimeofday()) che in genere riduce le prestazioni delle applicazioni di rete, la velocit `a resta sotto i valori che ci si aspettano. Questo comportamento ha spostato l’attenzione all’unica operazione ancora non analizzata, l’allocatore di memoria, che `e risultato essere la vera fonte di inefficienza.
In Click, ogni Pacchetto (un oggetto C++ definito dagli utenti) richiede l’allocazione di due blocchi di memoria, uno per il descrittore e uno per il payload. Queste allocazioni sono fatte attraverso l’allocatore standard C++, che probabilmente richiede un lock per ogni allocazione, ed `e anche progettato per oggetti di dimensione variabile. I pacchetti di Click possono essere facilmente implementati con oggetti di dimensioni fisse, e la memoria allocata pu `o essere riutilizzata per ogni thread senza ricorrere alla gestione centralizzata dell’allocatore C++.
Applicando queste modifiche al codice generico di Click, esso incrementa il throughput a 490 Kpps quan- do viene eseguito sulibpcap, ed a 3.3 Mpps connetmapcap, sempre utilizzando un valore di BURST pari a 1. A queste velocit `a l’influenza dello scheduler potrebbe essere significativa, quindi occorre effettuare nuovi test utilizzando un valore maggiore di BURST. Incrementando il valore di BURST fino a 50 si ottiene una ve- locit `a di circa 4 Mpps. Queste prestazioni in user space e con l’utilizzo di un core singolo, `e simile o superiore a configurazioni di Click in esecuzione nel kernel.
La Figura 3.18 confronta i risultati ottenuti tra la versione di Click originale e quella modificata, in varie con- dizioni operative. Come si vede, `e stato raggiunto un miglioramento di circa 10 volte rispetto alle prestazioni originali, e anche in questo caso un aiuto significativo `e venuto dalla rimozione di un collo di bottiglia sot- tostimato e non dal sistema di Packet I/O. Le modifiche effettuate sono state integrate nella distribuzione pi `u recente di Click (Click 2.0).