Performances du r´ eseau

Mˆeme si la partie du syst`eme qui nous concerne ici est le traitement des donn´ees par le processeur graphique, il est int´eressant d’avoir une id´ee des capacit´es de traitement des flux r´eseau par le syst`eme d’exploitation, Linux dans notre cas. Nous l’utilisons pour cr´eer un pont r´eseau entre deux cartes Ethernet, filtrer le trafic selon les r`egles des ebtables pr´esent´ees `

a la section 3.1.3, et copier le trafic restant pour le transmettre `a notre application (voir section 3.1.1). Nous allons ´etudier ici les performances sur un r´eseau 10 Gb/s pour donner un aper¸cu des avantages et inconv´enients de cette m´ethode.

4.2.1 Pont r´eseau

Pour mesurer la capacit´e de Linux `a g´erer un pont entre deux r´eseaux, nous avons mis en place deux serveurs communiquant entre eux et g´en´erant ainsi du trafic `a pr`es de 10 Gb/s. Nous avons mesur´e le d´ebit moyen des donn´ees transmises avec et sans serveur interm´ediaire. Les r´esultats sont repris dans le tableau 4.3 et montrent que la gestion par Linux est assez efficace pour interconnecter deux r´eseaux sans causer de ralentissement. On observe une l´eg`ere augmentation de la latence.

Le tableau montre ´egalement que le syst`eme d’exploitation assigne une priorit´e tr`es ´elev´ee au pont r´eseau car les performances restent identiques lorsque le processeur est tr`es occup´e. On visualise l’impact sur le processeur en suivant l’activit´e de programme qui chargent les cœurs du processeur `a 100%. En effet, lorsque du trafic r´eseau doit ˆetre trait´e, les programmes sont pr´eempt´es, ne disposant plus que de 86% du temps CPU. Ceci tend `a montrer qu’`a d´ebit maximal, la gestion du pont r´eseau seule utilise 14% de la puissance de calcul des processeurs, ce qui ´etait pr´evisible puisque tout est g´er´e en logiciel.

Ici revient l’int´erˆet d’utiliser un p´eriph´erique d´edi´e et sp´ecialis´e, pour g´erer le r´eseau et d´echarger le processeur de cette tˆache. Les cartes r´eseau haut de gamme peuvent mˆeme offrir

Tableau 4.3 – Performances du pont r´eseau

´

Etat du serveur interm´ediaire D´ebit moyen Ping moyen R´ef´erence : connexion directe 8.85 Gb/s 0.1 ms

Libre (charge  0.1%) 8.85 Gb/s 0.3 ms

Occup´e (charge 100%) 8.85 Gb/s 0.2 ms

Avec copie du trafic 8.85 Gb/s 0.3 ms

Filtrage (100 r`egles) 8.85 Gb/s 0.3 ms

cette fonction en mat´eriel, ne n´ecessitant alors pas de p´eriph´eriques externes. 4.2.2 Copie du trafic

En plus de simplement relier les deux ports Ethernet, le syst`eme d’exploitation doit aussi passer les paquets de donn´ees `a notre application d’analyse, ce qui charge encore le processeur. Nous avons repris la mˆeme plateforme de test que pr´ec´edemment en ajoutant le processus de copie des paquets vers un buffer d´edi´e `a une application.

Notons que la copie des donn´ees depuis la m´emoire de la carte r´eseau jusqu’`a la m´emoire de la carte graphique passe par le bus PCIe. Il serait envisageable de les faire communiquer directement en DMA, ne passant alors pas du tout par la m´emoire vive du CPU. Mal- heureusement NVidia ne donne ni acc`es `a la gestion du bus, ni directement `a la m´emoire de ses cartes, et nous sommes donc oblig´es de travailler avec la m´emoire centrale comme interm´ediaire.

La copie des donn´ees depuis la carte r´eseau que nous avons pr´esent´e au paragraphe 4.1.2 peut, elle aussi, ˆetre r´ealis´ee selon diff´erentes m´ethodes. En effet, par d´efaut, le syst`eme d’exploitation lit les paquets et les copie dans sa m´emoire (qui lui est r´eserv´ee et n’est pas accessible aux applications). On utilise alors des applications telles que pcap pour r´ecup´erer une copie de cette m´emoire dans l’espace utilisable par l’application. Il existe cependant des alternatives telles que ntop [17], qui fonctionnent de la mˆeme fa¸con que pcap, mais direc- tement avec le driver de la carte r´eseau. Les paquets peuvent alors ˆetre copi´es directement vers l’application, allant mˆeme jusqu’`a outrepasser le syst`eme d’exploitation, qui ne voit donc plus de trafic. Il faut alors ˆetre sˆur de pouvoir g´erer le pont r´eseau et le filtrage autre- ment. Ces solutions peuvent ˆetre beaucoup plus efficaces car plus directes, mais demandent aussi un plus grand travail de mise en place pour des fonctions que le syst`eme d’exploitation fournissait tr`es simplement. Des tests effectu´es sur une plateforme ´equivalente `a la nˆotre ont permis de r´ecup´erer tout le trafic `a 10 Gb/s [16].

Analyser les possibilit´es de notre mat´eriel et les alternatives `a pcap apr`es avoir optimis´e la partie GPU serait tr`es int´eressant. En utilisant la librairie pcap, on parvient `a r´ecup´erer l’ensemble du trafic jusqu’`a 7.3 Gb/s.

4.2.3 Filtrage

Comme nous l’avons expliqu´e, le filtrage est effectu´e par le syst`eme d’exploitation et charge le processeur. Les essais montrent en effet l’impact des ebtables sur les performances du pont r´eseau, les r´esultats sont ajout´es au tableau 4.3.

0 0.5 1 1.5 2 2.5 3 3.5 0 10 20 30 40 50 60 70

Nombre de règles présentes (x10 000)

Temps d’aj

out/suppression d’une règle (m

s)

Figure 4.6 – Latence des ebtables

port´ees, le mode d’ajout ou encore la latence entre la demande d’ajout et la mise en place effective. Les ebtables peuvent prendre en compte 32 762 r`egles sur notre syst`eme de test. On mesure que la latence de l’ajout ou la suppression d’une r`egle est globalement propor- tionnelle au nombre de r`egles existantes, comme le montre la figure 4.6. Cette latence est assez importante, entre 5 ms et 70 ms. On ne pourra donc utiliser efficacement ce syst`eme qu’avec un petit nombre de r`egles de blocage.

Minimiser la latence entre l’arriv´ee d’un paquet et la mise en place de la r`egle de fil- trage correspondante est en effet primordial. Nous bloquons une communication `a partir du moment o`u des donn´ees interdites ont ´et´e rep´er´ees `a l’int´erieur. En travaillant `a de tr`es hauts d´ebits, chaque cycle pass´e dans le traitement retarde l’application du blocage et laisse l’utilisateur transf´erer beaucoup de donn´ees. Si le traitement est trop long, le transfert du fichier peut ˆetre termin´e avant que le blocage n’ait ´et´e mis en place.

Nos tests de filtrage ont montr´e une latence comprise entre 7 et 40 ms, l’´ecart entre les mesures ´etant du au temps de remplissage du buffer d’entr´ee. Avec de telles latences, on peut ais´ement bloquer les communications classiques (chargement d’images, lecture de vid´eos) sur Internet, les utilisateurs ne pouvant alors t´el´echarger leur contenu que pendant les quelques millisecondes du traitement du premier paquet suspect.