11th - NTTの10Gソフトスイッチ

2012/12/9 付で NTT の未来ねっと研が 10G ワイヤースピードが出るソフトスイッチを開発した、とアナウンスがあった。
当たり前なのだけれど、幾らか以上の条件が付いている。 まず総務省の委託研究とあるので、研究開発というか、まあほんとうに研究レベルである、と。 またワイヤーレートは「ロングパケット」である、と。これでも「ジャンボパケット」とは言っていないので、9.6KB ではなく 1.5KB のことなのかなと思うが、ちょっと僕には言い切れない。どうなんだろう。
ただいずれにしても 10 万フロー登録時に、というのだから結構なインパクトだと思う。
技術的なポイントとして幾つか挙がっている。 ユーザ空間における実装 最近なんだかこれが多い。12/8の記事でも取り上げた Solarflare の FPGA つきCPUオフロード用 NIC も、カーネルというか OS をなるべく通さないでユーザアプリケーションと直接データ交換することでシステム負荷を下げている。 マルチスレッド実装 リリースでは「フローの識別においては、パケットの順序逆転が起きないように、各パイプラインへの振り分けを行い、マルチスレッド対応としました」とある。
まあマルチスレッドにして性能が上がるようなものでは無いから、これはマルチスレッドをマルチコアで並走させる、ということを指しているはず。 ネットワーク機器がパケットの転送順序の逆転を嫌う（FIFO であって欲しい）理由は良く分かる。 が、これを完全に実装しようとおもったらとてつもなく長いバッファが必要で、普通それはやらない。 たとえソフト実装ならハード実装より遥かに楽にこれが実現できると言っても、ちょっとやるとは思えない。
代わりに「フロー内での順序逆転は起きない」が、「違うフローのパケットを追い越すことはある（順序関係は維持されない）」ならかなり自然な設計ができる。つまりリソースを大量投入せざるを得ないような無理なバファリングは起きない。 その意味ではリリース文面の「フロー識別」において「順序逆転が起きないよう」に並列化されたパイプラインに処理を「振り分け」て、それでもって「マルチスレッド対応」にした、という記述は興味深い。
つまりフロー識別のためのフィールドをハッシュするなりして、それをキーにマルチコアで待ち受けている各スレッドに振り分けているように僕には読める。 図でも「フロー識別」の後にパイプライン（並列処理部）があり、それらにかぶさるように「検索」処理があることもそれを思わせる。つまりフロー識別と表現されているのは振り分け処理だけ、という意味。
そうだとするとかなりストレートな実装ではないかなあ。 TCAM的三値の検索アルゴリズムの適用 もうこれについてはアルゴリズムを聞くしかない、という状況。論文出てないんだろうか。読みたい。
他にも「ハードウェア（サーバ？）の spec が分からない」といった話があるが、僕はもっとうがって、「このシステム、どの NIC に対応してるんだろう？」などと考えたりしている。 まさか Solarflare のような NIC を使って「ソフトウェアで」とは言わないだろうが、ユーザランドからの直接の呼び出しなど、ちょっと細かい芸が要りそうなので、幾らか縛られると思う。
検索アルゴリズムと全体アーキテクチャが気になる気になる。。 沖縄の SDN Japan に行くと見られるのだろうか。あったら是非どなたかアーキテクチャについて聞いて来て下さい。

References