IPファスト・パスはなぜ必要か? - 3つの (技術的な) 理由

Tomas Hedqvist

Nokiaをはじめとする企業がIPコミュニケーションの高速化を目的とするオープンソース・プロジェクトに投資する理由

 

An IP fast path can bypass the Linux kernel and the kernel/user space barrier

 IPファスト・パスによるLinuxカーネルとカーネル/ユーザー・スペースのバイパスNokia、ARM、Cavium、MarvellなどのCPUベンダー各社は、Linuxユーザー・スペースに実装されるアクセラレーテッドIPスタックの提供を目的としたオープンソース・プロジェクト「Open Fast Path」(OFP) に投資しています。

有力なハードウェア・ベンダーやネットワーク機器メーカーがオープンソース・プロジェクトに参加することは珍しくありませんが、なぜ独立したIPスタックが必要なのでしょうか?

当然のことながら、第一に挙げられるのはスピードへのニーズです。モバイル・インフラ領域などで利用されるネットワーク化アプリケーション (RANバックホール、BBU、RNC、EPCノードなど)、ネットワーキング・インフラ (ルーター、仮想スイッチなど)、ネットワーク・ファンクション (エッジ・キャッシュ、セッション・ボーダー・コントローラー、ファイアウォール、ウェブ・サーバー、ロード・バランサーなど) はすべて、高パフォーマンスのデータ・プレーンに依存しています。IPSecに見られるようなデータ量の増大、高ラインレート、パケット当たりワークロードの増加により、高スループット・低レイテンシを両立させるソリューションの需要が拡大しています。

次世代対応ネットワーク・アプリケーションでは、IPトラフィックの転送や終端を極めて効率的に行う必要があります。しかし、Linuxカーネル・スタックでこれを実現することは技術的に困難です。そこで、OFPがなぜ必要か、どのような技術的問題が解決されるのかについて、(技術的な観点から) 3つの理由を説明します。

 

理由その1:OFPの最適化

汎用IPスタックとしてのLinuxカーネル・スタックは、まれなケースも含め、発生する可能性のあるあらゆるケースやプロトコルに対応するよう設計されています。その結果、汎用性が高い代わりに速度が遅くなっています。この特性は、コントロール・プレーン向きと言えます。というのも、柔軟性と多様なプロトコルのサポートが不可欠である一方、スループットはさほど重要視されないからです。ところが、データ・プレーンでは、高スループットと低レイテンシが何よりも重視されます。

強力な最適化機能を可能にするために、OFPではプロトコルやユース・ケースのサポートが限られてきました。これにより、確かに柔軟性は制限されます。しかし、例えば、UDPトラフィックを終端させるデータ・プレーンの場合、柔軟性はあまり重要ではなく、大量のUDPパケットを可能な限り迅速に終端させることのみが求められます。ファスト・パスの範囲外のものはすべてスロー・パスで処理されますが、一般にこれはレイテンシやスループットのパフォーマンスの感度が低いトラフィックになります。

 

理由その2:OFPによるカーネル制限の回避

ここで重要なのは、OFPはユーザー・スペースに実装されるため、カーネル・スペース/ユーザー・スペースの障壁およびカーネル内部の処理により発生するレイテンシを回避できる点です。カーネル・スタックで処理されるシステム・コールにはコンテキスト・スイッチが不可欠です。また、カーネル・スタック内で頻繁にロックがかかるため、余計にレイテンシが発生し、スループットが低下します。OFPは、ODP (OpenDataPlane) やDPDK (Data Plane Development Kit) を使用して IP パケットに直接アクセスします。カーネルをバイパスし、パケットをネットワーク・ハードウェアかアプリケーションに直接渡すことにより、大幅なスループットの向上とレイテンシの低減を実現します。

 

理由その3:OFPのリニアな拡張性

OFPのもう一つの特長は、多数のコア、接続、エンドポイントにわたってリニアに拡張できることです。10Gbラインレートは既に最大容量14.88 Mpps (IPv6) を達成し、その合計処理時間は1パケット当たりおよそ67 nsに相当します。したがって、単一コア、または相当数のコアにより、ラインレートでパケットを処理することは不可能ではないことが簡単に推測できます。ただし、カーネル・スタックでパケット処理を拡張することは容易ではありません。さまざまなテクニックが使われ、それぞれに一長一短がありますが、いずれのテクニックにも共通して言えることは、極めて複雑な構成が必要になること、そしてハードウェアとの有線接続に依存せざるを得ないためにポータビリティが制限される場合があるということです。

 

結論

Nokia、Marwell、Cavium、ARM、Linaro、EneaがこぞってOFPプロジェクトを推進するのはなぜでしょうか?リニアに拡張可能な専用ファスト・パスを使用すれば、カーネルIPスタックの多くの欠点を解決でき、OFPは従来どおり機能することができます。ファスト・パスは、スロー・パスに比べてパフォーマンスが何倍も高いことが実証されているだけでなく、高プロファイル・アプリケーションにも使用できる安定したプロジェクトになっています。例えば、昨年開催されたLinux向けオープンソース・ソフトウェアのコンファレンスLinaro Connectにおいて、NokiaとCaviumは、OFPベースの5Gバックホールのデモを披露しています。また、Eneaは、最適化済みの商用OFPとして「Enea Fast Path」を提供しています。この製品は、既に数社に導入され、各自の5Gアクセスおよびコア・ネットワーク向けソリューションに統合されています。

オープン・ファスト・パスの詳細については、こちらをご覧ください

Enea Fast Pathの詳細およびベンチマーク・レポートについては、こちらをご覧ください