問題タブ [infiniband]

Infiniband または RoCE-Ethernet で知られているように、以下を使用できます。

• VMA - Voltaire Messaging Accelerator (VMA) Mellanox の Messaging Accelerator (VMA) は、メッセージベースおよびストリーミング アプリケーションのパフォーマンスを向上させます。その結果、レイテンシが 300% 削減され、アプリケーションのスループットが 200 倍増加します。 % サーバーあたり...

• SDP - Sockets Direct Protocol (SDP) は、InfiniBand ファブリックの機能を利用して、既存のソケットベースのネットワーク アプリケーションのパフォーマンスを透過的に向上させるバイト ストリーム プロトコルです。

また、9 ページ: http://www.informatix-sol.com/docs/TCP_bypass_overview.pdf

また、SDP と VMA の両方が RDMA-Verbs を使用し、(libpreload) LD_PRELOAD として既にコンパイルされたプログラムのバイナリに使用できることが知られています: http://www.informatix-sol.com/low-latency.html

Openonload と同様に、SDP と Mellanox の VMA はすべてプリロードして、既存の TCP/IP ソケット プログラムを高速化します。Openonload は TCP/IP プロトコルを保持しているため、シングルエンドで使用できます。SDP と VMA はどちらも VERBS にマップされるため、ワイヤの両端に展開する必要があります。

また、次から画像を取得します。

• 15 ページ 図 2-1: http://lists.openfabrics.org/pipermail/general/attachments/20081016/3fe4fd45/attachment.obj
• 76 ページ: http://ircc.fiu.edu/download/sc13/Infiniband_Slides.pdf

ただし、SDP と VMA の両方の場合:

• TCP/IP スタックをバイパスします
• RDMA動詞を使用
• ワイヤの両端に展開する必要があります
• すでにコンパイルされたプログラムのバイナリに (libpreload) として使用できます。次のように program.bin を実行しますLD_PRELOAD=libsdp.so program.bin。LD_PRELOAD=libvma.so program.bin

では、なぜ速度 (レイテンシーと帯域幅) に大きな違いがあるのでしょうか?

• VMA のレイテンシは SDP の 2.5 分の 1 です
• VMA の帯域幅は SDP の 1.8 倍です

イーサネット接続と Infiniband 接続の両方を持つコンピューター クラスターで実行される MPI プログラムがあります。mpavich2 の mpicc でコンパイルすると、自動的に Infiniband ライブラリにリンクされます。

mpi プログラムのコンパイル時に使用するネットワークを制御する方法はありますか?

mpicc のマニュアル ページを確認しましたが、役に立ちませんでした。

2TB のメモリを搭載したファット ノードがあります。新しい Connect-IB カードでは、MTT を増やしたいので、大きなメモリ領域を登録できます。HowTo Increase Memory Size used by Mellanox Adaptersのこの投稿を見つけましたが、Connect-IB でそれを増やす方法については言及されていませんでした。誰か私に何か提案をしてもらえますか?

IB ネットワークを介してファイルを交換する必要がある補足プロセスがあります。その後、ファイルは他のプロセスによって使用されます。

ワークフローは次のとおりです。

1. /dev/shm にファイルを作成する
2. ファイルのサイズを適切に変更する
3. プロセスの VM 内のファイルをマップする
4. mmaped 領域を ibv_reg_mr で登録します
5. データ転送の RDMA 操作を開始する

私のスキームのボトルネックは ib_reg_mr であることが判明しました (3Gb メモリの登録に 1.78 秒かかると個別に測定しました)。プロセスのアドレス空間へのメモリ領域のマッピングをトリガーするようです。残念ながら、受信プロセスはこのメモリを使用しないため、この操作は必要ありません。メモリは、後で他のプロセスでマップして使用する必要があります。

そのため、受信プロセスのページテーブルを変更することを回避するのが賢明だと思いましたが、それが可能かどうかはわかりませんでした。

メモリ領域をプロセスのアドレス空間にマッピングせずにデータ転送を開始する方法があれば教えていただけますか?

pcap 形式を使用して Infiniband パケットをキャプチャしようとしています。そのため には、 tcpdump の LINK-LAYER HEADER TYPESLINKTYPE_INFINIBAND 247 DLT_INFINIBANDに記載されているように使用する必要があると考えました。 Wireshark で pcap ファイルを開こうとすると、次のエラー メッセージが表示されます -

ファイル「ib.pcap」は、Wireshark がサポートしていないネットワーク タイプのキャプチャです。(pcap:ネットワーク タイプ 247 不明またはサポートされていません)

さらに、Wireshark のサンプル キャプチャでは、サンプルは InfiniBandです -

ファイル infiniband.pcap (8.7KB)
説明 DLT_ERF 形式の低レベル InfiniBandフレームの libpcap トレース ファイル。

では、DLT_INFINIBAND (247) が Wireshark によって認識されないのはなぜで、サンプルが DLT_ERF (197) を使用するのはなぜですか?

ありがとう！

仲間の RDMA ハッカーの皆さん、__ibv_get_cq_event() を呼び出す rdma_get_recv_comp() がタイムアウトになるかどうか知っている人はいますか?

私の問題は、ここに示されているのと同じプログラムにあります: RDMA プログラムがランダムにハングします

正常に動作しますが、ランダムなクライアントの切断に対して堅牢ではありません。具体的には、クライアントを強制終了すると、サーバーは rdma_get_recv_comp() / ipv_get_cq_event() でスタックします。

これは Mellanox ConnectX-3 用で、デフォルトのタイムアウトが 2.14 秒で、再試行 = 1 であることを確認しました。ただし、ブロック モードの ibv_get_cq_event() がタイムアウトになるかどうかはわかりません。ibv_modify_qp() ドキュメントのタイムアウトの説明は、送信者のみが ACK を待機するため、タイムアウトは送信 (rdma_get_send_comp()) にのみ適用されることを示唆しているようです。しかし、受信にもタイムアウトを許可することに問題はありません。

この場合、rdma_get_recv_comp() 内でのハングが予想される場合、どうすればそれを回避したり、タイムアウトを実装したりできますか?

いくつかの可能性:

1. サーバーで rdma_get_recv_comp() がハングしたままにならないように、必要なすべての送信を実行するようにクライアントのシャットダウン シーケンスを変更しますか?

2. rdma_get_recv_comp() を、受信完了をポーリングするループに置き換えます

ここで見つけることができるkrpringモジュールを機能させようとしています：http://git.openfabrics.org/?p=~sgrimberg/krping.git;a=summary

Mellanox ofed kernel 3.3 を介してドライバーをインストールします。すでに ofa-kernel/default から Module.symvers をコピーしましたが、機能しませんでした。

ubuntu 12.04 と 14.04 の異なるカーネルで試しました。私が使用したカーネルは、3.18、3.5、および 4.0 です。ただし、毎回同じ問題が発生します。誰かが krping をコンパイルして、これを手伝ってくれたら? 特に、カーネルのバージョン、OS、および使用したドライバーのインストール手順。

メイクファイル1

メイクファイル2

上記は、モジュールをコンパイルしようとした 2 つの makefile です。私が試すことができる変更を提案してください。

カーネル モジュールを使用して、Infiniband のカーネル空間で RDMA 転送を行っています (krping.cリンク: git.openfabrics.org Git - ~sgrimberg/krping.git/summary)。私が持っているカードは、Mellanox ConnectX-4 (ドライバー: mlx5)、Linux カーネル バージョン: 3.13、Ubuntu 12.04、および Mellanox OFED 3.3 です。

mutex_lockinmlx5_ib_query_qp関数 (mlx5_ib.h)の取得でコードがスタックしているようです。krping.cを使用してモジュールから呼び出されますib_req_notify_cq function。このエラー/デッドロックを解決する方法について助けてもらえますか? この投稿にdmesgトレースを添付しています。

Dmesg トレース:

クライアント側：

サーバ側：

クライアント側はカーネル空間で記述され、サーバー側はユーザー空間で記述されます。wc.status は 12 を返します。これにはどのような問題が考えられますか?