第 3 章 関連研究および関連技術
U- Net/MM
3.2.8 Genoa Active Message MAchine (GAMMA)
Genoa Active Message MAchine (GAMMA)[110] [111]はGenoa大学で開発されたEthernet向け の軽量通信ライブラリである．元々Fast Ethernet用に開発され，後にGbE向けに実装が行われた．
以下ではまず3Com社の3c595および3c905向けに実装されたFast Ethernet向けのGAMMAにつ いて述べる．
GAMMAの通信モデルは，送信側でメッセージハンドラを指定し，受信側でメッセージ受信後
ハンドラが呼び出されて受信データの処理が行われる，AMの通信モデルを元にしている．
各プロセスはActive Port [112]と呼ばれる複数のポートを持ち，これを通じてメッセージの送受 信を行う．送信処理は，プロセスがGAMMAのデバイスドライバ内の関数を呼び出すことで起動 する．各メッセージは，デバイスドライバによって適宜分割され，連続したEthernetのフレーム としてリモートに送信される．その際，ユーザ領域上のバッファからネットワークインタフェー スのFIFOに対して直接DMAでデータの転送を行うため，カーネルによるバッファリングは行 われない．フレームのヘッダは，あらかじめポートをバインドする際に計算しておく．最後のフ レームの送信が済んだらシステムコールから戻る．
一方，受信側では，通信に先立ってユーザ関数であるハンドラと受信バッファをポートに対して バインドしておく．受信バッファは，受信したメッセージをハンドラが起動するまで保持するのに 用いる領域であり，メッセージが到着すると割込みに応じてGAMMAのドライバが動き，DMA を用いてこの領域に対して受信データを転送する．そのため，受信バッファは事前にピンダウン しておく必要がある．最後のフレームが受信されたら，GAMMAのドライバはポートに対応する
ハンドラを呼び出し，直ちにデータの処理を行う．その際，ドライバが一時的にコンテキストを 切り替え，受信側のプロセスのコンテキスト上でハンドラが実行されるようにする．通常，プロ セス内のハンドラは，メッセージをメインのスレッド内の領域に必要に応じて退避し，メインの スレッドにメッセージの到着を通知した上で，次のメッセージの受信用の領域をポートに対して バインドする．
このように，GAMMAでは送信側と受信側の双方においてメッセージのゼロコピー通信が行わ れる．
GAMMAは，CRCによるエラー検出と通知を行うが，再送などのエラー回復やフロー制御は提
供せず，エラーへの対処は上位アプリケーションの判断に委ねられる．また，GAMMAの通信レ イヤは，大部分がLinuxのカーネルレベルで実装されており，残りの一部はユーザライブラリに 実装されている．
GAMMA on DEC 2114x
GAMMAは元々3Com社の3c595および3c905向けに実装されていたが，ネットワークインタ
フェースの入手が困難となったなどの理由から，新たにdescriptor-based DMA (DBDMA)と呼ば れる機構に対応したDEC社のDC21140向けに移植された[113]．DBDMAでは，ネットワーク インタフェースはホストメモリとネットワークの間のDMAを，ホストメモリ上に事前に用意し たDMAディスクリプタを用いて行う．これまでのGAMMAの実装では，ホストCPUがネット ワークインタフェースのDMAを直接起動し，DMA開始後，CPUは次のDMAを始めるには今 のDMAが完了するのを待たなければならない．そのため，長いメッセージを送る場合，CPUが ブロックされてしまうという問題があった．DBDMAを用いたGAMMAでは，送信側は要求され たメッセージを複数に分割し，分割した数分のディスクリプタをキューにいれて送り出す．その 後は，ネットワークインタフェースがキューからディスクリプタを読み出してDMA転送を行う ため，ディスクリプタをキューに格納した時点でプロセスに戻るノンブロッキング送信が可能と なる．
一方，DBDMAにおける受信処理では，ネットワークインタフェースは，受信データをホスト
上ディスクリプタの指すバッファに対してDMAで書き込み，それが完了した上でホストに割込 みをかける仕様となっている．割込みが発生した時点で受信データがホストメモリ上に存在する ことになるため，受信したデータをユーザプロセスに渡す際にメモリ間コピーが発生することに なり，従来の実装で実現されていたメッセージのゼロコピー通信が不可能となる．
また，GAMMAではGO back N方式で再送制御を行うことで順序性を維持するが，この方式で
はパケットが消失した場合の再送量が大きいためネットワークの混雑が発生してしまう．GAMMA の想定するEthernet環境では，パケットの消失はネットワークでのエラーによって引き起こされ ることは稀であり，ほとんどの場合，受信バッファのオーバーフローによるパケットの破棄が原 因である．DBDMAを用いた実装では，スイッチがIEEE 802.3xのフロー制御に対応していない 場合にも受信バッファのオーバーフローが発生しないよう，クレジットベースのフロー制御が新 たに追加されている．
GAMMA on GbE
GbE向けのGAMMAは，当初Packet Engines社のG-NIC IIとNetgear社のGA620に対して実 装が行われた[8]．GA620はNIC上にプロセッサを持ちプログラマブルな環境を提供しているが
GAMMAはこれを利用しない実装となっている．
GbE向けのGAMMAのプロトコルは，基本的にDC21140向けの実装と大きな違いはない．
GAMMAのプロトコル自体は特定のネットワークインタフェースの機能に依存しない作りとなっ
ているため，Basic Interface for Network Device Drivers (BIND2) と呼ばれる割込みやディスクリ プタの扱いなどの個々のネットワークインタフェースで処理が異なる部分をまとめた小さなコー ドセットを用意し，既存のデバイスドライバをGAMMAに対応できるよう修正することで一般 的なGbEのネットワークインタフェースに対して移植を行うことができる．現在ではIntel社の PRO/1000シリーズや，Broadcom社のTigon3チップなどがサポートされている．
3.2.9 まとめ
これまで述べたクラスタ向けの低レベル通信ライブラリは，Remote procedure call (RPC)型の 通信モデル，Send/Recvのメッセージ通信型の通信モデルおよびPut/GetなどのRMA型の通信モ デルのいずれか，あるいは複数を組み合せたものを提供している．また，ユーザレベルでの通信 呼び出しや通信時のユーザメモリ–カーネルメモリ間のメモリコピーを排除するゼロコピー通信 などが取り入れられているものも多い．これら通信ライブラリのほとんどは1990年代後半に提案 されたものであるが，PMやGAMMAなどは現在でもそのままの形で最新のOSやハードウェア に追従し，利用されている．
2.3.2節で簡単に触れたが，RHiNET-2のネットワークインタフェースコントローラであるMartini は，PUSHおよびPULLのみをハードウェアで提供し，それ以外の通信処理はソフトウェアで実 装するという方針をとっている．さらにMartiniではPUSHでリモートプロセスのメモリにメッ セージを書き込んだ際に，書き込み完了後に相手に割込みをかけるなどの通知手段が用意されて おらず，受信側は，積極的にメモリをポーリングすることでメッセージの受信を検出することが 前提となっている．このようなネットワークインタフェース上に構築されている低レベルな通信 ライブラリは，これまで述べた中にない．Martiniを用いた低レベルソフトウェアライブラリで上 位にメッセージ通信などの通信モデルを提供する場合，高性能なハードウェアによる通信処理を 積極活用するならば，これまで述べた低レベル通信ライブラリとは全く異なる通信機構の実装が 必要となると考えられる．