J'ai passé plusieurs jours là-dessus maintenant et j'ai réussi à faire fonctionner SR-IOV avec la carte Mellanox Infiniband en utilisant le dernier firmware.
Les fonctions virtuelles apparaissent dans Dom0 sous la forme
06: 00.1 Contrôleur réseau: famille Mellanox Technologies MT27500 [fonction virtuelle ConnectX-3] 06: 00.2 contrôleur réseau: famille Mellanox Technologies MT27500 [fonction virtuelle ConnectX-3] 06: 00.3 contrôleur réseau: famille Mellanox Technologies MT27500 [fonction virtuelle ConnectX-3 ] 06: 00.4 Contrôleur de réseau: famille Mellanox Technologies MT27500 [fonction virtuelle ConnectX-3]
J'ai ensuite détaché 06: 00.1 de Dom0 et l'ai affecté à xen-pciback.
Je l'ai passé dans un domaine de test Xen.
lspci dans le test DomU montre:
00: 01.1 Contrôleur réseau: Famille Mellanox Technologies MT27500 [Fonction virtuelle ConnectX-3]
J'ai les modules suivants chargés dans DomU
mlx4_ib
rdma_ucm
ib_umad
ib_uverbs
ib_ipoib
La sortie dmesg pour les pilotes mlx4 montre:
[ 11.956787] mlx4_core: Mellanox ConnectX core driver v1.1 (Dec, 2011)
[ 11.956789] mlx4_core: Initializing 0000:00:01.1
[ 11.956859] mlx4_core 0000:00:01.1: enabling device (0000 -> 0002)
[ 11.957242] mlx4_core 0000:00:01.1: Xen PCI mapped GSI0 to IRQ30
[ 11.957581] mlx4_core 0000:00:01.1: Detected virtual function - running in slave mode
[ 11.957606] mlx4_core 0000:00:01.1: Sending reset
[ 11.957699] mlx4_core 0000:00:01.1: Sending vhcr0
[ 11.976090] mlx4_core 0000:00:01.1: HCA minimum page size:512
[ 11.976672] mlx4_core 0000:00:01.1: Timestamping is not supported in slave mode.
[ 12.068079] <mlx4_ib> mlx4_ib_add: mlx4_ib: Mellanox ConnectX InfiniBand driver v1.0 (April 4, 2008)
[ 12.184072] mlx4_core 0000:00:01.1: mlx4_ib: multi-function enabled
[ 12.184075] mlx4_core 0000:00:01.1: mlx4_ib: operating in qp1 tunnel mode
J'ai même fait apparaître le périphérique ib0.
ib0 Link encap:UNSPEC HWaddr 80-00-05-49-FE-80-00-00-00-00-00-00-00-00-00-00
inet addr:10.10.10.10 Bcast:10.10.10.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:2044 Metric:1
RX packets:117303 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:256
RX bytes:6576132 (6.5 MB) TX bytes:0 (0.0 B)
Je peux même ping localement 10.10.10.10.
Cependant, ces pings ne sont pas envoyés sur le tissu infiniband.
Il semble que ce soit parce que le lien est en panne. ibstat montre:
CA 'mlx4_0'
CA type: MT4100
Number of ports: 1
Firmware version: 2.30.3000
Hardware version: 0
Node GUID: 0x001405005ef41f25
System image GUID: 0x002590ffff175727
Port 1:
State: Down
Physical state: LinkUp
Rate: 10
Base lid: 9
LMC: 0
SM lid: 1
Capability mask: 0x02514868
Port GUID: 0x0000000000000000
Comment puis-je l'obtenir? le lien domU est UP mais pas celui VF?
Et la réponse se trouve en fait ici: Selon ce lien: http://www.spinics.net/lists/linux-rdma/msg13307.html
De quoi ai-je besoin pour que le port du VF esclave devienne actif? J'utilise opensm 3.3.13 sur une autre boîte, est-ce assez nouveau? (SR-IOV nécessite-t-il une prise en charge SM?)
Oui, comme l'a noté Hal, vous avez au moins besoin de opensm 3.3.14 ( http://marc.info/?l=linux-rdma&m=133819320432335&w=2 ) car il s'agit de la 1ère version à prendre en charge alias-guid et autres éléments nécessaires pour SRIOV, 3.3.15 est également disponible maintenant, vous voulez donc la 2ème version qui prend en charge cela ... fondamentalement, vous avez besoin d'un lien IB pour le PPF et l'esclave pour obtenir un guide d'alias enregistré pour cela @ le SM. Nous (équipe IL) étions hors mardi / mercredi en vacances, nous essaierons de vous fournir plus de détails ce soir et sinon, d'ici demain, bien sûr.
J'ai maintenant mis à niveau OpenSM et je ferai un rapport bientôt.
EDIT: OK, cela fonctionne maintenant. Cependant, je reçois une éruption de journal pour opensm. Le processus OpenSM écrit des centaines d'entrées par seconde du formulaire:
Sep 30 20:36:26 707784 [7DC1700] 0x01 -> validate_requested_mgid: ERR 1B01: Wrong MGID Prefix 0x8000 must be 0xFF
Sep 30 20:36:26 707810 [7DC1700] 0x01 -> mcmr_rcv_create_new_mgrp: ERR 1B22: Invalid requested MGID
Sep 30 20:36:26 708096 [8DC3700] 0x01 -> validate_requested_mgid: ERR 1B01: Wrong MGID Prefix 0x8000 must be 0xFF
Sep 30 20:36:26 708119 [8DC3700] 0x01 -> mcmr_rcv_create_new_mgrp: ERR 1B22: Invalid requested MGID
Sep 30 20:36:26 708391 [FF5B0700] 0x01 -> validate_requested_mgid: ERR 1B01: Wrong MGID Prefix 0x8000 must be 0xFF
Sep 30 20:36:26 708421 [FF5B0700] 0x01 -> mcmr_rcv_create_new_mgrp: ERR 1B22: Invalid requested MGID
Sep 30 20:36:26 708696 [3DB9700] 0x01 -> validate_requested_mgid: ERR 1B01: Wrong MGID Prefix 0x8000 must be 0xFF
Sep 30 20:36:26 708719 [3DB9700] 0x01 -> mcmr_rcv_create_new_mgrp: ERR 1B22: Invalid requested MGID
Et les messages d'erreur ci-dessus ont disparu lorsque j'ai redémarré et donné plus de mémoire à Dom0. J'ai actuellement 2 Go qui lui sont alloués avec la désactivation automatique. Malheureusement, ils sont de retour sans raison évidente. J'ai donc posé une nouvelle question à ce sujet ici
Je ne sais pas vraiment pourquoi cela fonctionne dans dom0 mais dans mon cas, je dois avoir OpenSM en cours d'exécution sur le Dom0 qui a les VF. Je suppose que c'est parce que l'instance OpenSM fonctionnant sur Dom0 connaît les VF et peut les publier alors qu'un gestionnaire de sous-réseau sur un autre nœud ne le fait pas? c'est ma supposition. J'espère que l'autre nœud xen récupérera également ses VF. Cela pourrait finir par devenir une autre question. Pour l'instant, cela fonctionne avec un seul nœud Xen.