9.6. Configuration d'IPoIB

Comme mentionné dans Section 1.2, « Réseaux IP versus Réseaux non-IP », la plupart des réseaux sont des réseaux IP. InfiniBand n'en est pas un. Le rôle d'IPoIB est de fournir une couche d'émulation de réseau IP sur les réseaux RDMA InfiniBand. Cela permet à des applications existantes d'exécuter sur InfiniBand réseaux non modifiés. Toutefois, les performances de ces applications sont considérablement inférieures par rapport à la possibilité que l'application ait été écrite pour utiliser la communication RDMA nativement. Étant donné que la plupart des réseaux InfiniBand comprennent un ensemble d'applications qui doivent vraiment essayer d'obtenir toute la performance possible du réseau, et d'autres applications pour lesquelles un taux de rendement moindre est acceptable, si cela signifie que l'application ne doit pas être modifiée pour utiliser les communications RDMA. IPoIB est là pour permettre aux applications moins critiques d'exécuter sur le réseau telles qu'elles.

Comme les réseaux iWARP et RoCE/IBoE sont en fait des réseaux IP avec des couches RDMA au dessus de leur couche liaison IP, ils n'ont pas besoin d'IPoIB. De ce fait, le noyau refusera de créer des périphériques IPoIB sur les périphériques RDMA iWARP ou RoCE/IBoE.

Les périphériques IPoIB peuvent être configurés pour exécuter en mode datagramme ou connecté. La différence est dans quel type de paire de file d'attentes la couche IPoIB tente d'ouvrir avec la machine à l'autre bout de la communication. Pour le mode datagramme, une paire de file d'attentes peu fiables, déconnectées, est ouverte. Pour le mode connecté, une paire de files d'attentes fiables, connectées est ouverte.

En mode datagramme, le type de paire de file d'attentes peu fiables, déconnectées n'autorise pas les paquets qui sont plus volumineux que le MTU de la couche-liaison d'InfiniBand. La couche IPoIB ajoute un en-tête IPoIB de 4 octets au dessus du paquet IP transmis. Ainsi, le MTU IPoIB doit être de 4 octets de moins que le MTU de couche liaison d'InfiniBand. Comme 2048 est un MTU de couche liaison d'InfiniBand commun, le MTU de périphérique commun d'IPoIB MTU en mode datagramme est de 2044

Lorsque vous utilisez le mode connecté, la paire de file d'attentes fiables et connectées autorise des messages qui sont plus volumineux que le MTU de couche liaison d'InfiniBand et l'adaptateur de l'hôte gère une segmentation de paquets et leur réassemblage à chaque extrémité. En conséquence, il n'y a aucune limite de taille imposée sur la taille des messages IPoIB, qui peuvent être envoyés par les adaptateurs InfiniBand en mode connecté. Cependant, il y a toujours la limitation qu'un paquet IP doit avoir un champ de taille de 16 bits seulement, et qu'il est donc limité à 65535 comme nombre d'octets maximum. Le MTU maximal autorisé est en fait plus petit que cela, parce que nous devons tenir compte des différents en-têtes TCP/IP qui doivent également correspondre à cette taille. En conséquence, le MTU IPoIB en mode connecté est plafonné à 65520 afin de s'assurer il y a suffisamment de place pour tous les en-têtes TCP nécessaires.

L'option mode connecté a généralement des performances supérieures, mais il consomme aussi plus de mémoire du noyau. Comme la plupart des systèmes s'intéressent davantage à la performances qu'à la consommation de mémoire, le mode connecté est le mode le plus couramment utilisé.

Toutefois, si un système est configuré en mode connecté, il doit encore envoyer le trafic multidiffusion en mode datagramme (la structure et les commutateurs InfiniBand ne peut pas faire passer le trafic multidiffusion en mode connecté). De plus, il reviendra en mode datagramme lorsqu'il communiquera avec tous les hôtes non configurés en mode connecté. Les administrateurs doivent être conscients que s'ils ont l'intention d'exécuter des programmes qui envoient des données multidiffusion, et que ces programmes tentent d'envoyer des données multidiffusion à hauteur de la valeur maximale MTU sur l'interface, il faudra configurer l'interface pour l'opération de datagramme ou trouver un moyen de configurer l'application multidiffusion pour plafonner la taille de leurs paquets envoyés à une taille qui s'adaptera à celle des paquets datagramme.

Les périphériques IPoIB ont des adresses de 20 octets. L'utilitaire déprécié ifconfig n'est pas en mesure de lire l'ensemble des 20 octets et n'est pas assez fiable pour chercher les adresses correctes de matériel pour un périphérique IPoIB. Les utilitaires ip du package iproute fonctionnenet correctement.

Les 4 premiers octets de l'adresse matérielle d'IPoIB correspondent aux drapeaux et au numéro de paire de file d'attentes. Les prochains 8 octets représentent le préfixe de sous-réseau. Quand le périphérique IPoIB est tout d'abord créé, il aura le préfixe de sous-réseau par défaut de 0xfe:80:00:00:00:00:00:00. Le périphérique utilise le préfixe de sous-réseau par défaut (0xfe80000000000000) jusqu'à ce qu'il entre en contact avec le gestionnaire de sous-réseau, et à moment là, il se réinitialisera le préfixe de sous-réseau pour correspondre à la valeur de configuration devisée par le gestionnaire de sous-réseau. Les 8 octets de la fin correspondent à l'adresse GUID du port InfiniBand auquel le périphérique IPoIB est attaché. Comme les 4 premiers octets et les 8 octets suivants peuvent changer de temps en temps, ils ne sont pas utilisés ou mis en correspondance lorsque vous spécifiez l'adresse matérielle d'une interface IPoIB. La section Section 9.3.3, « Utilisation de 70-persistent-ipoib.rules » explique comment dériver l'adresse en laissant les 12 premiers octets en dehors du champ ATTR {address} dans le fichier de règles udev pour que la correspondance au périphérique soit fiable. Lorsque vous configurez des interfaces IPoIB, le champ HWADDR du fichier de configuration peut contenir les 20 octets, mais seuls les 8 derniers octets sont effectivement utilisés pour la correspondance et pour trouver le matériel spécifié par un fichier de configuration. Toutefois, si le TYPE=InfiniBand n'est pas correctement épelé dans le fichier de configuration de périphérique, et que ifup-ib n'est pas le script réel utilisé pour faire apparaître l'interface IPoIB, alors, une erreur expliquant que le système est incapable de trouver le matériel spécifié par la configuration surgira. Pour les interfaces IPoIB, le champ TYPE= du fichier de configuration doit être InfiniBand ou infiniband (l'entrée est sensible à la casse, mais les scripts accepteront les deux façons d’épeler).

La structure InfiniBand peut être logiquement segmentée en sous-réseaux virtuels avec différents sous-réseaux P_Key. Ceci est similaire à l'utilisation de réseaux locaux virtuels sur des interfaces Ethernet. Tous les commutateurs et les hôtes doivent être membres du sous-réseau P_Key qui correspond à la valeur par défaut, mais les administrateurs peuvent créer des sous-réseaux supplémentaires et limiter des membres de ces sous-réseaux à des sous-réseaux d'hôtes ou de commutateurs de la structure. Un sous-réseau de P_Key doit être défini par le gestionnaire de sous-réseaux avant qu'un hôte puisse l'utiliser. Voir la section Section 9.4.4, « Création d'une définition P_Key » pour plus d'informations sur la façon de définir un sous-réseau P_Key en utilisant le gestionnaire de sous-réseaux opensm. Pour les interfaces IPoIB, lorsqu'un sous-réseau P_Key a été créé, nous pouvons créer des fichiers de configuration IPoIB supplémentaires spécifiquement pour ces sous-réseaux P_Key. Tout comme les interfaces VLAN sur les périphériques Ethernet, chaque interface de IPoIB se comporte comme si elle était sur une structure complètement différentes des autres interfaces IPoIB partageant la même liaison, mais ayant des valeurs P_Key différentes.

Il y a des prescriptions particulières pour les noms des interfaces P_Key d'IPoIB. Toutes les P_Key d'IPiIB varient entre 0x0000 et 0x7fff et le caractère étendu (high bit), 0x8000 indique que l'appartenance à un P_Key est membre à part entière et qu'il ne s'agit pas d'une adhésion partielle. Le pilote IPoIB du noyau Linux ne supporte que des membres à part entière dans les sous-réseaux P_Key, donc, pour n'importe quel sous-réseau sur lequel Linux peut établir une connexion, la valeur high bit de P_Key sera toujours définie. Cela signifie que si un ordinateur Linux rejoint P_Key 0x0002, son nombre P_Key une fois rejoint, sera 0x8002, indiquant que nous sommes membres à part entière de P_Key 0x0002. Pour cette raison, lorsque vous créez une définition de P_Key dans un fichier opensm partitions.conf comme décrit dans la section Section 9.4.4, « Création d'une définition P_Key », il est faut spécifier une valeur P_Key sans 0x8000, mais lors de la définition des interfaces P_Key d'IPoIB sur les clients Linux, ajoutez la valeur de 0x8000 à la valeur de base P_Key.