100Gbpsソフトウェアルータの実現可能性に関する論文

前回のGPUを用いたSSLリバースプロキシの実装について - ゆううきブログに続いて，同じ研究グループが出している100Gbpsのソフトウェアルータの実現可能性に関する論文を読みました．

Sangjin Han ; KAIST, Daejeon, South Korea ; Keon >Jang ; KyoungSoo Park ; Sue Moon

"Building a single-box 100 Gbps software router" Local and Metropolitan Area Networks (LANMAN), 2010 17th IEEE Workshop on

IEEE Xplore - Building a single-box 100 Gbps software router

論文紹介

現在または予測可能な未来の技術を用いて，100 Gbpsのソフトウェアルータを構築することができるかどうかが考察されています．できるかどうかは明言されていませんが，I/O周りのボトルネックの削減がまだ難しそうという印象でした．

論文では，近年のIntel/AMDの改良されたアーキテクチャ（マルチコアプロセッサ,CPU統合メモリコントローラ，PCI Express，マルチCPUソケット，QPIなど）を用いて，100Gbpsソフトウェアルータを実現しようとするとどこがボトルネックとなるかが書かれています． IPルーティングまでは考えておらず，パケットの送信，受信，フォワーディング性能のみ考慮されています．

具体的には，以下のようなCPUソケット2個，IOハブ2個，2ポートの10GbE NICを６個もつNUMAな構成を例にとり，CPUサイクル，I/O帯域幅，メモリ帯域幅の観点で何がボトルネックとなるかが議論されています．

f:id:y_uuki:20130514233714p:plain

CPUサイクル，メモリ帯域幅については測定値というよりは理論性能を元に考察されていますが，I/O帯域幅については上記構成を単純化したいくつかの構成を用いて，どのリンクがボトルネックかを実験で測定した値を用いて議論されています．

CPUサイクルについては，パケットの動的確保をやめて静的に確保して使いまわすなどいくつかの最適化を施し，なおかつパケットI/O以外のIPルーティングなどの処理をFPGAまたはGPUにオフロードすれば，CPUサイクルはさほど問題にならないということでした．

ちなみに，IPルーティングやIPsecをGPUで高速化する話は下記の論文にあります．

PacketShader - GPU-accelerated Software Router

I/O帯域幅については，PCIeリンクおよびQPIリンクの実効帯域はさほど問題ではないが，マルチIOハブ構成時にIOハブ数にパケットの受信性能がスケールしないようです．IOハブのchipsetがマルチIOに対して最適化されていない？ような感じでした．

(PCIeについてはPCIe 2.0 x8で実効帯域幅が双方向で32Gbps以上なので2ポートの10GbE NICの帯域を損なわない． QPIについては双方向で100Gbpsくらいでるので，一方のノードに受信パケットが偏っていてなおかつそれらのパケットをもう一方のノードにフォワーディングするような状況でなければ，問題ない．)