Ho trascorso diversi giorni su questo ora e sono riuscito a far funzionare SR-IOV con la scheda Mellanox Infiniband utilizzando l'ultimo firmware.
Le funzioni virtuali vengono visualizzate in Dom0 come
06: 00.1 Controller di rete: famiglia MT27500 Mellanox Technologies [funzione virtuale ConnectX-3] 06: 00.2 Controller di rete: famiglia MT27500 Mellanox Technologies [funzione virtuale ConnectX-3] 06: 00.3 Controller di rete: famiglia MT27500 Mellanox Technologies [funzione virtuale ConnectX-3 ] 06: 00.4 Controller di rete: Mellanox Technologies MT27500 Family [Funzione virtuale ConnectX-3]
Ho quindi staccato 06: 00.1 da Dom0 e assegnato a xen-pciback.
L'ho passato in un dominio di prova Xen.
lspci all'interno del test DomU mostra:
00: 01.1 Controller di rete: Mellanox Technologies MT27500 Family [Funzione virtuale ConnectX-3]
Ho i seguenti moduli caricati in DomU
mlx4_ib
rdma_ucm
ib_umad
ib_uverbs
ib_ipoib
L'output di dmesg per i driver mlx4 mostra:
[ 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
Ho persino fatto apparire il dispositivo 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)
Posso persino eseguire il ping a livello locale il 10.10.10.10.
Tuttavia, quei ping non vengono inviati sul tessuto infiniband.
Sembra che il collegamento non sia attivo. ibstat mostra:
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
Come faccio ad alzarlo? il link domU è UP ma non quello VF?
E la risposta in realtà si trova qui: secondo questo link: http://www.spinics.net/lists/linux-rdma/msg13307.html
Di cosa ho bisogno per rendere attiva la porta VF dello slave? Sto eseguendo opensm 3.3.13 su una scatola diversa, è abbastanza nuovo? (SR-IOV richiede qualche supporto SM?)
Sì, come ha notato Hal, è necessario almeno opensm 3.3.14 ( http://marc.info/?l=linux-rdma&m=133819320432335&w=2 ) in quanto è la prima versione a supportare alias-guid et al roba necessaria per Anche SRIOV, 3.3.15 è ora disponibile, quindi vuoi la seconda versione che supporti questo ... fondamentalmente hai bisogno del link IB per il PPF e lo slave per ottenere un alias guid registrato per esso @ SM. Noi (team IL) siamo partiti da martedì / mercoledì a partire da una vacanza, cercheremo di fornirti ulteriori dettagli stasera e, in caso contrario, entro domani, certo.
Ora ho aggiornato OpenSM e riferirò presto.
EDIT: OK, ora funziona. Comunque sto ottenendo un logout per opensm. Il processo OpenSM sta scrivendo centinaia di voci al secondo del modulo:
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
E i messaggi di errore sopra sono andati via quando ho riavviato e ho dato a Dom0 più memoria. Al momento ho allocato 2 GB con l'autoballooning disattivato. Sfortunatamente, sono tornati senza una ragione ovvia. Quindi ho fatto una nuova domanda che si riferisce a questo qui
Non sono davvero sicuro del perché funzioni in dom0 ma nel mio caso devo avere OpenSM in esecuzione sul Dom0 che ha i VF. Presumo che ciò sia dovuto al fatto che l'istanza OpenSM in esecuzione su Dom0 è a conoscenza dei VF e può pubblicizzarli mentre un gestore subnet su un altro nodo non lo sa? questa è la mia ipotesi. Spero che anche l'altro nodo xen rilevi i suoi VF. Ciò potrebbe finire per diventare un'altra domanda. Per ora funziona con un singolo nodo Xen.