RoCEv2アップデート
RoCEv2 IBTA標準化完了(2014年9月16日)
以前、当ブログでも紹介したRoCEv2(Ethernet上で動作するRDMA規格のIPルーティングできる新しい規格)が、先週2014年9月16日、InfiniBand関連規格団体であるIBTA(InfiniBand Trade Association)での標準化が完了した。
Press Release: IBTA - InfiniBand Trade Association
InfiniBand Trade Association Releases Updated Specification for Remote Direct Memory Access over Converged Ethernet (RoCE)
New specification enables RoCE routing capabilities for the evolving enterprise data center and hyperscale networking infrastructure
RoCEv2標準化完了 プレゼンテーション動画（英語）
従来のRoCE(RoCEv1)とRoCEv2の違い
下記比較表の通り、RoCEv1に比べ、RoCEv2はIPルーティングに対応し、サブネットを越えてRDMA通信ができるようになった。
出典：Industry Ratifies RoCEv2 for Improved Hyperscale Computing
パケットフレームとしては、下記のようにRoCE(RoCEv1)にはIPヘッダやUDPヘッダが無く、InfiniBandのL2ヘッダをEthernetヘッダ(MAC)に変えただけだったが、
InfiniBandフレームとRoCEv1フレームとの対応
RoCEv2では、下図のようにIPヘッダ(L3ヘッダ)及びUDPヘッダ(L4ヘッダ)を備えている。中間にRoCE(IP Based)というものがあるが、これはRoCEv1.25なども呼ばれ(出典：Mellanox WinOF4.80 User Manual)、UDPヘッダがないものである。UDPヘッダは、L3でのルーティングにおいてマルチパス通信(ECMP: Equal Cost Multi Path等)を行う場合、L4のポート番号でのハッシュによるロードバランスが必要とされるため、UDPヘッダがある方が都合のよい場合がある。標準化されたのはUDPヘッダのあるRoCEv2である。
RoCEv2パケットを見てみる
観察環境：
NIC:Mellanox ConnectX-3Pro (40GbE)
OS:RHEL 6.5
Driver : MLNX OFED 2.3-1.0.1
実行アプリケーション: ib_send_bw (MLNX OFEDインストールで一緒にインストールされるRDMA性能測定ツール。詳細は後述の性能測定例にて。)
RoCEv1 - 設定 特になし（ドライバデフォルトで動作）
RoCEv1パケットの構成：
- Ethernet Type=0x8915(RoCE) : 後続のフィールドがIB GRH(Global Route Header)ヘッダであることを示している
- IPヘッダはない(=IPルーティングはできない)
RoCEv2 - 下記設定を実施
/etc/modprobe.d/mlx4.conf (無ければ作成)に、下記を追記する。
options mlx4_core roce_mode=2
追記後、ドライバのリスタートを実行する。
/etc/init.d/openibd restart
デフォルトでは、UDPポート番号は1021となる。変更する必要がある場合、/etc/modprobe.d/mlx4.confに、
options mlx4_core roce_mode=2 rr_proto=23456
などとする。
RoCEv2パケットの構成：
- Ethernet Type=0x0800 : IPv4
- IPヘッダがある（本例ではIPv4、IPv6にも対応している）
- UDPヘッダがある（本例ではDst portはデフォルトの1021、Src portは送信側アプリケーションによって様々に変わる=ECMPのマルチパス負荷分散が可能）
RoCEv2性能測定例
測定環境（環境の都合により、上述のパケットキャプチャ時とは別環境)：
NIC:Mellanox ConnectX-3Pro (40GbE)
OS:Ubuntu14.04LT
Driver : MLNX OFED 2.3-1.0.1
実行アプリケーション: ib_send_bw（使用方法は下図の実行例参照（"ib_send_bw -h"でヘルプ表示））
接続構成: Mellanox 40GbEスイッチ経由接続（本例ではロスレス設定等は無し）
結果：約37Gbps程度の性能を確認（RoCEv1でも実施、ほぼ同等性能）
RoCEv2ユーザー事例
当ブログでも以前紹介したが、Microsoft Azureのクラウドデータセンターで採用していると発表されている。
下記のRoCEv2標準化完了に関するニュースでもMicrosoft Azureに関するコメントが記載されている。
“RoCEv2 allows us to better scale our cloud deployment in a manner that is compatible with our evolving software defined networking infrastructure and growing virtualization demands, while achieving significant performance and efficiency benefits from RDMA,” said Albert Greenberg, partner development manager for Azure Networking at Microsoft. “Utilizing 40 Gigabit Ethernet solutions with RoCEv2 support is a key factor in enabling Microsoft Azure to efficiently, reliably and cost-effectively process the massive amounts of data required to support our customers’ wide range of workloads.”
補足：RoCEv1/RoCEv2通信でのスイッチの要件
RoCEは、中間バッファを排除したアプリケーションメモリ間のダイレクトなRDMA通信を行うため、送信相手が確実に受け取れる前提で送信するプロトコル（ロスレス通信プロトコル）である。
一方、回線上のビットエラー等による一定レベルのパケットロスは、NICハードウェアで再送されるため、ここでの「ロスレス」とは、完全にパケットロスでなければならないという意味ではない。ロスレスとは、送信速度が受信速度を上回らない通信速度を自動的に保つ仕組みである。受信側が受信処理が間に合わない場合、送信側に「ちょっと待て」とか、「ちょっと送信速度を落として」と伝え、送信側は受信側からのフィードバックを踏まえて送信できればよい。
受信速度を上回る通信レートで送信する場合、受信が追いつかないことを意味し、追いつかない分は受信側で破棄（パケットロス）となる。送信性能と受信性能が釣り合っている環境の場合、ロスレスプロトコルが動いていなくても、結果的にロスレスとなることになる。
余談として、Ethernetスイッチのポートバッファが話題となることがある。スイッチのポートバッファは、受信側が間に合わない場合にもポートバッファ分だけ貯めておける仕組みだが、10Gbpsや40Gbpsといった高速な通信速度で通信する場合、ポートバッファで保留できる時間は非常に限定的であり、広帯域ネットワークでの本質的な解決策とはならないため、ロスレスプロトコルの導入が望ましい。
MellanoxコミュニティサイトでのRoCE関連まとめ記事紹介
（ポイントを補足を含めて日本語にて追記）
RoCE v2 Considerations | Mellanox Interconnect Community
What are the network requirements for RoCE?
Both layer 2 and layer 3 RoCE share the requirement to configure the network for lossless operation. In fact, it does not mean that the network needs to be absolutely lossless. Some level of packet loss is acceptable. (for example as a result of bit errors that may occur at the physical layer). This is permissible as the transport protocol embedded within RoCE includes reliable services with built-in retransmission mechanisms. These reliability mechanisms are implemented in hardware and detect lost packets and retransmit without support required from software. An underlying lossless Ethernet network is required for RoCE traffic only in order to avoid systematic packet drops resulting from resource contention within network switches and adapters.
RoCEネットワークの要件とは？
- RoCEの要件は、L2やL3(RoCEv2の場合)でのロスレス実現である
- ビットエラー等による一定レベルのパケットロスはハードウェアで再送され、許容される
- ネットワークスイッチやアダプタのリソース（処理能力やバッファサイズ）による構造的なパケットドロップは回避すべき（いわゆるロスレス）
How do I achieve lossless Ethernet L2 network?
At the link level, it can be achieved by using flow control. Flow control is achieved by either enabling global pause across the network, or by the use of priority flow control (PFC). PFC is a link level protocol that allows a receiver to assert flow control telling the transmitter to pause sending traffic for a specified priority. PFC supports flow control on individual priorities as specified in the class of service field of the 802.1Q VLAN tag. Thus it is possible for a single link to carry both lossless traffic to support RoCE and other best effort traffic on a lower priority class of service.
ロスレスなL2 Ethernetネットワークはどのように実現するか？
- リンク層では、フローコントロールによって実現可能
- フローコントロールには２種類ある
- １）Global puaseによる通信全体のPause（送信抑制）
- ２）PFC(Priority Flow Control)による特定PriorityのフローのみのPause
- PFCでは、802.1Q VLAN tagフィールドのCOSビットで指定されたPriority単位でPauseを実行し、同一リンクに複数の性質のフロー（ロスを許容するTCP/IP通信等）が混在する場合には有効
参考資料
HowTo Run RoCE over L2 Enabled with PFC | Mellanox Interconnect Community
If I run RoCE v2, should I use PFC or global pause for lossless L2 subnet?
In a converged environment lossy traffic share the same physical link with lossless RoCE traffic. Typically separate dedicated buffering and queue resources are allocated within switches and routers for the lossless and best-effort traffic classes that effectively isolates these flows from one another. Although global pause configuration is easier and might work nicely in a lab condition, it is recommended to use PFC in operational network in order to be able to differentiate between different flows. otherwise, In case of congestion, important lossy traffic, such as control protocols may be affected. Therefore, RoCE should run on a VLAN with priority enabled with PFC, while the control protocols (lossy) will run without flow control enabled on different priority.
RoCEv2を動作させる場合、PFCやGlobal pauseのどちらを使ったらよいか？
- コンバージド環境（複数の用途の通信が広帯域ネットワークに統合された環境）では、Lossyなトラフィック（ロスを許容する通信）とLosslessなトラフィック（ロスレス通信）が混在
- ロスレス通信のみをPauseさせ、Lossyなトラフィック（例えばハートビート等）は許容するPFCの使用が望ましい
- （筆者注）ストレージ専用ネットワークのようにRoCEのみを使う場合はGlobal pauseでも問題ないと思われる
How do I preserve lossless characteristics on L3 network (between L2 subnets)?
Operating RoCE at layer 3 requires that the lossless characteristic of the network are preserved across L3 routers that connect layer 2 subnets. The intervening layer 3 routers should be configured to transport layer 2 PFC lossless priorities across the layer 3 router between Ethernet interfaces on the respective subnets. This can typically be accomplished through standard router configuration mechanisms mapping the received layer 2 class of service to the corresponding layer 3 Differentiated Serviced Code Point (DSCP) QoS setting.
L3ネットワークの場合、L2サブネット間でのロスレス性はどのように保持するか？
- L3でのRoCE(RoCEv2)では、L3ルーター経由でのロスレスを実現する必要がある
- L2 PFCでロスレス設定されたPriorityをL3ルーターは送信先L2サブネットへ伝播させる必要がある
- 典型的にはL2のCOSをL3のDSCP QoSにマッピングする仕組みで実現する
参考資料
What happens when I use multi-path routing (ECMP) on L3 networks?
Rather than being constrained by layer 2 link-breaking protocols such as spanning tree algorithm, layer 3 networks can implement forwarding algorithms that take much better advantage of available network connectivity. Advanced data center networks can utilize multi-path routing mechanisms for load balancing and improved utilization. One commonly used protocol to achieve these goals is Equal Cost Multiple Path (ECMP). For each received packet the L3 Routers make a forwarding decision based on not just the destination IP address but also on other fields within the packet. In cases where there are many possible paths to a given endpoint ECMP allows different flows to select different paths and thus to leverage the available connectivity. The path selection for a given packet is based on the destination IP address and a hashed value of other packet fields. Note that while different flows can exploit different paths, the values used to select the output port for forwarding is deterministic such that packet ordering for a given flow is preserved.
L3ネットワークでのECMPについては？
- 先進的なデータセンタネットワークでは、L3でのECMPマルチパス活用でのネットワークが構成され、負荷分散と可用性を実現している
- ECMPでは、L3ルーターでの送信先は、送信先IPアドレスだけでなく、パケットの他のフィールド値でのハッシュ計算で決定され
- １つのフローではパケット順序が保たれるようなフィールド値と計算方法が用いられる（（筆者注）例えば、UDPポート番号）
Mellanox Windowsドライバ WinOF4.70でのアップデート
日本ではゴールデンウィークの最中でしたが、日本時間2014年5月5日の深夜に下記WEBにてさりげなくリリースとなっています。
Mellanox Products: Mellanox OFED for Windows (WinOF)
下記に概要とトピックを説明します。
MellanoxのWindowsドライバは、VPI(Virtual Protocol Interconnect)版ドライバです。
（InfiniBandとEthernetの両方をサポートするドライバ）
Mellanox WinOF Rev 4.70 New Features（リリースノートから抜粋）
- Ethernet SR-IOV over Windows Hyper-V Hypervisor (over Windows 2012 R2)1
- Virtual Ethernet Adapter support (over Windows 2012 and above)2
- RoCEv2: RoCE over Layer 3 networks (only for ConnectXR-3 Pro)
- Lossless TCP buffer management when no receive WQE are available
- IPoIB SR-IOV over KVM Hypervisor (Beta level)
今回のリリースでは大きなアップデートが２点あります。
１．RoCEv2のサポート
RoCE Version 2という新しいプロトコルがサポートされました。
元々RoCEは、InfiniBandフレームの最下位ヘッダをEthernetヘッダに置き換えただけのものであったため、IPヘッダが存在せず、IPルーティングが出来ないという制約がありました（参考：当ブログ過去記事）。EthernetベースでのRDMAプロトコルであるRoCEでL3でのスケーリングが出来ればさらに大規模で柔軟なシステム構成が可能となるため、RoCEのL3対応は長らく課題とされていました。
RoCEv2は、そのような課題を解消し、理想的なプロトコルを実現するものであり、L3活用でのオーバーレイネットワークの方向性と合わせて投入された新世代のプロトコルであると言えます。
本プロトコルは非常に新しいため、今後随時情報アップデートを行っていきたいと思います。
今後色々なシステムで検証が実施されていくのが楽しみです。
参考：例外的に既に使用しているユーザーも存在します。当ブログの過去エントリ、
http://rdma.hatenablog.com/entry/2014/04/28/212936
で紹介したスライドをよく見るとはっきりと書いてあります。
２．Virtual Ethernet Adapterのサポート(vea_manコマンド）
詳しくはドライバユーザーマニュアル「8.11 Virtual Ethernet Adapter」の章を参照。
このコマンド(vea_manコマンド）を使用すると、１つの10/40GbE物理ポートを２つの論理ポートとしてWindows OSへ提供できます。
従来より同様のコマンドはInfiniBand向けにはサポートされていました(part_manコマンド）が、Ethernetでは未サポートでした。
WinOF4.70では、Ethernetでもサポートという点がアップデートです。
なぜ論理ポート追加コマンドが必要か
理由：SMB Direct(RDMA)と仮想スイッチ経由のアクセスを同一物理ポートで共存させるため（I/O統合(Unified I/O)の実現）
http://technet.microsoft.com/ja-jp/library/jj134210.aspx
SMB ダイレクトを使用する場合の考慮事項 より抜粋(※Windowsの仕様です)
part_manコマンド(InfiniBand)、vea_manコマンド(Ethernet)を使って１つの物理ポートを２つの論理ポートとしてWindowsへ提供することで、上記制約事項をクリアし、RDMAと仮想スイッチの両立を実現できます。
# 本件については別エントリとして記事作成を予定しています。
Microsoft Azureでの40GbE RoCE (RDMA over Converged Ethernet)活用
Microsoft Azure
Microsoft Azureといえば、InfiniBandで動くHPCクラウドが2012年11月のSC12にてスパコンTOP500にランクイン(165位)し、2013年11月時点では、TOP500の309位にランキングされている。
Windows Azure Benchmarks Show Top Performance for Big Compute
TOP500 site : http://www.top500.org/site/50454
一方、表題のMicrosoft Azureでの40ギガビットイーサネットベースでのRDMA(RoCE)活用は、HPCクラウドではなく、より広く使われている一般的なIaaSサービスの方だと思われる。
2014年3月に開催されたONS(Open Networking Summit)2014にて発表された内容がYouTubeにアップされている。以下に該当部分をピックアップする。
Microsoft Azure - Software Defined Storage : 40GbE RoCE (RDMA)
- ストレージコストを抑えるため、ネットワークに投資。コモディティーサーバを高速ネットワークで接続した構成。
- Erasure Code(消失符号)を活用し、データの冗長性を担保。データライトに対して、３つのコピーライトが実行される。（引用者注：コピーライト完了がクライアントからの応答性能に含まれるため、コピーライトの完了をいかに速くできるかがライト性能のポイントとなり、後述のRDMAが効果を発揮する）
- 40ギガビットイーサネットRoCE (RDMA over Converged Ethernet)が動作
- Software Defined Network - 全ての機能はホスト側(RDMA対応NICとドライバソフトウェア)で実現（ネットワーク機器は特別なものではない）
- オールL3(IPベース)でRDMAが動作（※本稿執筆時点では詳細未公開）
- 極めて速いレイテンシー：E2Eで2us未満（スライド参照）
- RDMAにより、ホストCPUの負荷を削減し、圧倒的なコストパフォーマンスを実現
- 40Gbpsで通信をしている状態でもホストCPU使用率はゼロ(RDMAの特長）
- 実際にパフォーマンスメーターで0%を確認
伊勢雅英氏のInfiniBand関連記事まとめ
久々に伊勢雅英氏のInfiniBandの記事が掲載となっているので、これまでの記事をまとめてみた。伊勢氏の最初のInfiniBand記事2004年からちょうど10年。10年前にはクラウドやデータセンターという話題がまだほとんど無かったと言ってもよく、随分と状況は変わった。
今回の記事は、ユーザー事例に加え、新動向としてRoCEが取り上げられている点に注目である。RoCEを使えば、慣れ親しんだEthernetでありながらInfiniBandの性能の核心であったRDMAが使える。「運用性と転送効率を両立した新世代のプロトコル」と紹介されているが、クラウド、データセンターといった外側ネットワークとの接続や従来のVLAN運用が必要となる部分にもRDMAが活用できるようになってきた、という10年前には無かった、最近のニーズに合わせた動向と思う。
RoCEの登場によって10G/40G Ethernetの魅力がさらに増す
InfiniBandがどれだけ高速であろうと、実績の豊富なEthernetを使いたいと思う人がいるのも事実だ。InfiniBand製品は、Mellanoxを中心とする極めて少数のベンダーしか手がけていないが、Ethernet製品であればさまざまなベンダーから選べるからだ。また、接続先となるストレージシステムも、InfiniBandポートをネイティブに備えた製品はまだ少なく、Ethernetポートを搭載した製品が圧倒的に多い。
これまでを振り返ると、InfiniBandがネイティブでRDMA技術をサポートしていたのに対し、Ethernetは通信効率の面で見劣りする部分があった。しかし、近年ではInfiniBandで培われた広帯域・低レイテンシの通信技術をEthernetに適用したRoCE（RDMA over Converged Ethernet）が実製品のレベルで登場している。RoCEは、フロー制御によるロスレスの10Gigabit/40Gigabit Ethernet（10GbE/40GbE）を足回りとしながら、その上でInfiniBand譲りのRDMA転送を行う、運用性と転送効率を両立した新世代のプロトコルである。
過去記事
- InfiniBand探検隊リターンズ【前編】〜2012年現在も進化を続けるInfiniBandの最新状況 - クラウド Watch (2012/1/26)
- InfiniBand探検隊リターンズ【後編】〜広帯域I/Oを必要とする仮想化やDB分野で強く期待されるInfiniBand - クラウド Watch (2012/1/27)
SMB Direct - 40GbE RoCE 実機デモ - Interop Tokyo 2013
Interop Tokyo 2013でのSMB Direct実機デモ内容の記録。
40GbE(RoCE) x 2本をSMB Multichannelで束ね、SMB DirectでのファイルシステムI/OをIOmeter(1MBシーケンシャルリード)で実行するデモを会場ブースにて実施した。
デモ概要
- 日時：2013年6月11日-14日
- 場所：Interop Tokyo 2013 幕張メッセ 展示会場
デモの目的
- Windows Server 2012環境での40GbE End-to-End接続を実証
- 40GbE RoCE(RDMA over Converged Ethernet)でのSMB Directアクセスが安定して充分な性能が出ることを実証
- SMB Multichannelにて安定動作し、片パス障害及び障害復帰時にアクセスが途切れることなく動作することを実証
性能はストレージの構成やサーバーの構成によるため、あくまで一例としてだが、展示会場でのデモでは、２パスで7,000MB/sを超えるスループット性能を確認した。
２パスでの接続状況(SMB Multichannel / SMB Direct)
展示会場では一方のパスのケーブルをオンラインで抜き差しするデモも実施。
ストレージアクセスが途切れることなく、片パスの抜き差しが出来ることを実演。
片パスを抜いた場合の状況(SMB Multichannel(1パス) / SMB Direct)
参考：デモを含めて展示内容を紹介する動画（RBBtoday)
RoCE(RDMA over Converged Ethernet)
RoCEは、「アールオーシーイー」または「ロッキー」と発音する。
- Ethernet上でRDMA転送を行うことができるネットワークプロトコル
- 下位レイヤのネットワークヘッダはEthernetヘッダであり、上位レイヤのネットワークヘッダ（データ部分を含む）はInfiniBandのヘッダである。
- 標準的なEthernet環境（ロスレス機能が備わったスイッチ）でRDMA転送を行うことを可能であり、NICがRoCEをサポートしている必要がある。
RoCEフレームフォーマット
出典： IBTA Supplement to InfiniBandArchitecture Specification Volume 1 Release 1.2.1 - Annex A16:RDMA over ConvergedEthernet (RoCE)
RoCEとInfiniBandとの比較
RoCEの最下位レイヤのフレームヘッダは、標準的なEthernetフレームと同じである。
また、上位のネットワークヘッダはデータを含めてInfiniBandと同じである。
リモートダイレクトメモリアクセス(Remote Direct Memory Access : RDMA)の紹介
#本記事は、下記ブログの日本語訳（＋一部補足）版を原文筆者Dotan Barak*1の了解を得て掲載しています。
Introduction to Remote Direct Memory Access (RDMA) - RDMAmojo
目次
- RDMAとは？
- RDMAの利点
- RDMAをサポートするネットワークプロトコル
- RDMAを使うために複数のプログラムAPIを学ぶ必要がある？
- RDMAをサポートするネットワークプロトコル相互の互換性は？
- RDMAを使うには？（特別なパッケージをダウンロード？ OS付属？ ）
1.RDMAとは？
ダイレクトメモリアクセス(Direct Memory Access (DMA))は、CPUが介在することなく、ホストメモリへ直接アクセスを行うデバイスの機能である。
RDMA (Remote DMA)は、CPUが関与することなくネットワーク越しにリモート計算機上のメモリへアクセスする（すなわち、リモート計算機上のメモリからリードおよびリモート計算機上のメモリへライトする）機能である。
翻訳者補足：データを水にたとえると・・・
TCP/IP : バケツリレーして水を運ぶような方式。バケツの数には限りがあるし、運ぶのに労力が掛かる。
（性能に限界あり、CPU負荷大）
RDMA : 太いホースで繋いで水道の蛇口を開けるような方式。送りたい水（データ）を一気に流し、流し終わったら送り側の蛇口を閉めるだけ。
（帯域をフルに活用、CPU負荷ゼロ（データ転送時））
※FibreChannel等のチャネル系プロトコルとの違いは？
FibreChannel等では最大でも1MB程度のサイズの細切れでバッファ確保／開放を通信ペアで確認しながら送受信。細切れサイズ毎にCPU割り込みやドライバ処理が発生するため、性能には限界がり、CPUも使ってしまう。
一方、RDMAでは、ローカルとリモートの大きなメモリ領域の間で連続的にデータ転送(最大GB単位での連続転送)をすることができる。また、細かいサイズの転送であっても、バッファ確保を通信の都度行う必要がないので（ワンサイドオペレーション(One Side Operation)でのデータ通信が可能）、圧倒的に低いレイテンシと高スループットを実現することができる。
2.RDMAの利点
RDMAを用いることによる主なメリット：
ゼロコピー (Zero-copy)
アプリケーションは、ネットワークソフトウェアスタックを経由することなくデータ転送を行うことができ、データはネットワークレイヤ間のコピー無しでバッファへ送信または受信される。
カーネルバイパス (Kernel Bypass)
アプリケーションは、ユーザ空間から直接データ転送されるため、コンテキストスイッチを行う必要がない（コンテキストスイッチには非常に多くのCPU処理が必要とされるため、コンテキストスイッチを減らすことは性能向上に直結する）。
CPUの介在がない (No CPU Involvement)
アプリケーションは、リモート計算機のCPUを全く使うことなくリモートメモリにアクセスすることができる。リモート計算機は、リモートプロセス（プロセッサ）が介在することなくメモリリードを行うことができる。リモートCPUのキャッシュは、アクセスされたメモリデータで使用されない（したがって、CPUキャッシュを無駄に消費する必要がない）。
メッセージベースのトランザクション (Message Based Transactions)
データはストリームではなく、離散的なメッセージとして処理される。このことにより、アプリケーションは別のストリームを別々のメッセージやトランザクションとして処理する必要がない。
スキャッタ／ギャザー処理のサポート (Scatter/Gather Entries Support)
RDMAは、スキャッタ／ギャザー処理をネイティブサポートしている。すなわち、複数のメモリバッファ（メモリ領域）を読み込んで１つのストリームとして送信したり、１つのストリームから複数のメモリバッファ（メモリ領域）へ書き出したりすることができる。
3.RDMAをサポートするネットワークプロトコル
現時点でRDMAをサポートするネットワークプロトコルの例：
InfiniBand（インフィニバンド）
初めからRDMAをネイティブサポートする新世代のネットワークプロトコルである。新しいテクノロジーのため、このテクノロジーをサポートするNIC（InfiniBand規格ではHCA (Host Channel Adapter)と呼ぶ）とスイッチが必要となる。
RDMA Over Converged Ethernet (RoCE)（アールオーシーイーまたはロッキー）
Ethernet上でRDMA転送を行うことができるネットワークプロトコルである。下位レイヤのネットワークヘッダはEthernetヘッダであり、上位レイヤのネットワークヘッダ（データ部分を含む）はInfiniBandのヘッダである。このプロトコルは、標準的なEthernet環境（スイッチ）でRDMA転送を行うことを可能とする。NICのみが特別なものであり、RoCEをサポートしている必要がある。
Internet Wide Area RDMA Protocol (iWARP)
TCP上でRDMA転送を行うネットワークプロトコルである。InfiniBand (RDMA)とRoCEではサポートされていてiWARPではサポートされていない機能がある。このプロトコルは、標準的なEthernet環境（スイッチ）でRDMA転送を行うことを可能とする。NICのみが特別なものであり、iWARPをサポートしている必要がある（ただし、CPUオフロードが使われる場合）。CPUオフロードを使用しない場合は、全てのiWARPスタックはソフトウェアとして実装可能であるが、RDMAの性能的な長所の大部分は失われてしまう。
4.RDMAを使うために複数のプログラムAPIを学ぶ必要がある？
前章でRDMAをサポートするネットワークプロトコルが複数あることを述べた。そうすると、RDMAを使うにはそれぞれ別のプログラムAPIを習得する必要があるように思えるかもしれないが、答えは「いいえ」（複数のプログラムAPIを学ぶ必要はない）である。幸運なことに、同じAPI（すなわち、verbs）は、上記の全てのRDMA対応のネットワークプロトコルで使用可能である。Liux系ではlibibverbsとKernel verbsであり、WindowsではNetwork Direct (ND)に相当する。
5.RDMAをサポートするネットワークプロトコル相互の互換性は？
RDMAをサポートするネットワークプロトコルは互いに異なるプロトコルであるため、パケットフォーマットが異なり、それら相互に直接メッセージの送受信はできない。何らかのルータやゲートウェイを挟む必要がある。しかしながら、同じコードでRDMAネットワークプロトコル全てをサポートすることができる。全てのRDMAネットワークプロトコルはlibibverbsをサポートするため、ソースコードの再コンパイルさえも不要で同じバイナリを使用することができる。
6.RDMAを使うには？（特別なパッケージをダウンロード？ OS付属？）
いくつかのOSでは、Kernel標準でRDMAをサポートしている。例えば、LinuxはRDMAをネイティブサポートしており、Linuxの主要なディストリビューションでRDMAをサポートしている。その他のOSではRDMAサポートを追加するためにある種のパッケージ（OFED等）をダウンロードする必要となる場合がある。
*1:Dotanは当ブログ筆者と同じハイテク企業に勤務しており、当ブログ筆者も本社にて彼の技術講座を受講したことがあります。
