TCPオフロードエンジン

TCPオフロードエンジン（TOE ）は、一部のネットワークインターフェースカード（NIC）で使用されている技術で、 TCP/IPスタック全体の処理をネットワークコントローラーにオフロードします。主にギガビットイーサネットや10ギガビットイーサネットなどの高速ネットワークインターフェースで使用され、ネットワークスタックの処理オーバーヘッドが顕著になります。TOEは、iSCSIやネットワークファイルシステム（NFS）などのインターネットプロトコル（IP）ストレージプロトコルに関連するオーバーヘッドを削減する手段としてよく使用されます[ 1 ]。

目的

もともとTCPは信頼性の低い低速ネットワーク (初期のダイヤルアップモデムなど) 向けに設計されたが、インターネットのバックボーン伝送速度 (光キャリア、ギガビット イーサネット、10 ギガビット イーサネットリンクを使用) とより高速で信頼性の高いアクセス メカニズム ( DSLやケーブル モデムなど) の成長に伴い、1 ギガビット/秒を超える速度でデータ センターやデスクトップPC環境で頻繁に使用されるようになった。このような速度では、ホスト システム上の TCP ソフトウェア実装にかなりの計算能力が必要になる。2000 年代初頭には、全二重ギガビット TCP 通信は 2.4 GHz Pentium 4プロセッサの 80% 以上を消費することがあり[ 2 ] 、システム上でアプリケーションを実行するための処理リソースがほとんど残らないか、まったく残らない状態になった。

TCPはコネクション指向プロトコルであり、複雑さと処理オーバーヘッドを増加させます。これには次のような側面があります。

これらの機能の一部またはすべてを専用のハードウェア (TCP オフロード エンジン) に移動すると、システムのメインCPU が他のタスクに使用できるようになります。

解放されたCPUサイクル

一般的に受け入れられている経験則は、送信または受信には1ヘルツのCPU処理が必要であるということです。1 ビット/秒のTCP/IP。[ 2 ]例えば、5ギガビット/秒（625 MB/秒）のネットワークトラフィックには5GHzのCPU処理能力が必要です。これは、5ギガビット/秒のTCP/IPトラフィックに関連するTCP/IP処理能力を持つ2.5GHzマルチコアプロセッサのコア2つが必要となることを意味します。イーサネット（この例では10GE）は双方向であるため、 10ギガビット/秒（合計スループット20ギガビット/秒）の送受信が可能です。1Hz /(ビット/秒)ルールを用いると、これは8つの2.5GHzコアに相当します。

TCP/IP処理に使用されていたCPUサイクルの多くはTCP/IPオフロードによって解放され、CPU（通常はサーバーCPU）がファイルシステム処理（ファイルサーバー）やインデックス作成（バックアップメディアサーバー）といった他のタスクを実行するために使用できます。つまり、TCP/IPオフロード機能を備えたサーバーは、TCP/IPオフロードNICを備えていないサーバーよりも 多くのサーバー処理を実行できます。

PCIトラフィックの削減

TOE はプロトコルオーバーヘッドの解決に加え、ホストベース（サーバーおよび PC）のエンドポイントの大部分に影響を与えるアーキテクチャ上の問題にも対処できます。多くの旧式のエンドポイントホストはPCIバスベースであり、サーバーや PCへのネットワークインターフェイスなどの特定の周辺機器を追加するための標準インターフェイスを提供しています。PCI は、メインメモリから PCI バスを介してネットワークインターフェイス IC に少量のデータバーストを転送するのには非効率的ですが、データバーストサイズが大きくなるにつれて効率は向上します。TCP プロトコルでは、多数の小さなパケット（確認応答など）が生成されます。これらのパケットは通常、ホスト CPU で生成され、PCI バスを介してネットワーク物理インターフェイスから送信されるため、ホストコンピュータの IO スループットに影響を与えます。

ネットワーク インターフェイス上に配置された TOE ソリューションは、CPU ホストとは反対側の PCI バス上に配置されているため、TCP 接続を介して送信されるデータは、PCI バスを通過する小さな TCP パケットを必要とせずに、大きなデータ バースト サイズを使用して PCI バスを介して CPU から TOE に送信できるため、この I/O 効率の問題に対処できます。

歴史

この技術における最初の特許の一つであるUDPオフロードは、1990年初頭にAuspex Systemsに付与されました。 [ 3 ] Auspexの創業者であるラリー・ブーシェ氏と数名のAuspexエンジニアは、ネットワークスタックオフロードの概念をTCPに拡張し、カスタムシリコンに実装するというアイデアを掲げ、1997年にAlacritechを設立しました。彼らは1999年初頭に、初のパラレルスタック・フルオフロード・ネットワークカードを発表しました。同社のSLIC（セッション層インターフェースカード）は、現在のTOE製品の前身です。AlacritechはTCP/IPオフロード分野で多数の特許を保有しています。[ 4 ]

2002年までに、 iSCSIなどのTCPベースのストレージの出現が関心を刺激し、「ドットコムバブルの終わり頃に設立された少なくとも12社の新規参入企業が、ストレージプロトコルとアプリケーション用の商用半導体アクセラレータの機会を追い求め、6社の既存ベンダーや社内ASIC設計と競合している」と言われました。[ 5 ]

2005年、MicrosoftはAlacritechの特許基盤のライセンスを取得し、Alacritechと共同で、後にTCPチムニーオフロードとして知られる部分的なTCPオフロードアーキテクチャを開発しました。TCPチムニーオフロードは、Alacritechの「通信ブロックパッシング特許」を基盤としています。同時に、BroadcomもTCPチムニーオフロードチップの製造ライセンスを取得しました。

種類

TCPスタックをTOEに完全に置き換える代わりに、オペレーティングシステムのTCPスタックと連携して一部の操作をオフロードする代替技術があります。TCPチェックサムオフロードとラージセグメントオフロードは、今日のイーサネットNICの大部分でサポートされています。ラージレシーブオフロードやTCP確認応答オフロードなどの新しい技術は、一部のハイエンドイーサネットハードウェアに既に実装されていますが、純粋にソフトウェアで実装した場合でも効果的です。[ 6 ] [ 7 ]

並列スタックフルオフロード

パラレルスタック・フルオフロードは、2つの並列TCP/IPスタックという概念に由来しています。1つ目は、ホストOSに含まれるメインホストスタックです。2つ目は「パラレルスタック」と呼ばれ、アプリケーション層とトランスポート層（TCP）の間に「ヴァンパイアタップ」を介して接続されます。ヴァンパイアタップは、アプリケーションからのTCP接続要求を傍受し、TCP接続管理とTCPデータ転送を担います。以下のセクションで取り上げる批判の多​​くは、このタイプのTCPオフロードに関連しています。

HBAフルオフロード

HBA（ホストバスアダプタ）フルオフロードは、iSCSIホストアダプタに搭載されています。iSCSIホストアダプタは、TCP/IP経由でiSCSIストレージデバイスに接続する際に、ホストシステムに対してディスクコントローラとして機能します。このタイプのTCPオフロードは、TCP/IP処理だけでなく、iSCSIイニシエーター機能もオフロードします。HBAはホストに対してディスクコントローラとして認識されるため、iSCSIデバイスでのみ使用可能であり、一般的なTCP/IPオフロードには適していません。

TCP チムニー部分オフロード

TCP チムニー オフロードは、パラレルスタック フル オフロードに対する主要なセキュリティ上の批判に対処します。部分オフロードでは、メイン システム スタックがホストへのすべての接続を制御します。ローカル ホスト (通常はサーバー) と外部ホスト (通常はクライアント) の間で接続が確立されると、接続とその状態が TCP オフロード エンジンに渡されます。データの送受信という負荷の高い処理は、オフロード デバイスによって処理されます。ほぼすべての TCP オフロード エンジンは、何らかのタイプの TCP/IP ハードウェア実装を使用して、ホスト CPU の介入なしにデータ転送を実行します。接続が閉じられると、接続状態がオフロード エンジンからメイン システム スタックに返されます。TCP 接続の制御を維持することで、メイン システム スタックは接続セキュリティを実装および制御できます。

TCPセグメンテーションオフロード

TCPセグメンテーションオフロード（TSO）はTCPセグメントタスクをネットワークインターフェースコントローラにオフロードすることができる。[ 8 ]

大規模受信オフロード

ラージレシーブオフロード（LRO）は、中央処理装置（CPU）のオーバーヘッドを削減することで、高帯域幅ネットワーク接続の受信スループットを向上させる技術です。LROは、単一のストリームから複数の受信パケットをより大きなバッファに集約してから、ネットワークスタックの上位に渡すことで、処理すべきパケット数を削減します。Linux実装では、割り込み数を削減するために、 LROをNew API （NAPI）と組み合わせて使用​​することが一般的です。

ベンチマークによると、この技術を完全にソフトウェアで実装するだけでも、ネットワーク性能を大幅に向上させることができる。[ 6 ] [ 7 ] [ 9 ] 2007年4月現在、LinuxカーネルはTCPのLROをソフトウェアのみでサポートしている。FreeBSD 8は、LROをサポートするアダプタ上でハードウェアでLROをサポートしている。[ 10 ] [ 11 ] [ 12 ] [ 13 ]

LROはエンドツーエンドの原則に反し、パフォーマンスに大きな影響を与える可能性があるため、ルータとして機能するマシンでは動作しないはずです。[ 14 ] [ 15 ]

汎用受信オフロード

汎用受信オフロード（GRO ）は、TCP/ IPv4に制限されず、LROによって生じる問題も抱えないソフトウェアで汎用LROを実装します。 [ 16 ] [ 17 ]

大規模送信オフロード

コンピュータネットワークにおいて、Large Send Offload（LSO ）は、 CPUオーバーヘッドを削減することで高帯域幅ネットワーク接続の出力スループットを向上させる技術です。この技術は、マルチパケットバッファをネットワークインターフェースカード（NIC）に渡すことで機能します。NICはこのバッファを個別のパケットに分割します。この技術は、 TCPセグメンテーションオフロード（TSO）またはTCPに適用される場合、汎用セグメンテーションオフロード（GSO ）とも呼ばれます。LSOとLROは独立しており、一方を使用しても他方を使用する必要はありません。

システムがコンピュータネットワーク経由で大量のデータチャンクを送信する必要がある場合、まずチャンクを小さなセグメントに分割する必要があります。これらのセグメントは、送信元コンピュータと宛先コンピュータ間のルーターやスイッチなどのネットワーク要素を通過できます。このプロセスはセグメンテーションと呼ばれます。多くの場合、ホストコンピュータのTCPプロトコルがこのセグメンテーションを実行します。この処理をNICにオフロードすることをTCPセグメンテーションオフロード（TSO）と呼びます。

例えば、64 KiB（65,536バイト）のデータは通常、NICを経由してネットワーク経由で送信される前に、1,460バイトずつ45個のセグメントに分割されます。NICに何らかのインテリジェンスがあれば、ホストCPUは64 KBのデータを1回の送信要求でNICに渡すことができ、NICはそのデータを1,460バイトずつの小さなセグメントに分割し、ホストのTCP/IPスタックによって提供されるテンプレートに従って、TCP、IP、およびデータリンク層プロトコルヘッダーを各セグメントに追加し、結果として得られたフレームをネットワーク経由で送信できます。これにより、CPUの負荷が大幅に軽減されます。2014年現在、市場に出回っている多くの新しいNICがTSOをサポートしています。

一部のネットワーク カードは TSO を汎用的に実装しているため、他のトランスポート層プロトコルのフラグメンテーションをオフロードしたり、UDPなど、フラグメンテーションを単独でサポートしないプロトコルのIP フラグメンテーションを実行したりするために使用できます。

UDPフラグメンテーションオフロード

UDPフラグメンテーションオフロード（UFO）は、UDPデータグラムのタスクをネットワークインターフェースコントローラにオフロードすることができます。[ 18 ]

Linuxでのサポート

FreeBSDなどの他のオペレーティングシステムとは異なり、LinuxカーネルにはTOE（他の種類のネットワークオフロードと混同しないでください）のサポートは含まれていません。[ 19 ] ChelsioやQlogicなどのハードウェアメーカーからはTOEサポートを追加するパッチが提供されていますが、Linuxカーネル開発者はいくつかの理由からこの技術に反対しています。[ 20 ]

  • セキュリティ– TOEはハードウェアに実装されているため、特定のTOE実装で発見されたセキュリティ脆弱性に対処するには、ソフトウェアだけでなくTOEファームウェアにもパッチを適用する必要があります。これは、TOEを使用しないオペレーティングシステムに搭載されているような十分にテストされたTCP/IPスタックと比較して、このハードウェアが新しく、ベンダー固有のものであるという点で、さらに複雑です。
  • ハードウェアの制限– 接続は TOE チップ上でバッファリングされ、処理されるため、オペレーティング システムで使用できる十分な CPU とメモリと比較して、リソース不足が発生しやすくなります。
  • 複雑さ– TOEは、カーネルが常にすべてのリソースにアクセスできるという前提を覆します。つまり、オープン接続で使用されるメモリなどの詳細情報はTOEでは取得できません。また、TOEを適切にサポートするには、ネットワークスタックに非常に大きな変更が必要であり、たとえ変更が行われたとしても、サービス品質（QoS）やパケットフィルタリングなどの機能が動作しない可能性があります。
  • 独自仕様– TOEはハードウェアベンダーごとに実装が異なります。つまり、様々なTOE実装に対応するために、より多くのコードを書き直す必要があり、前述の複雑さと、場合によってはセキュリティの低下を招きます。さらに、TOEファームウェアはクローズドソースであるため、簡単に変更することはできません。
  • 陳腐化– システム ハードウェアは急速に TOE のパフォーマンス レベルに追いつき、最終的には TOE のパフォーマンス レベルを超えるため、各 TOE NIC の有効期間には限りがあります。

サプライヤー

TOE テクノロジに関する現在の取り組みの多くは、Broadcom、Chelsio Communications、Emulex、Mellanox Technologies、QLogicなどの 10 ギガビット イーサネット インターフェイス カードのメーカーによって行われています。

参照

参考文献

  1. ^ Jeffrey C. Mogul (2003-05-18). TCPオフロードは時代遅れの愚かなアイデアだ. HotOS. Usenix .
  2. ^ a b Annie P. Foong; Thomas R. Huff; Herbert H. Hum; Jaidev P. Patwardhan; Greg J. Regnier (2003-04-02). TCPパフォーマンスの再考(PDF) . Proceedings of the International Symposium on Performance Analysis of Systems and Software (ISPASS). Austin, Texas.
  3. ^米国特許: 5355453 「並列I/Oネットワークファイルサーバーアーキテクチャカテゴリ」
  4. ^米国特許: 6247060 「デバイス上でメッセージが処理されるように、ホストからローカルデバイスに通信ブロックを渡す」
  5. ^「新参者がストレージネットワークシリコンを開発」リック・メリット、2002年10月21日、EE Times
  6. ^ a b Jonathan Corbet (2007年8月1日). 「Large receive offload」 . LWN.net . 2007年8月22日閲覧。
  7. ^ a b Aravind Menon、Willy Zwaenepoel (2008-04-28). TCP受信パフォーマンスの最適化. USENIX年次技術会議. USENIX.
  8. ^ https://docs.kernel.org/networking/segmentation-offloads.html
  9. ^ Andrew Gallatin (2007-07-25). 「lro: TCPトラフィックの汎用大規模受信オフロード」 . linux-kernel (メーリングリスト) . 2007年8月22日閲覧。
  10. ^ "Cxgb" . Freebsd.org . 2018年7月12日閲覧。
  11. ^ "Mxge" . Freebsd.org . 2018年7月12日閲覧。
  12. ^ "Nxge" . Freebsd.org . 2018年7月12日閲覧。
  13. ^ 「LROが有効になっているLinux仮想マシンではTCPパフォーマンスが低下する可能性がある」 VMware 2011年7月4日2011年8月17日閲覧。
  14. ^ 「Linux* ベースドライバー：Intel(R) Ethernet 10 Gigabit PCI Express ファミリーアダプター用」 Intel Corporation 2013年2月12日。2019年11月24日時点のオリジナルよりアーカイブ。 2013年4月24日閲覧。{{cite web}}: CS1 maint: bot: 元のURLステータス不明（リンク）
  15. ^ 「LROが有効になっているすべてのNICでLROを無効にする」 Red Hat, Inc. 2013年1月10日. 2013年4月24日閲覧。
  16. ^ 「JLS2009: 汎用受信オフロード」 . lwn.net .
  17. ^ Huang, Shu; Baldine, Ilia (2012年3月). Schmitt, Jens B. (編). SR-IOV対応10GE NICのパフォーマンス評価：I/O仮想化とネットワークスタックの最適化. コンピューティングシステムと信頼性および耐障害性の測定、モデリング、評価：第16回国際GI/ITG会議、MMB & DFT 2012. Lecture Notes in Computer Science. Vol. 7201. カイザースラウテルン、ドイツ：Springer (2012年出版). p. 198. ISBN 97836422854002016年10月11日閲覧。Large -Receive-Offload（LRO）は、小さなパケットを大きなパケットに集約し、ネットワークスタックに渡すことで、パケットごとの処理オーバーヘッドを削減します。Generic-Receive-Offload（GRO）は、LROの汎用ソフトウェアバージョンを提供します [...]。
  18. ^ https://docs.kernel.org/networking/segmentation-offloads.html
  19. ^「Linux と TCP オフロード エンジン」、2005 年 8 月 22 日、LWN.net
  20. ^ネットワーク:TOE、Linux Foundation。
「 https://en.wikipedia.org/w/index.php?title=TCP_offload_engine&oldid=1332891114#Large_send_offload」から取得