IO Linux Vyatta PC

(1)

イマドキな

ネットワーク

IO

[email protected]

(2)

はじめに

• ネットワークの高速化に伴って

ハード・ソフト両面でネットワークIOの実装が繰り返し見直されてきている

• ^これが^Linuxカーネルの実装にも大きく影響し

ている

• 厳密にはルータではなくサーバの話だが

Vyattaで用いられるPCルータにも大きく関係

(3)

旧来のパケット受信処理

Process(User)

Process(Kernel)

HW Intr Handler SW Intr Handler

パケット受信プロトコル処理

ソケット受信処理

ユーザプログラム

user buﬀer

input queue socket queue

パケット

システムコール

プロセス起床

ソフトウェア割り込みスケジュール

ハードウェア割り込みユーザ空間へコピー

(4)

ハードウェアの進化

• ^NIC^{性能の急激な向上}

• NIC:1GbE→10GbE

• CPU:1GHz→3.2GHz・メモリ:CPUの1/10のペース

• ^{マルチコア}^CPU^の普及

• ^1CPU^{コアの性能を上げる}^→^{コア数を増やしていく}

• ソフト・ハードの設計をマルチコア環境で性能が出るように変えていく必要が出てきた

(5)

割り込みが多すぎる

• ^NICの性能向上によって、一定時間に

NICが処理できるパケット数が飛躍的に増加

• １パケット毎に割り込みが来ると、通信量が多いときにコンテキストスイッチ回数が増えすぎ性能が劣化

(6)

割り込みが多すぎる

Process(User)

Process(Kernel)

パケット受信プロトコル処理

ソケット受信処理

user buﬀer

input queue socket queue

パケット

プロセス起床

(7)

Interrupt Coalescing

• ^{ハードウェアでの対応}

• パケット数個に一回割り込む、

或いは一定期間待ってから割り込む

• ^{割り込みを間引く}

• デメリット：レイテンシが上がる

(8)

ソフトウェアでの対応

• ^{ポーリング}

• ^NICの割り込みを使わずに、タイマーを使って定期的にNICのレジスタをポーリング、パケットが有ったら受信処理

• ^{ハイブリット方式}

• 通信量が多く連続してパケット処理を行っている時のみ割り込みを無効化、ポーリングで動作

→NAPI（Linux）解説：http://tinyurl.com/LinuxNAPI

(9)

NAPI

Process(User)

Process(Kernel)

割り込み無効化

プロトコル処理ソケット受信処理

user buﬀer

socket queue

パケット

プロセス起床

パケットパケット

パケット受信

パケットが無くなるまで繰り返し

(10)

プロトコル処理が重い

• ^高速な^NICを用いる環境では、ホストCPUでパケットを一つづつ処理する作業が大きなオーバヘッドになっている

→CPUがボトルネック

• ^{例：全二重な}^1Gbps^{の通信を行うと、}

Pentium4 2.4GHzでCPU時間を80%消費

• ^CPUをプロトコル処理から開放したい

(11)

Process(User)

Process(Kernel)

user buﬀer

socket queue

パケット

プロセス起床

パケット受信

プロトコル処理が重い

(12)

(TCP Offload Engine)TOE

• ^NIC^{に実装された}^TCP/IPスタックへプロトコル処理をフルオフロード

• ^{デメリット}

• ^{セキュリティ：}^TOEにセキュリティホールが生じても、OS側から対処が出来ない

• ^複雑性：^OSのネットワークスタックをTOEで置き換えるにはかなり広範囲の変更が必要であり、更に

メーカによってTOEの実装が異なる

(13)

(TCP Offload Engine)TOE

• ^Linux^{：サポート予定無し}

• ^Windows^{：コネクションは}^OS^で管理

解説：http://bit.ly/offload

• ^{特定用途：}RDMA, iSCSI HBA

(14)

部分的なオフロード

• TCP Checksum Offload

TCPのチェックサム計算

• Large Segment Offload

大きなパケット（例：64KB）をまとめて渡すと、NICでMTUに合わせて分割送信する

• Large Receive Offload

LSOの逆で、NIC上でパケットを結合し大きなパケットにしてカーネルに渡してくれる

(15)

Linux

の対応状況

• TCP Checksum Offload

TCPのチェックサム計算

• Large Segment Offload

大きなパケット（例：64KB）をまとめて渡すと、NICでMTUに合わせて分割送信する

LSOの逆で、NIC上でパケットを結合し大きなパケットにしてカーネルに渡してくれる

対応

ソフトウェアで実装

(16)

マルチコアが活用出来ない

• マルチコア環境においても一つのNICの受信処理は一つのCPUでしか行えていない

• 通信量が多いときにパケット処理の負荷が特定のコアへ大きく偏り性能に悪影響を及ぼす

(17)

複数の

CPU

でパケット処理したい

cpu0

Process(User)

Process(Kernel)

user buﬀer

socket queue

パケット

プロセス起床

パケット受信

cpu1

Process(User)

Process(Kernel)

user buﬀer

socket queue

パケット

プロセス起床

パケット受信

(18)

Receive Side Scaling

• パケットヘッダのハッシュ値を元にパケットを複数の受信キューへ振り分け

• 受信キューはそれぞれのCPUコアに対応、

それぞれのCPUへ割り込む

• ^CPUごとに並列にパケット処理が行えるようになる

• ^{同一フローは一つの}^CPU^{へ振り分けられる}

→データローカリティを考慮

(19)

NIC

パケットパケットパケット

ハッシュ計算

パケット着信

hash queue

ディスパッチ参照 RX

Queue

#0

RX Queue

#1

RX Queue

#2

RX Queue

#3

cpu0 cpu1 cpu2 cpu3

受信処理割り込み

受信処理

■

0 1

(20)

• ^Microsoft^がScalable Network Initiativeで提唱解説：http://bit.ly/ReceiveSideScaling

• ^Windows^・^Linux^{でサポート}

• ハードウェア対応が必要

• ^PCI^バスの^MSI-X^サポート

• ^NIC^への^RSS^実装

(21)

RPS(Linux)

• ^RSS^{非対応のオンボード}^NIC^{をうまくつかってサー}

バの性能を向上させたい

• ^ソフトで^RSS^{を実装してしまおう}

• ソフト割り込みの段階でパケットを各CPUへばらまく

• ^CPU間割り込みを使って他のCPUを稼動させる

• ^RSSのソフトウエアによるエミュレーション

(22)

cpu3 cpu2

cpu1 cpu0

user buﬀer

socket queue

パケット

プロセス起床

ソフトウェア割り込み

パケット受信ハッシュ計算ディスパッチ

ユーザ

プログラム _user

buﬀer

socket queue

backlog

#1 hash queue

■ 参照

■ ⁰¹

CPU間割り込み

backlog

#2

backlog

#3

(23)

RFS(Linux)

• 受信待ちプロセスがいるCPUへパケットをディスパッチ出来る仕組みをRPSに追加

• データローカリティの向上、レイテンシの削減

(24)

RPS

のワーストケース

NIC

デフォルトCPUへ割り込み

CPU0 CPU1 CPU2 CPU3

割り込みハンドラ

ネットワークスタックプロセス起床

ポーリング

バッファ

プロセスB プロセス起床

(25)

プロセスがいる

CPU

へ転送

NIC

デフォルトCPUへ割り込み

CPU0 CPU1 CPU2 CPU3

割り込みハンドラ

プロセスA

ポーリング

バッファ

プロセスB

(26)

それでも遅い

• ^Intel^{の取り組み：}http://bit.ly/IOATJ

• ^{何故、高速な}^NIC^、^CPU^{・最適化された}^OS^{を使用している}

にも関わらずサーバのパフォーマンスは上がらないのか？

• 最も深刻なボトルネックはCPUにネットワークI/O処理を行わせていることが原因ではなく、データ移動に伴うオーバヘッドだった

• ^{メモリの速度は}^CPUよりはるかに低速であるため、メモリアクセス時のメモリ・フェッチにはかなりの時間がかる

(27)

TOE

は要らない子

• ^TOEではごく僅かな性能改善しか出来ず、レイテンシの根本的な問題を解決していない

• ^何故、^CPUより性能の低いオフロードエンジンが CPUよりも速いと考えられていたのか？

→TCP/IPのデータ操作に最適化されている為

• ^{最適化された}^TCP/IP^{スタックを}^CPU^{上に実装、}

性能測定を行いTOEより高速化される事を確認

→オンロード

(28)

Intel I/O Acceleration Technology

• Intel QuickData Technology

• Direct Cache Access

• Receive Side Scaling

• Low Latency Interrupts

＋最適化されたネットワークスタック

(29)

• ^NIC^{のバッファ}^→^{アプリケーションの}

バッファへパケットをDMA転送

• ^CPU^{負荷を削減}

• ^{チップセットに実装、}^OS^から利用

Intel QuickData Technology

(30)

Process(User)

Process(Kernel)

user buﬀer

socket queue

パケット

プロセス起床

パケット受信

Intel QuickData Technology

(31)

Direct Cache Access

• ^NIC^{からメモリへ}^DMA^{転送されたパケットを}

CPUからアクセスする時、キャッシュへ

フェッチする為にレイテンシが発生している

• ^NICからキャッシュへ直接転送したい

• ^{難しいので、必ず}^prefetch^{が掛かるように}

ハードの実装を変更、フェッチコストを隠蔽

(32)

DCA

無し

I/O Device Memory Controller

CPU

Cache

Memory

DMA Write

Snoop invalidate Writeback

Memory Wirte Fetch

(33)

DCA

有り

I/O Device Memory Controller

CPU

Cache

Memory

DMA Write

Snoop invalidate Writeback

Memory Wirte

HW Prefetch +hint

(34)

仮想化環境でも

パフォーマンスを出したい

• ^{Intel VT-c}

• ^SR-IOV

• ^{複数のゲスト}^OS^と^NIC^{を直接接続}

• ^VMDq

• ^VM^間の^IO^{スケジュール}

(35)

従来の仮想ハードウェア

VM1

Hypervisor

フロントエンドドライバ

VM2

フロントエンドドライバ

バックエンドドライバデバイスドライバ

デバイス

(36)

Intel VT-d

による

PCI Passthrough

VM1

Hypervisor

デバイスドライバ

VM2

デバイス

(37)

SR-IOV

VM1

Hypervisor

VFデバイスドライバ

VM2

PFデバイスドライバ

デバイス

仮想デバイス

(38)

VMDq

VM1

Hypervisor

VM2

PFデバイスドライバ

デバイス

仮想デバイス

仮想デバイス RX1

RX1 RX1

RX2 RX2

RX1 RX1 RX1 RX2

RX2

(39)

まとめ

• ソフトウェア・ハードウェア双方で最適化を進めないとならない

• ある時点で正しかった答えがずっと正しいとは限らない

• 一つの解決策だけで問題が解消するとは限らない

• ^Intel^{がんばるなぁ}