PROJET DE FIN D ETUDES

Transcription

1 Option ASR 2005/2006 PROJET DE FIN D ETUDES Interface de communication pour les réseaux InfiniBand Etudiants Aïchatou RABBA Nadir GHEZALI Responsable Guy Bernard Encadrants Eric RENAULT Ouissem BEN FREDJ

2 SOMMAIRE I. Introduction II. Présentation d InfiniBand. II.1- Grappes & Grids.... II.2- Solutions d interconnexion II.2.1- Ethernet (100BaseT et GigaByte Ethernet) II.2.2- Myrinet II.2.3- InfiniBand II Le Subnet.. II Les liens II Les Switchs... II Les Nœuds terminaux II Les HCA (Host Channel Adapter). II Les TCA (Target Channel Adapter).. II Subnet Manager. II.3- Support logiciel dans les grappes.. II.3.1- Transferts zero-copie II.3.2- RDMA (Remote Direct Memory Access) II.3.3- Modèle de communication... II.4- Types de services de transfert. II.4.1- RC (Reliable Connected) QP.. II.4.2- UC (Unreliable Connected) QP.. II.4.3- RD (Reliable Datagram) QP II.4.4- UD (Unreliable Datagram) QP II.4.5- Raw QP.. II.5- Types de transfert II.5.1- RMDA Read II.5.2- RDMA Write. II.5.3- Send inlined II.5.4- Send II.6- Gestion des communications III. Interface Rwapi.. III.1- Modèle de programmation. III.2- Routine d initialisation d interface III.3- Gestion de la topologie. III.4- Allocation mémoire III.5- Envoi de messages III.6- Contrôle des messages III.7- Contrôle des messages par interruption.. 2

3 IV. Conception.. IV.1- Initialisation IV.2- Gestion de la topologie... IV.3- Envoi de messages. IV.3.1. Choix du type de transfert IV.3.2 Le mode de transfert et les fonctions d envoi de message. IV.4- Contrôle des messages IV.5- Contrôle des messages par interruption V. Validation et tests de performance. V.1- Benchmark des tests V.1.1- La latence. V.1.2- La bande passante utile..... V.2-Interpretation des résultats.. V.2.1- La latence.. V.2.2- La bande passante utile VI. Conclusion et perspectives 3

4 I. Introduction Aujourd'hui, il est possible de construire des grappes de plus d'un millier de processeurs pour un coût moindre. On constate, à l'heure actuelle, une véritable explosion du nombre de grappes et des supercalculateurs. La plupart des grappes de stations dédiées au calcul parallèle utilisent des réseaux comme Ethernet, Myrinet et tout récemment InfiniBand pour transférer des données entre les mémoires des différents nœuds. Le projet s inscrit dans le cadre d un travail de développement d un middleware de communication qui permet d offrir une interface unique pour plusieurs réseaux simultanément. Dans ce projet nous nous intéressons plus précisément à InfiniBand, c est à l heure actuelle le réseau le plus performant en débit et rapidité. Le but est d améliorer la latence et la bande passante utile de ce réseau en implantant une pile logicielle entre le protocole de Remote-Write et le réseau InfiniBand. Le projet s est déroulé en plusieurs étapes : Dans un premier temps, nous avons étudié le réseau InfiniBand pour la prise en main de son architecture et de ces spécificités. C est en effet une norme assez récente qui initialement devait remplacer les Bus I/O, réseau, stockage existants. Proche d IP en termes d interopérabilité et de routage, il utilise les technologies de communications les plus récentes comme RDMA et l OS-bypass. En deuxième partie nous avons étudié le protocole à implémenter à savoir Remote- Write. C est un protocole de communication sans recopie intermédiaire qui devrait nous permettre d avoir une latence moins importante et un débit plus important pour le transfert de messages avec InfiniBand. Ensuite nous avons développé une interface permettant l implémentation du Remotewrite avec la couche VAPI offerte par InfiniBand. La dernière partie concerne la validation et les tests de performance de notre interface. 4

5 II. Présentation d InfiniBand II.1- Grappes & Grilles L'idée d'une grille est d'utiliser la puissance de tous les postes qu'un parc informatique peut posséder. Un parc peut être une entreprise avec un seul site, une entreprise distribuée géographiquement, une fédération de plusieurs réseaux locaux ou internet. Les postes à utiliser peuvent être des simples PC, des supercalculateurs ou des grappes. Une grappe (ou cluster en anglais) est un ensemble de machines homogènes reliés en réseau et considérés comme une ressource unifiée de calcul. Le cluster se définit par rapport au réseau, comme un regroupement logique de plusieurs machines (parfois appelées «nœuds») qui possède un réseau isolé. Ce qui veut dire que pour une ou plusieurs machines de la grappe, il faut d abord passer par une machine frontale qui sépare le réseau de la grappe du réseau extérieur. Pour la description matérielle, un cluster comprend plusieurs nœuds (nœuds de calcul, nœuds E/S) connectés par un réseau d administration (généralement Ethernet) et par un réseau haut débit (InfiniBand, Myrinet, etc). Comme logiciel on peut trouver une distribution Linux, un système de fichier parallèle, une bibliothèque MPI et bien d autres. Voici un aperçu des statistiques actuelles du top500 datant de novembre 2005 : Les types d architecture Nombre de machines Pourcentage Nombre de De la famille d utilisation processeurs MPP ,80% Cluster % MPP (massively parallel processing) Les technologies d interconnexion Nombre de machines De la famille Pourcentage d utilisation Nombre de processeurs Myrinet % Quadrics 14 2, Gigabit Ethernet , InfiniBand 27 5,

6 II.2- Solutions d interconnexion L obtention de performances élevées lors de l exécution d applications sur des grappes a nécessité de réduire au maximum le coût des communications entre les différentes machines. A cet effet, plusieurs solutions Réseaux sont disponibles sur le marché, plus ou moins adaptées à une utilisation dans un environnement de grappes. II.2.1- Ethernet (100BaseT et GigaByte Ethernet) Protocole de connexion de Réseaux locaux le plus utilisée dans le monde, mais reste mal adaptée pour un usage dans un environnement réparti à haute performance, et ce pour plusieurs raison parmi lesquelles : Latence trop Importante. Bande passante relativement faible. Support logiciel beaucoup trop lourd avec copies successives des messages ce qui dégrade fortement les performances système. Forte consommation énergétique des adaptateurs réseau. Néanmoins, il y a un regain d intérêt pour cette technologie avec la standardisation du protocole iscsi qui peut s appuyer sur Ethernet. II.2.2- Myrinet Myrinet est le leader du marché des réseaux d interconnexion pour grappes de calcul. Il est produit par la société Myricom depuis 1995 et à été standardisé par l ANSI (ANSI/VITA ) Ses principales caractéristiques sont : Contrôle de flux, d erreurs, ainsi que l état des liens en continu. Excellent passage à l échelle. Faible latence, offrant une grande disponibilité aux applications. Architecture commutée (commutateur peut relier jusqu'à 256 noeuds) : Le routage par la source permet un transfert rapide des paquets sur le réseau physique. Liens à 250MBps (jusqu à 500MBps). Services «PIO & OS By-pass» pour s affranchir du système d exploitation pour l émission et la réception des messages en effectuant directement (au travers de la NIC) les opérations de lecture et d écriture, ce qui permet une amélioration notoire des performances. NIC programmable. II.2.3- InfiniBand InfiniBand est une norme créée à la fin des années 1990 par un consortium de nombreux constructeurs de matériel informatique afin de définir l architecture des entrées sorties de l avenir. 6

7 La norme décrit une architecture et des spécifications pour les flux de données entre processeurs et composants d E/S intelligents. InfiniBand est destinée à remplacer le bus PCI dans les serveurs, à offrir une meilleure capacité, à augmenter la capacité d extension et à améliorer la souplesse de conception des serveurs. Elle permet essentiellement de relier des serveurs, des systèmes de stockage distants et d autres composants de réseau dans une matrice contenant des commutateurs et des liens. L architecture basée sur les commutateurs peut connecter jusqu à serveurs, systèmes de stockage et composants de réseau. InfiniBand a construit une architecture de communication système, basée sur le concept de canal (et non plus sur le concept de bus partagé). Avec cette architecture, il n est plus nécessaire d avoir le matériel d interface d E/S dans le châssis du serveur : le stockage distant, l utilisation des réseaux et les connexions entre les serveurs s effectuent en reliant tous les périphériques à une matrice centrale de commutateurs et de liens. En enlevant les E/S du châssis du serveur, on en augmente la densité, ce qui permet d envisager un centre des données plus souple et évolutif puisque l on peut ajouter des nœuds indépendants à la demande. Contrairement à PCI, qui mesure les distances depuis la carte mère CPU en centimètres, la conception des canaux InfiniBand permet de placer les composants d E/S à une distance maximale de 17 mètres du serveur avec des liaisons en cuivre, de 300 mètres avec la fibre optique multimode et jusqu à 10 km avec de la fibre optique monomode. On peut ainsi obtenir des vitesses de transmissions avoisinant les 30 Gb/s. Les processeurs des cartes d interface InfiniBand sont désormais essentiellement produits par Mellanox. Les équipements réseau et logiciels sont ensuite distribués par un certain nombre de constructeurs dont TopSpin (racheté par Cisco depuis peu), Voltaire et Infinicon. Les spécifications de la norme (téléchargeables sur le site de l InfiniBand Trade Association : IBTA) précisent à la fois la mise en oeuvre matérielle et logicielle. Cependant, chaque revendeur distribue ses propres couches logicielles d accès au réseau respectant plus ou moins la norme. Le projet OpenIB ( propose une alternative libre à ces différentes distributions logicielles propriétaires. Le protocole de bas niveau est très proche de IP. La topologie n est pas fixée et le routage est effectué dans les commutateurs. La principale interface est les VERBS entre le software et la carte réseau. Les communications bas niveau profitent des capacités RDMA du matériel pour obtenir de très bonnes performances. La bande passante théorique est actuellement sont de 2,5 GBps, 10GBps voir 30GBps selon l interface utilisée (1X, 4X, 12X). Comme le résume le tableau ci-dessous: Lien Débit de transmission (unidirectionnel) Capacité utile (80% du débit de transmission) Débit effectif des données (envoi + réception) Largeur Gb/s 2 Gb/s (250 Mo/s) ( ) Mo/s Largeur 4 10 Gb/s 8 Gb/s (1 Go/s) (1+1) Go/s Largeur12 30 Gb/s 24 Gb/s (3 Go/s) (3+3) Go/s 7

8 Cependant, certaines limites inhérentes aux machines, et notamment les bus I/O, rendent difficile l obtention de telles performances. Ces limitations sont par la généralisation du PCI Express. Architecture & Composantes du Réseau InfiniBand : II Le Subnet La plus petite entité complète d un réseau IB est le Subnet ou sous réseau. Plusieurs Subnets peuvent être interconnectés par des routeurs adéquats pour former un plus grand réseau. Figure : Architecture de connexion dans le Subnet Les éléments d un Subnet sont, comme la figure l indique : les nœuds finaux (end Nodes), les commutateurs (switchs), les liens physiques (câblage+connecteurs), ainsi que le Manager de Subnet (Subnet Manager). Les nœuds finaux, tels que des terminaux ou périphériques, émettent sur un lien, des messages en destination d autres nœuds terminaux : ces messages sont commutés par les switchs. Le routage ainsi que la topologie du réseau est géré par le Subnet Manager. Un nœud final est relié au réseau par un CA (Channel Adapter), qui est montré dans la figure suivante : 8

9 Figure : Différents types de nœuds dans un réseau InfiniBand II Les liens Les liens IB sont des canaux de communications point à point et bidirectionnels, utilisant un support en fibre optique ou en cuivre. (17 mètres de portée sans répéteur avec du coax). Un lien simple, offre une bande passante de 2.5Gbaud ce qui donne des débits de l ordre de 2Gbps (codage 8b/10b). Il est néanmoins possible d agréger plusieurs liens physiques afin d obtenir plus de bande possible. On parle alors de liens (4X et 12X). II Les Switchs Les switchs IBA routent les messages de la source à la destination en s appuyant sur des tables de routage qui ce constitue pendant la phase d initialisation du réseau, et après quelconque modification. Les messages sont fragmentés en paquets plus petits pour pouvoir être transporté sur les liens physiques. La taille d un paquet et telle que le MTU peut-être 256 octets, 1KB, ou 4KB. Dans des systèmes à MTU variant, le Subnet Manager se charger de communiquer à l initiateur d une communication, le MTU approprié pour atteindre la destination voulue. Dans les cas les plus fréquents, la fragmentation/assemblage des messages est effectué par les HCA (host Channel Adapter) au niveau des nœuds terminaux. Le nombre de ports d un switch dépend du constructeur, selon la catégorie des liens supportés (1X, 4X, 12X). Le nombre maximum de ports est de 256 ports, il est possible de placer plusieurs switchs en cascade afin de former de grands systèmes. Certains commutateurs supportent le Multicast. II Les Nœuds terminaux 9

10 Les Nœuds terminaux peuvent être aussi bien des systèmes terminaux, des périphériques, des baies de stockages, des périphériques I/O etc. Ces nœuds, selon leur type, embarquent un CA (Channel Adapter) qui peut être un HCA ou TCA et qui va s interfacer entre le nœud terminal et le lien physique. II Les HCA (Host Channel Adapter) Ils se trouvent sur les nœuds de calcul, leur rôle est de fournir une interface physique au terminal vers le réseau. De plus, le HCA fournit aux applications du terminal une interface logicielle dénommée Verbs. Le HCA est souvent relié au bus d I/O du système et pourrait le remplacer à terme. Il gère, en plus, les messages émis et reçus grâce à des files dans un modèle de mémoire particulier. II Les TCA (Target Channel Adapter) Les TCA se trouvent sur les nœuds d entrée/sortie, baie de stockage. Son rôle est identique à celui du HCA, à la différence qu il n existe pas dans le TCA l équivalent de la pile Verbs présente dans le HCA. II Subnet Manager Il y a un Subnet Manager par Subnet. Son rôle est d émettre des messages d une certaine classe, afin de gérer le réseau. Déterminer la topologie lors de la phase d initialisation, le routage, etc. II.3- Support logiciel dans les grappes II.3.1- Transferts zéro-copie Les transferts de données zéro-copie par DMA (voir la figure en dessous) ne sont en fait importants que pour les grands messages pour lesquels une copie mémoire n est pas envisageable. Ils permettent de saturer les liens physiques. Mais ces DMA ont l inconvénient de nécessiter une interruption pour notifier leur terminaison sans faire d attente active. Le coût est de plusieurs microsecondes, ce qui est négligeable pour un large transfert de données. Mais pour les petits messages, c est la latence qui est importante. En effet, avec une latence L et une bande passante B, le temps de transfert d un message de taille s est T = L + s/b. Comme L est de l ordre de quelques microsecondes et B plusieurs centaines de Megaoctets par seconde, T == L pour s inférieur à quelques KB. Il est préférable de gaspiller quelques cycles processeur en utilisant un transfert PIO (Programmable Input/Output) pour être notifié rapidement plutôt que de subir le surcoût d une interruption. Ceci permet de conserver une très petite latence des petits messages au prix de quelques cycles processeur. Les PIO permettent des communications entièrement contrôlées par le processeur central. Le processeur n a pas besoin dans ce cas d attendre une notification de la carte d interface réseau puisque c est lui qui dirige la communication. 10

11 Figure : Transfert de données zéro-copie avec OS-bypass sur un réseau de grappe II.3.2- RDMA (Remote Direct Memory Access) RDMA est une technique de communication permettant la transmission de données à partir d une zone de mémoire d un poste (dans le réseau) vers un autre en s affranchissant de l intervention du processeur distant (pas d interruptions générées lors de la réception), des copies successives des données vers différents tampons dans l espace utilisateur et dans le mode kernel (zéro copy), et enfin : ne fait pas appel aux appels systèmes du noyau (OS ByPass). Ce qui à pour effet d améliorer considérablement les performances. II.3.3- Modèle de communication Le traitement des requêtes de communication par la carte d interface permet l implantation de modèles asynchrones de programmation. L application soumet des requêtes à la carte, recouvre leur traitement par des calculs (Overlap) puis teste leur terminaison plus tard. Ces requêtes sont de deux types, qui correspondent aux deux paradigmes de programmation des applications parallèles, le Rendez-vous (passage de messages, utilisé dans MPI) et les accès mémoire à distance RDMA. Dans le premier cas, les requêtes sont du type émission et réception de message. Les paramètres de ces requêtes sont comparés pour savoir quelle émission va être reçue par quelle requête de réception. Cette correspondance peut être effectuée dans l hôte (ce qui réduit le recouvrement) ou dans la carte d interface (ce qui peut nécessiter beaucoup de ressources mémoire et de puissance). Dans le second modèle, les primitives de communication sont de type lecture ou écriture en mémoire distante, ce sont des types RDMA (Remote Direct Memory Access). L application définit des fenêtres de RDMA (Window) qui possèdent des identifiants. L application transmet ces identifiants aux autres noeuds. Ces nœuds peuvent ainsi lire et écrire à distance dans les zones mémoire décrites par les fenêtres. Plus la carte d interface offre de ressources matérielles et des fonctionnalités évoluées, plus le protocole pourra y être déporté, et plus le recouvrement dans l hôte sera amélioré. 11

12 Figure : Diagramme temporel d une lecture mémoire distante RDMA. L application du nœud cible crée une fenêtre RDMA (Window) tandis que l initiateur poste une requête (RDMA Req). Les cartes d interfaces (NIC) traitent cette communication en tâche de fond (Comm.) pendant que les applications continuent leurs calculs. L application initiatrice vient Tester plus tard la terminaison de la requête (RDMA Event). II.4- Types de services de transfert Un service de transfert ajoute une particularité au message dans le sens de la fiabilité, de la sécurité ou du protocole utilisé. Un QP (Queue Pair) permet un transfert bidirectionnel de messages. A la création le QP est associé au port d un CA (Channel Adapter) local et un port peut être relié à plusieurs QP. Il se compose ainsi du SQ (Send Queue) et du RQ (Receive Queue) qui s échangent les messages à travers les SQ et RQ logic. Les messages sont sous forme de paquets qui sont identifiés par des PSN (Packet Sequence Number) ou des epsn. Les PSN permettent aux RQ Logic et SQ Logic de vérifier la provenance ou la bonne réception d un paquet (protocole d acquittement). Il existe plusieurs types de QP, en fonction du service de transport choisi : II.4.1- RC (Reliable Connected) QP Ce type de QP doit être initialisé par : -Le numéro de port du CA local par lequel s effectue l envoi et la réception des messages -Le numéro de QP, QPN (QPNumber). -Le numéro de QP distante (DestQPN) avec laquelle la connexion sera établi -Le numéro de port du CA distant où se situe la QP distante correspondante. -La taille des messages peut atteindre 2 Go. 12

13 Les QP implémentant ce type de transfert exigent une connexion explicite à une autre QP (de même type RC) préalablement à toute communication. Ce type de transfert implémente des mécanismes de contrôle de flux et d erreurs avec génération d acquittements positifs ou négatifs (Ack/Nak). D où le nom de service fiable (Reliable). Il consomme de ce fait, une bande passante importante. II.4.2- UC (Unreliable Connected) QP Les QPs de ce type suivent le même procédé d initialisation et de connexion que le type RC. Contrairement au type RC, le type UC n implémente pas de mécanismes de reprise sur erreur, ni de contrôle de flux. Il consomme donc relativement peu de bande passante et la taille des messages varie de 0 à 2Gb. II.4.3- RD (Reliable Datagram) QP Pour envoyer ou recevoir un message, Le RDQP peut communiquer avec plusieurs autres RDQP attachées un CA distant. La communication se fait en passant par des pipelines entre la CA local et un CA distant. Chaque canal ou pipeline dénommés RDC permet le transit des messages entre les RDQP locaux et les RDQP d un autre CA. Le RDC est programmé avec les numéros de port du CA local et celui du CA externe. Le service est dit fiable (reliable) car le protocole vérifie la bonne réception d un paquet avec émission de messages d acquittement. Il utilise pour cela une bande passante assez importante. II.4.4- UD (Unreliable Datagram) QP Les QPs de ce type peuvent communiquer avec l ensemble des QP joignables par le port local. Ce type de transfert n implémente pas de mécanismes de contrôle d erreurs ni de gestion de flux. La taille des messages est limitée à 2Ko. II.4.5- Raw QP Permet l encapsulation de paquets issus d autres protocoles (non IB) dans une fabrique InfiniBand. II.5- Types de transfert La spécification définit plusieurs opérations permettant l envoi et la réception de messages parmi les quelles : 13

14 II.5.1- RMDA Read Une opération de type RDMA Read demande à la Queue de Réception (QP RQ : Queue Pair Receive Queue) du destinataire de lire un message dans sa mémoire locale et d envoyer le résultat à la queue d émission de l émetteur. (QP SQ : Queue Pair Send Queue). Voici un schéma résumant le déroulement de cette opération : II.5.2- RDMA Write Figure : Déroulement d un RDMA Read avec InfiniBand Demande au destinataire d écrire des données dans une zone mémoire spécifiée en argument. Voici un schéma explicatif : 14

15 Figure : Déroulement d un RDMA Write avec InfiniBand II.5.3- Send Nœud entrant Nœud récepteur RAM 1 Données Descripteur d envoie 2 5 RAM 2 Données Descripteur de réception 1 NIC 1 NIC Données Données Réseau Infinibanb Figure : Déroulement d un Send 1- Construction du descripteur d envoi qui contient, notamment, l adresse virtuelle de la zone mémoire contenant les données à envoyer. Ce descripteur est placé dans la file d envoi (Send Queue) 2- Au moment de l envoi effectif du message, le contrôleur Réseau récupère les données à envoyer depuis la mémoire physique du système (RAM1), à l adresse spécifiée lors de l étape1. 3- Envoi du message. 4- Extraction du descripteur de réception. (Receive Request) 5- Les données sont récupérées à l adresse spécifiée dans le descripteur et écrites dans la mémoire physique de noeud destinataire (RAM2). II.5.4- Send inlined Le processus d envoi est équivalent à celui du Send. Cependant les donnés sont directement insérées dans le descripteur d envoi, supprimant ainsi une étape à l émission et à la réception. La taille des donnés pouvant être insérées dans un descripteur d envoi dépend directement des Capacités du contrôleur réseau. En négligeant la durée de la transmission d un message sur le réseau (étape 3). Nous pouvons Conclure que le coût d un Send et approximativement le double que celui d un Send inlined. Nous ferons donc usage du send inlined dans la mesure où la taille des donnés à envoyer nous le permet, et du send (non inlined) dans le cas contraire. 15

16 Nœud entrant E RAM 1 Données Descripteur d envoi Nœud récepteur R RAM 2 Données Descripteur de réception 1 NIC 1 NIC Données Données Réseau Infinibanb Figure : Déroulement d un Send II.6- Gestion des communications La gestion des communications repose sur les QP (Queue Pair). Comme cité précédemment, une QP est un canal de communication bidirectionnel composé de : 1- Une file d envoi (Send Queue) ainsi qu une file de réception (Receive Queue). 2- Une file de complétion d envoi (Send Completion Queue) ainsi qu un file de complétion de réception (Receive Completion Queue). (Dans certaines configurations, il est possible de disposer d une unique file de complétion partagée) L envoi des données s effectue de la manière suivante : 1- Un descripteur d envoi (Send Request) contenant l ensemble des paramètres fonctionnels de l opération (adresse des données, type d opération, type de notification ) est «postée» dans la file d envoi. 2- Ce descripteur est traité, selon une politique de priorité définie. Puis l envoi est effectué selon les paramètres spécifiés dans ce descripteur. 3- Une fois l opération terminée, le descripteur d envoi est retiré de la file d envoi, et un CQE (Completion Queue Entry) est ajouté à la file de Completion (Send Completion Queue), et ce à fin de notifier l utilisateur de la terminaison de l opération d envoi. La réception suit la même logique ; après chaque réception, un CQE (Completion Queue Entry) est ajoutée à la file de complétion de réception (Receive Completion Queue). 16

17 Interface Rwapi Comme annoncé dans l introduction, le but du projet est d implémenter cette interface sur le réseau InfiniBand. Nous allons dans un premier temps présenter l interface et quelques unes de ses caractéristiques qui nous intéressent. III.1- Modèle de programmation RWAPI implémente un protocole de communication sans recopie intermédiaire et sans synchronisation entre l émetteur et le récepteur. La figure suivante montre les différentes étapes nécessaires à un transfert d information. Réseau Nœud #1 Nœud #2 AE1 = rwapi_alloc(taille) AE2 = rwapi_alloc(taille) rwapi_ssend (#1, AE2) AE2 = rwapi_receive () rwapi_send (#2, AE1, AE2, taille) rwapi-receive () Figure : Modèle de programmation du Remote-Write Dans un premier temps, chaque nœud intervenant dans la communication doit réserver un espace de mémoire physique contigu en utilisant la fonction rwapi_alloc(). Pour une taille donnée, cette dernière fournit deux adresse : tout d abord, l adresse du segment de mémoire à l intérieur de l espace d adressage virtuel (non représentée sur le schéma) afin que l utilisateur puisse manipuler les informations comme il le ferait avec n importe quel segment issu d un malloc ; ensuite, une adresse identifiant l espace de mémoire physique contiguë et utilisée par l interface RWAPI, notée AEx pour le nœud x. Cette dernière adresse est envoyée du récepteur du message final vers l émetteur par l intermédiaire par exemple d un message court (c est-à-dire ne nécessitant aucune autre information autre que le numéro du nœud destinataire). Une fois l adresse reçue par l émetteur du message final, elle peut être utilisée à tout moment. 17

18 III.2- Routine d initialisation du Remote-Write La routine d initialisation concerne deux fonctions rwapi : La fonction rwapi_init(), de prototype void rwapi_init (int *, char ***), elle sert à initialisation des ressources c est-à-dire des queues d envoi et de réception, des interfaces de communications, de la mémoire La fonction rwapi_finalise(), dont le prototype est void rwapi_finalize (void), elle effectue l opération inverse de la fonction précédente. Elle libère les ressources après utilisation. III.3- Gestion de la topologie Afin d identifier et de gérer les processus et les nœuds dans le réseau, rwapi utilise : La fonction rwapi_size() de prototype size_t rwrapi_size (void), elle retourne le nombre de processus de l application. La fonction rwapi_rank() de prototype node_t rwrapi_size (void), elle renvoi un identifiant unique du processus qui à invoqué la fonction. L identifiant est un entier 0 et N-1 si le nombre de processus total est N. III.4- Allocation mémoire Pour faire une allocation mémoire, on utilise la fonction rwapi_alloc() (dont le prototype est void * rwapi_alloc (size_t, auth_t*) ), elle sert à l allocation de plages de mémoires contiguës. Afin d utiliser les mécanisme de DMA dans les opérations de type send() ou receive() : il est nécessaire de fournir des adresse physiques. Celles-ci ne sont pas accessibles depuis l espace utilisateur (USER MODE). Cette fonction permet de récupérer un objet représentant l adresse physique (de type auth_t*), qui est utilisable dans les fonctions d émission et de réception mettant en jeu le DMA (Direct Memory Access). Elle renvoi un pointeur vers l adresse virtuelle de la zone allouée, et le pointeur de type auth* contiendra une représentation de l adresse physique de cette même zone de mémoire. La fonction rwapi_free() (prototype void rwapi_alloc (void*)) sert à libérer une zone mémoire précédemment allouée avec rwapi_alloc. III.5- Envoi de messages Nous avons le choix entre deux fonctions pour envoyer un message, selon le type de message (Short message, Normal message) La fonction rwapi_ssend() (prototype sid_t rwrapi_ssend(node_t n, mi_t mi, small_t data, notify_t flag)) sert à envoyer des messages courts La fonction rwapi_send() (prototype sid_t rwrapi_send (node_t n, mi_t mi, auth_t lua, auth_t rua, size_t len, notify_t flag), sert à envoyer des messages normaux. Le paramètre en sortie sid_t des deux fonctions est l identifiant du message envoyé. 18

19 On distingue 2 types de messages : Les messages courts : Ils permettent de réaliser les communications les plus simples. Les messages courts servent aussi bien à l échange des adresses physiques entre les nœuds qu à optimiser la transmission des messages de petites tailles en limitant l utilisation des canaux DMA. Ils sont limités à 8 octets, conséquence directe de la taille des adresses physiques utilisées par les messages normaux. Les messages normaux : qui ne rentrent pas dans la catégorie précédente c est-à-dire qu ils utilisent le mode RDMA et ont besoin de connaitre aussi bien l adresse physique distante que l adresse locale. III.6- Contrôle des messages Ce contrôle fait appel à deux fonctions : La fonction rwapi_issent() dont le prototype est int rwrapi_issent(sid_t sid), Après l envoi d un message, l utilisateur peut utiliser rwapi_issent afin de s assurer de l envoi effectif d un message. La fonction rwapi_receive dont le prototype est size_t rwrapi_receive(node_t *n, mi_t *mi, int *type, small_t *data ), Elle teste si un message est arrivée et dans ce cas elle le lit et initialise les paramètres que l utilisateur peut récupérer. Elle renvoi alors la taille du message en sortie et dans le cas où aucun message n est arrivé elle retourne la valeur zéro. III.7- Contrôle des messages par interruption Au moment de l invocation des fonctions rwapi_ssend ou rwapi_send, l utilisateur utilise un paramètre (flag ou drapeau) qui spécifie le type d interruption qu il veut recevoir lors de l utilisation des fonctions précédentes. Il existe quatre types drapeaux d interruption : Pas d interruption dans tous les cas avec RWAPI_NONE. Interruption à l envoi d un message avec RWAPI_ONSEND. Interruption à la réception d un message avec RWAPI_ONRECEIVE. Interruption dans tous les cas avec RWAPI_BOTH. Pour contrôler ces interruptions, Nous disposons des fonctions suivantes : La fonction extern shandler_t rwrapi_shandler( mi_t mi ), Si le drapeau RWAPI_ONSEND est spécifié à l envoi. Une interruption est générée après l envoi effectif de ce message. Un appel à rwapi_shandler (fonction utilisateur) est effectué. La fonction extern rhandler_t rwrapi_rhandler( node_t n, mi_t mi, int, small_t data ) Si le message entrant spécifie les drapeaux RWAPI_BOTH ou RWAPI_ONRECEIVE, Un interruption est générée afin d effectuer un appel à la fonction utilisateur rwapi_rhandler. 19

20 III. Conception Le but de la démarche de conception, a été d'identifier les services rendus par les fonctions de l'api Remote-Write. Puis de mettre en correspondance ces services avec les fonctionnalités InfiniBand adéquates, de la manière la plus sure, et performante possible. L'API Remote-Write (RWAPI) définit un certains nombres de fonctions dont certaines impliquent l'envoi et la réception de messages sur le réseau InfiniBand vers des nœuds du réseau représentés simplement par des entiers. IV.1- Gestion de la topologie La gestion de la topologie concerne les fonctions rwapi_size() et rwapi_rank(). L élément le plus important étant le Spawner SSH. Celui-ci dispose d un fichier xml comportant les spécificités du réseau. Il définit notamment les routines de communication utilisée pour l initialisation, ainsi que la synchronisation des nœuds lors d une exécution répartie. Le Spawner calcule le plus court chemin entre deux nœuds et récupère leurs identifiants, puis à l aide de connexions SSH, lance les exécution sur les nœuds voulus. Son utilisation a permit de gérer la topologie d un manière simple et efficace : chaque processus se voit affecter un entier (entre 0 et nproc, le nombre de processus) représentant son identifiant propre ("à la MPI") tout le long du programme. Ceci nous permet de nous affranchir l'utilisateur du maniement des adresses InfiniBand. IV.2- Initialisation Rwapi dispose d'une fonction d'initialisation, dont le rôle est l'initialisation de l'"environnement" d'exécution. Dans le cas InfiniBand, cet environnement est constitué par l'ensemble des ressources, au niveau des divers nœuds, permettant l'envoi et la réception de messages. Le réseau InfiniBand, définit dans son architecture, de tels mécanismes : les QPs. Ce sont donc les QPs qui nous permettent d'établir les "canaux" de communications entre les noeuds. Ce sont ces mêmes canaux qu'emprunteront les messages à destination des nœuds distants. Les nœuds doivent aussi bien, être en mesure d'envoyer que de recevoir des messages en provenance de tous les nœuds. Il faut donc que ces canaux permettent une communication bidirectionnelle avec l'ensemble des nœuds, Ceci implique une création au niveau de chacun des nœuds d'un certain nombre de ces QPs. Le type de transfert choisi est le type RC pour Reliable Connect, (il est expliqué plus haut et dont son choix sera justifié plus bas) requiert une connexion explicite entre deux QPs de type RC préalablement à tout transfert de messages. A cet effet, la solution retenue est de créer au niveau de chaque nœud, (N-1) QPs tel que la iéme QP sera destinée à la communication avec le nœud i, comme sur le schéma suivant : (N étant le nombre de nœuds total). 20

21 QP1 Nœud 0 QP2 QP0 Nœud 1 QP2 Connexion QP1 Nœud 2 QP2 Figure : réseau de trois nœuds La fonction prenant en charge de l'initialisation de l'environnement est rwapi_init(). Cette fonction est chargée de : Lancement du programme sur les différents nœuds utilisés, pour cela elle utilise la fonction grwai_bootstrapinit_ssh(). Cette dernière qui est l'appel effectué par le spawner, prend en argument le nombre de machines ainsi que leurs noms (hostname), puis lance un programme sur l'ensemble de ces machines. Création et initialisation des ressources InfiniBand. Rwapi_init fait appel à des fonctions qui prennent en charge cette tache. grwai_bootstrapbarrier_ssh(), c'est une fonction du spawner : son rôle est de synchroniser les processus de l application. init_common_params() initialise par défaut un certain nombre de paramètres tels que : a) La taille des différentes queues d'émission et de réception (SQ, RQ, SCQ, RCQ) b) Numéro de port (du NIC) c) Identifiant du HCA local. d) Type de Transport (RC, RD, UC, UD) create_common_params() interagit avec le HCA afin d'initialiser les paramètres ainsi que pour la création des ressources bas niveau (QPs) permettant l'envoi et la réception. Voici le détail des taches effectuées : a) Récupère le hca_hndl (HCA HANDLE) :nécessaire à toute interaction avec le HCA. b) Récupère le LLID (Local LID) qui correspond à l'adresse InfiniBand du HCA local. c) Allocation du Domaine de protection (Protection Domain). e) Création de N-1 Send Queues dont chacune sera destinée à l'envoi de messages vers un nœud distant. (N étant le nombre de processus) f) Création de N-1 Send Queues dont chacune sera destinée à la communication avec un nœud distant. 21

22 g) Affection des handlers à l'émission et à la réception (SQ, RQ) (si les interruptions sont prises en charge) h) Allocation de mémoire pour un certain nombre de variables vectorielles. qp_create() : Création de N-1 QPs destinées à la communication vers d'autres nœuds. communicate_params_mqp() : Cette fonction d'occupe d'échanger les paramètres des QP créés avec l'ensemble des nœuds, elle enregistre la valeurs des paramètres des QP distants afin de compléter leur initialisation. Pour cela elle utilise la fonction grwai_bootstrap_exchange_ssh(). qp_init2rts_mqp() : Avec cette fonction les QPs passent par trois états successifs: INIT : après la création une QP ne peut ni envoyer ni recevoir de messages. RTR : dans ce cas, la QP peut seulement recevoir des messages, mais ne pas en envoyer. RTS : la QP est totalement fonctionnelle, et peut envoyer et recevoir des messages. Elle permet aussi modification des QP grâce aux paramètres des QP distantes, afin de faire passer les QPs locales dans un état fonctionnel IV.3- Envoi de messages Les fonctions d'envoi et de réception, empruntent les QPs pour recevoir ou envoyer des messages vers le nœud désiré. Pour envoyer un message il faut d abord choisir ses spécificités et le type de transfert le plus adapté à nos paramètres. Pour définir le mécanisme d'envoi de messages dans RWAPI.h, il nous faut choisir un mode de transfert qui fonctionne à la fois pour infiniband et pour le Remote-write avec le type de service adapté. IV.3.1- Choix du type de transfert Le choix du type de transfert est un point important. Il influe sur l architecture globale de notre solution, car implique, selon le type choisi, des orientations différentes. Test de Bande passante Pour chacun des types de transfert, on relève la valeur de la bande passante en fonction de la taille des messages (Le type RD est exclu car non supporté par le contrôleur réseau sur lequel porte notre travail). Remarque : le type UD ne permet pas l envoi de messages de plus de 2Ko. En prenant les valeurs logarithmiques on obtient la courbe ci-dessous. 22

23 test de bande passante Bandwith use (ln(mb/sec)) 10 5 ud uc rc , , , , , , , , , , , , , size (ln(bytes)) Figure : évolution de la bande passante en fonction de la Taille des messages pour trois types de services (UC, UD et RC) Le type UD consomme effectivement le moins de bande passante, cependant il est exclu pour les raisons suivantes : a) taille maximale des messages : 2Ko b) Absence de support pour les opérations de type RDMA. Test de fiabilité (taux de pertes) Les statistiques réseau indiquent clairement que le taux de perte pour le contrôleur InfiniBand est nul. Ce qui tendrait à confirmer la fiabilité supposée du réseau IB. Cependant, une démarche plus précise aurait consisté à déterminer depuis les tests effectués (type RC) le taux d acquittements négatifs. Cette fonctionnalité n est pas fournie au niveau de la couche VAPI. IV.3.2 Le mode de transfert et les fonctions d envoi de messages La fonction rwapi_ssend() Cette fonction a pour charge l envoi de messages courts (8o). Nous excluons l utilisation des types d opérations RDMA pour cette fonction, pour les raisons suivantes : -Ils sont coûteux en termes de temps pour les petits messages -Il faut connaître l'adresse mémoire destination d'un message pour pouvoir l'envoyer. Il nous reste donc à choisir entre les deux Send. Le Send inlined d'infiniband correspond au Send short du Remote-write, On choisit pour cela le mode Send inlined pour envoyer un message court, en postant un Send Request dans la QP correspondante. Nous utilisons exclusivement un tampon mémoire, enregistré auprès du HCA pour envoyer les données. 23

24 La fonction rwapi_send() Cette fonction envoi un message de taille arbitraire (jusqu'à 2Gbits) vers un nœud du réseau. Il est donc fait usage de la Send Queue de la QP correspondante en faisant un appel à VAPI_post-sr dont l un des arguments, est de type VAPI_sr_desc_t. Ce type représente en fait l'entité InfiniBand qui est le Send Request. Cet élément regroupe dans ces champs un certain nombre de champs nous renseignent sur le message à envoyer tel que l'adresse de la zone mémoire où se trouve les données, le type d'opération effectué pour l'envoi ou le type de notification, etc.. Il suffit donc de fournir l'adresse de la zone mémoire où se trouvent les données à envoyer pour envoyer un message. Cependant, il faut aussi faire un choix sur le type d'envoi. InfiniBand propose quatre opérations qui sont : -SEND (inline, non_inlined) -RDMA-WRITE -RDMA-READ -RDMA atomics Le choix s est porté sur RDMA-WRITE car nous avons connaissance de l'adresse mémoire de destination. De cette manière, le message est directement écrit dans la mémoire distante à cette adresse. Il y a deux justifications à notre choix : Utilisation de l'accès à la mémoire distante (RDMA-WRITE) : afin d'implémenter le concept de zéro copy et de OS-Bypass que supporte RW. Dans les transferts classiques, chaque paquet reçu par l'interface réseau génère une interruption CPU. De plus, ce même message subit un certain nombre de recopies successives depuis l'espace Kernel vers l'espace utilisateur, ce qui a pour effet une dégradation des performances. Dans le cas du RDMA_WRITE, les accès mémoire sont gérés directement par le HCA qui embarque ses propres circuits. L envoi du message sera donc une écriture de message directement dans la mémoire destinataire. L'utilisation de la variante WITH-IMMEDIATE : une opération de type RDMA_WRITE ne génère pas de descripteur de complétion (VAPI_wq_desc_t) du coté du récepteur ce qui rend la réception d'un type de message impossible avec un appel à rwapi_receive, en effet celle-ci se sert des descripteurs de complétion (Completion Queue Entry) sur la RCQ (Receive Completion Queue) afin de délivrer un message reçu au niveau de la Receive Queue. L'option WITH IMMEDIATE permet de s'affranchir de cette limitation, car quand cette option est activée, un descripteur de réception est généré. IV.4- Contrôle des messages Le contrôle des messages avec la fonction rwapi_issent() : 24

25 Un identifiant unique de type sid_t est associé à chaque message envoyé (rwapi_send, rwapi_ssend). La fonction rwapi_issent prend en paramètre un tel identifiant, et vérifie que le message associé à cet identifiant a bien été envoyé. La fonction rwapi_receive() : scrute les N-1 Receive Completion Queue (RCQ) pour déterminer l expéditeur d un message. Puis s arrête après le premier RCQ trouvé. IV.5- Contrôle des messages par interruption Ce contrôle consiste à créer 4*(N-1) QPs qui permettront de gérer les interruptions en fonction du choix de flag de l utilisateur. La création des QPs est répartie comme suivant : (N-1) QPs pour le flag RWAPI_NONE, (N-1) QPs pour le flag RWAPI_ONSEND, (N-1) QPs pour le flag RWAPI_ONRECEIVE, (N-1) QPs pour le flag RWAPI_BOTH, Du fait de la spécificité d InfiniBand, Il serait nécessaire de créer 4*(N-1) QPs pour limiter le coût qu auraient engendré des interruptions non contrôlées. Cette partie n a pas été implémentée. 25

26 IV. Validation et tests de performance V.1- Benchmark des tests Pour la validation de l interface nous avons mesuré deux paramètres de test de performance, la latence et la bande passante. V.1.1- La latence Définition On parle en général de temps de latence ou période de latence pour désigner le délai entre une action et le déclenchement d'une réaction. Dans notre cas, on distingue : Le one-way-latency : le temps que met un message (8 oct dans notre cas) pour atteindre sa destination, c est-à-dire le nœud suivant. Il correspond au temps d envoi d un short message. Le round-trip-latency : c est le temps d un aller-retour d u message. Il correspond à l envoi et la réception d un message. Algorithmes du test de latence Comme variables on a N est le nombre de nœuds du réseau, t1, t2 et L sont des temps. Pour le one-way-latency, les algorithmes sont les suivants: Pour le nœud émetteur Pour le récepteur pour i de 1 à N faire rwapi_ssend (receveur, mi, données, drapeau) //ou rwapi_send fin pour i t1= timer_start() pour i de 1 à N faire rwapi_receive (emetteur, mi, type, données) fin pour i t2 = timer_stop() L= (t2-t1)/n V.1.2- La bande passante utile Pour tester la bande passante, on considère aussi les deux cas. Pour tester la bande passante on utilise la fonction rwapi_send() pour l envoi. 26

27 Les variables sont : N est le nombre d itération, size est la taille du message à envoyer, t1, t2 sont des temps. Pour le nœud émetteur Pour le récepteur Define MAX_SIZE 100Mo size = 4 Tant que size < MAX_SIZE faire t1= timer_start() t2 = timer_stop() BW = size/(t2-t1) size = size*2 fin tant que pour i de 1 à N faire fin pour i V.2- Interprétation des résultats V.2.1- La latence pour i de 1 à N faire rwapi_send(receveur, mi, adressedonnees, size, drapeau) rwapi_receive (emetteur, mi, type, adresse) fin pour i rwapi_receive (emetteur, mi, type, adresse) rwapi_send(receveur, mi, adressedonnees, size, drapeau) Puisque RWAPI propose deux routines d envoi de message, les tests ont été faits avec rwapi_send() et rwapi_ssend(). Pour avoir l algorithme pour le rwapi_ssend, il suffit de remplacer rwapi_send() par rwapi_ssend(). Avec le rwapi_ssend(), on trouve une la latence de L = 2,66 µs et avec rwapi_send(), on trouve L = 1,82 µs. Cet écart entre rwapi_send() et rwapi_ssend() est dû à l utilisation de l adresse physique distante pour effectuer le rwapi_send(). En effet, puisque le rwapi_send() connaît à l avance l adresse finale des données dans le nœuds récepteur, elle ne parcourt pas la queue de réception à la recherche d un descripteur de réception. Avec la version InfiniBand de MPI, la latence est d environ 5 µs. 27

28 V.2.2- La bande passante utile En théorie on a les valeurs suivantes : Bande passante maximale du réseau InfiniBand : 10 Gbps, Bande passante utile maximale : 8 Gbps. On trouve une bande passante utile de Gbps, ce qui veut dire qu on atteint 78% de la bande passante utile maximale théorique. Figure : Bande passante utile pour rwapi_send(). 28

29 V. Conclusion et perspectives Ce projet à été d un grand apport d un point de vue pratique. Il nous a permis d étudier une technologie réseau récente qui émerge dans le milieu industriel. D autre part, nous étions amené à implémenter un protocole de communication en respectant ses spécifications. Ce travail a été l occasion de travailler avec des mécanismes bas niveau. Les résultats obtenus sont assez satisfaisants. En effet, l implémentation correspond aux spécifications et les performances obtenues sont proches des résultats des autres bibliothèques développées au dessus d InfiniBand. Des optimisations sont encore possibles notamment dans la gestion des interruptions. Notre proposition est très envisageable mais elle nécessite un temps important pour son implémentation. Lors de mesure de performance, nous étions confrontés à un problème de gestion de requêtes d émission et de réception. Le problème vient du fait que les queues de communication d infiniband sont allouées dans la carte réseau et donc elles sont de taille très limitée. La solution pourrait être l utilisation d une double queue, l une allouée dans la carte réseau et l autre dans la mémoire de la machine. En conclusion, ce travail a été très bénéfique et il pourrait être un bon point de départ pour le développement d une bibliothèque plus complète. 29

30 VI. Bibliographie 1- Top500, novembre InfiniBand Trade Association, Mellanox, Tom Shanley, Infiniband Network Architecture, Inc MindShare 5- Eric Renault, Implementation de l interface PAPI sur une machine Multi- PC Ouissem Ben Fredj and Eric Renault. Remote Write Communication Protocol for Clusters and Grids. In Proceedings Second International Workshop on Operating Systems, Programming Environments and Management Tools for High-Performance Computing on Clusters (COSET-2). Cambridge, Massachusetts - USA. June 19th, Alexandrov and M. Ionescu and K. E. Schauser and C. Scheiman, LogGP: Incorporating Long Messages into the LogP Model---One Step Closer towards a Realistic Model for Parallel Computation. In Proceedings of the 7th Symposium on Parallel Algorithms and Architectures, pages Santa Barbara, California. July