10GbE時代のネットワークI/O高速化

32,835 views
32,129 views

Published on

10GbE、40GbEなどの極めて高速な通信をサポートするNICが、PCサーバの領域でも使われるようになってきている。
このような速度の通信をソフトウェア(OS)で処理し高い性能を得るには様々な障害があり、ハードウェア・ソフトウェア両面の実装を見直す必要がある。

本セッションでは、ハードウェア・ソフトウェア両面にどのような改良が行われてきており、性能を引き出すにはどのようにこれらを使用したらよいのかについて紹介する。

Published in: Technology
0 Comments
141 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
32,835
On SlideShare
0
From Embeds
0
Number of Embeds
2,866
Actions
Shares
0
Downloads
309
Comments
0
Likes
141
Embeds 0
No embeds

No notes for slide

10GbE時代のネットワークI/O高速化

  1. 1. 10GbE時代のネットワークI/O高速化Takuya ASADA<syuu@freebsd.org>13年6月7日金曜日
  2. 2. はじめに• 10GbE、40GbEなどの極めて高速な通信をサポートするNICが、PCサーバの領域でも使われるようになってきている• このような速度の通信をソフトウェア(OS)で処理し高い性能を得るには様々な障害があり、ハードウェア・ソフトウェア両面の実装を見直す必要がある13年6月7日金曜日
  3. 3. 今日のトピック1. 割り込みが多すぎる2. プロトコル処理が重い3. 複数のCPUでパケット処理したい4. データ移動に伴うレイテンシの削減5. プロトコルスタックを経由しないネットワークIO13年6月7日金曜日
  4. 4. 1. 割り込みが多すぎるProcess(User)Process(Kernel)HW Intr HandlerSW Intr Handlerパケット受信プロトコル処理ソケット受信処理ユーザプログラムuserbufferinputqueuesocketqueueパケットシステムコールプロセス起床ソフトウェア割り込みスケジュールハードウェア割り込みユーザ空間へコピー13年6月7日金曜日
  5. 5. 割り込みが多すぎる• NICの性能向上によって、一定時間にNICが処理できるパケット数が飛躍的に増加• 1パケット毎に割り込みが来ると、通信量が多いときにコンテキストスイッチ回数が増えすぎ性能が劣化13年6月7日金曜日
  6. 6. 旧来のパケット受信処理Process(User)Process(Kernel)HW Intr HandlerSW Intr Handlerパケット受信プロトコル処理ソケット受信処理ユーザプログラムuserbufferinputqueuesocketqueueパケットシステムコールプロセス起床ソフトウェア割り込みスケジュールハードウェア割り込みユーザ空間へコピーハードウェア割り込み↓受信キューにキューイング↓ソフトウェア割り込みスケジュール13年6月7日金曜日
  7. 7. 旧来のパケット受信処理• 1パケット受信するたびに割り込みを受けて処理を行っている• 64byte frameの最大受信可能数:• GbE:約1.5Mpps(150万)• 10GbE:約15Mpps(1500万)13年6月7日金曜日
  8. 8. 割り込みを無効にする?• ポーリング方式• NICの割り込みを禁止し、代わりにクロック割り込みを用いて定期的に受信キューをチェック• デメリット:レイテンシが上がる・定期的にCPUを起こす必要がある• ハイブリッド方式• 通信量が多く連続してパケット処理を行っている時のみ割り込みを無効化してポーリングで動作13年6月7日金曜日
  9. 9. NAPI(ハイブリッド方式)Process(User)Process(Kernel)HW Intr HandlerSW Intr Handler割り込み無効化プロトコル処理ソケット受信処理ユーザプログラムuserbuffersocketqueueパケットシステムコールプロセス起床ハードウェア割り込みユーザ空間へコピーパケットパケットソフトウェア割り込みスケジュールパケット受信パケットが無くなるまで繰り返しハードウェア割り込み↓割り込み無効化&ポーリング開始↓パケットが無くなったら割り込み有効化13年6月7日金曜日
  10. 10. Interrupt Coalescing• NICがOS負荷を考慮して割り込みを間引く• パケット数個に一回割り込む、或いは一定期間待ってから割り込む• デメリット:レイテンシが上がる13年6月7日金曜日
  11. 11. Interrupt Coalescingの効果• Intel 82599(ixgbe)でInterrupt Coalescing無効、有効(割り込み頻度自動調整)で比較• MultiQueue, GRO, LRO等は無効化• iperfのTCPモードで計測interrupts throughput packets CPU%(sy+si)無効有効46687 int/s 7.82 Gbps 660386 pkt/s 97.6%7994 int/s 8.24 Gbps 711132 pkt/s 79.6%13年6月7日金曜日
  12. 12. Process(User)Process(Kernel)HW Intr HandlerSW Intr Handler割り込み無効化プロトコル処理ソケット受信処理ユーザプログラムuserbuffersocketqueueパケットシステムコールプロセス起床ハードウェア割り込みユーザ空間へコピーパケットパケットソフトウェア割り込みスケジュールパケット受信パケットが無くなるまで繰り返し2.プロトコル処理が重い13年6月7日金曜日
  13. 13. プロトコル処理が重い• 特に小さなパケットが大量に届く場合にプロトコル処理でCPU時間を大量に使ってしまう• パケット数分プロトコルスタックが呼び出される例:64byte frameの場合→理論上の最大値は1500万回/s13年6月7日金曜日
  14. 14. TOE(TCP Offload Engine)• OSでプロトコル処理するのをやめて、NICで処理する• デメリット• セキュリティ:TOEにセキュリティホールが生じても、OS側から対処が出来ない• 複雑性:OSのネットワークスタックをTOEで置き換えるにはかなり広範囲の変更が必要メーカによってTOEの実装が異なり共通インタフェース定義が困難• Linux:サポート予定無し13年6月7日金曜日
  15. 15. Checksum Offloading• IP・TCP・UDP checksumの計算をNICで行う13年6月7日金曜日
  16. 16. Checksum Offloadingの効果• Intel 82599(ixgbe)で比較• iperfのTCPモードで計測• MultiQueueは無効化• ethtool -K ix0 rx offthroughput CPU%(sy+si)無効有効8.27 Gbps 868.27 Gbps 85.213年6月7日金曜日
  17. 17. LRO(Large Receive Offload)• NICが受信したTCPパケットを結合し、大きなパケットにしてからOSへ渡す• プロトコルスタックの呼び出し回数を削減• LinuxではソフトウェアによるLROが実装されている(GRO)13年6月7日金曜日
  18. 18. LROが無い場合• パケット毎にネットワークスタックを実行seq 10000 seq 10001 seq 10002 seq 10003←1500bytes→To network stack13年6月7日金曜日
  19. 19. LROが有る場合• パケットを結合してからネットワークスタックを実行、ネットワークスタックの実行回数を削減seq 10000 seq 10001 seq 10002 seq 10003←1500bytes→To network stackbig one packet13年6月7日金曜日
  20. 20. GROの効果• Intel 82599(ixgbe)で比較• MultiQueueは無効化• iperfのTCPモードで計測• ethtool -K ix0 gro offpacketsnetwork stackcalled count throughput CPU%(sy+si)無効有効632139 pkt/s 632139 call/s 7.30 Gbps 97.6%712387 pkt/s 47957 call/s 8.25 Gbps 79.6%13年6月7日金曜日
  21. 21. TSO(TCP Segmentation Offload)• LROの逆• パケットをフラグメント化せずに送信NICがパケットをMTUサイズに分割• OSはパケット分割処理を省略出来る• LinuxではソフトウェアによるGSO、ハードウェアによるTSO/UFOをサポート13年6月7日金曜日
  22. 22. TSOの効果• Intel 82599(ixgbe)で比較• MultiQueueは無効化• iperfのTCPモードで計測• ethtool -K ix0 gso off tso offpackets throughput CPU%(sy+si)無効有効247794 pkt/s 2.87 Gbps 53.5%713127 pkt/s 8.16 Gbps 26.8%13年6月7日金曜日
  23. 23. 3.複数のCPUでパケット処理したいcpu0Process(User)Process(Kernel)HW Intr HandlerSW Intr Handler割り込み無効化プロトコル処理ソケット受信処理ユーザプログラムuserbuffersocketqueueパケットシステムコールプロセス起床ハードウェア割り込みユーザ空間へコピーパケットパケットソフトウェア割り込みスケジュールパケット受信パケットが無くなるまで繰り返しcpu1Process(User)Process(Kernel)HW Intr HandlerSW Intr Handler割り込み無効化プロトコル処理ソケット受信処理ユーザプログラムuserbuffersocketqueueパケットシステムコールプロセス起床ハードウェア割り込みユーザ空間へコピーパケットパケットソフトウェア割り込みスケジュールパケット受信パケットが無くなるまで繰り返し13年6月7日金曜日
  24. 24. ソフト割り込みが1つのコアに偏る13年6月7日金曜日
  25. 25. ソフト割り込みとは?Process(User)Process(Kernel)HW Intr HandlerSW Intr Handler割り込み無効化プロトコル処理ソケット受信処理ユーザプログラムuserbuffersocketqueueパケットシステムコールプロセス起床ハードウェア割り込みユーザ空間へコピーパケットパケットソフトウェア割り込みスケジュールパケット受信パケットが無くなるまで繰り返しポーリングからプロトコル処理まで→ネットワークIOの大半部分13年6月7日金曜日
  26. 26. 何故偏る?ソフト割り込みはNICの割り込みがかかったCPUへスケジュールされる↓ポーリングからプロトコルスタックの実行までソフト割り込み内で実行される↓NICの割り込みがかかっているCPUだけに負荷がかかる13年6月7日金曜日
  27. 27. ソフト割り込みが1つのコアに偏って性能が出ない• memcachedなどショートパケットを大量に捌くワークロードで顕在化• ソフトウェア割り込みを実行しているCPUがボトルネックになり、性能がスケールしなくなる13年6月7日金曜日
  28. 28. 解決方法• パケットを複数のCPUへ分散させてからプロトコル処理する仕組みがあれば良い• 但し、TCPには順序保証が有るので並列に処理されるとパケットの並べ直し(リオーダ)が発生してパフォーマンスが落ちる13年6月7日金曜日
  29. 29. TCP Reordering• シーケンスナンバー通りの順序でパケットが着信していれば順にバッファへコピーしていくだけでよいが…1 2 3 4 5 61 2 3 4 5 6protocolprocessinguser buffer13年6月7日金曜日
  30. 30. TCP Reordering1 2 4 5 3 61 2 3 4 5 6protocolprocessinguser bufferreorderqueue3 4 5• 順序が乱れているとパケットの並べ直し(リオーダ)作業が必要になる13年6月7日金曜日
  31. 31. 解決方法(続)• 1つのフローは1つのCPUで処理される方が都合が良い13年6月7日金曜日
  32. 32. RSS(Receive Side Scaling)• CPUごとに別々の受信キューを持つNIC(MultiQueue NICと呼ばれる)• 受信キューごとに独立した割り込みを持つ• 同じフローに属するパケットは同じキューへ、異なるフローに属するパケットはなるべく別のキューへ分散→パケットヘッダのハッシュ値を計算する事により宛先キューを決定13年6月7日金曜日
  33. 33. MSI-X割り込み• PCI Expressでサポート• デバイスあたり2048個のIRQを持てる• それぞれのIRQの割り込み先CPUを選べる→1つのNICがCPUコア数分のIRQを持てる13年6月7日金曜日
  34. 34. RSSによるパケット振り分けNICパケットパケットパケットハッシュ計算パケット着信hash queueディスパッチ参照RXQueue#0RXQueue#1RXQueue#2RXQueue#3cpu0 cpu1 cpu2 cpu3受信処理割り込み受信処理■■0113年6月7日金曜日
  35. 35. キュー選択の手順indirection_table[64] = initial_valueinput[12] ={src_addr, dst_addr, src_port, dst_port}key = toeplitz_hash(input, 12)index = key & 0x3fqueue = indirection_table[index]13年6月7日金曜日
  36. 36. RSS導入前13年6月7日金曜日
  37. 37. RSS導入後13年6月7日金曜日
  38. 38. RPS• RSS非対応のオンボードNICをうまくつかってサーバの性能を向上させたい• ソフトでRSSを実装してしまおう• ソフト割り込みの段階でパケットを各CPUへばらまく• CPU間割り込みを使って他のCPUを稼動させる• RSSのソフトウエアによるエミュレーション13年6月7日金曜日
  39. 39. cpu3cpu2cpu1cpu0割り込み無効化プロトコル処理ソケット受信処理ユーザプログラムuserbuffersocketqueueパケットシステムコールプロセス起床ハードウェア割り込みユーザ空間へコピーパケットパケットソフトウェア割り込みパケット受信ハッシュ計算ディスパッチプロトコル処理ソケット受信処理ユーザプログラムuserbuffersocketqueuebacklog#1hash queue参照■■01CPU間割り込みbacklog#2backlog#313年6月7日金曜日
  40. 40. RPSの使い方# echo "f" > /sys/class/net/eth0/queues/rx-0/rps_cpus# echo 4096 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt13年6月7日金曜日
  41. 41. RPS導入前13年6月7日金曜日
  42. 42. RPS導入後13年6月7日金曜日
  43. 43. RPS netperf resultnetperf benchmark result on lwn.net:e1000e on 8 core Intel   Without RPS: 90K tps at 33% CPU   With RPS:    239K tps at 60% CPUforedeth on 16 core AMD   Without RPS: 103K tps at 15% CPU   With RPS:    285K tps at 49% CPU13年6月7日金曜日
  44. 44. RFS• プロセス追跡機能をRPSに追加13年6月7日金曜日
  45. 45. RFSフローに割り当てられたキューが宛先プロセスのCPUと異なるとオーバヘッドが発生する13年6月7日金曜日
  46. 46. RFSハッシュテーブルの設定値を変更する事でCPUを一致させる事ができる13年6月7日金曜日
  47. 47. RFSの使い方# echo "f" > /sys/class/net/eth0/queues/rx-0/rps_cpus# echo 4096 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt# echo 32768 > /proc/sys/net/core/rps_sock_flow_entries13年6月7日金曜日
  48. 48. RFS netperf resultnetperf benchmark result on lwn.net:e1000e on 8 core Intel   No RFS or RPS          104K tps at 30% CPU   No RFS (best RPS config):    290K tps at 63% CPU   RFS                    303K tps at 61% CPURPC test          tps     CPU%     50/90/99% usec latency     StdDev   No RFS or RPS     103K     48%     757/900/3185          4472.35   RPS only:          174K     73%     415/993/2468          491.66   RFS               223K     73%     379/651/1382          315.6113年6月7日金曜日
  49. 49. Accelerated RFS• RFSをMultiQueue NICでも実現するためのNICドライバ拡張• Linux kernelはプロセスの実行中CPUをNICドライバに通知• NICドライバは通知を受けてフローのキュー割り当てを更新13年6月7日金曜日
  50. 50. Receive Side Scalingの制限• 32bitのハッシュ値をそのまま使用していればハッシュ衝突しにくいが、Indirection Tableが小さいので少ないビット数でindex値をマスクしている→フローが多い時にハッシュ衝突する• Accelerated RFSには不向き13年6月7日金曜日
  51. 51. Flow Steering• フローとキューの対応情報を記憶4tuple:キュー番号のような形式で設定• RSSのような明確な共通仕様は無いが、各社の10GbEに実装されている• Accelerated RFSはFlow Steeringを前提としている13年6月7日金曜日
  52. 52. Flow Steeringで手動フィルタ設定# ethtool --config-nfc ix00 flow-type tcp4src-ip 10.0.0.1 dst-ip 10.0.0.2 src-port 10000dst-port 10001 action 6Added rule with ID 204513年6月7日金曜日
  53. 53. XPS• MultiQueue NICは送信キューも複数持っている• XPSはCPUと送信キューの割り当てを決めるインタフェース13年6月7日金曜日
  54. 54. XPSの使い方# echo 1 > /sys/class/net/eth0/queues/tx-0/xps_cpus# echo 2 > /sys/class/net/eth0/queues/tx-1/xps_cpus# echo 4 > /sys/class/net/eth0/queues/tx-2/xps_cpus# echo 8 > /sys/class/net/eth0/queues/tx-3/xps_cpus13年6月7日金曜日
  55. 55. 4.データ移動に伴うレイテンシの削減13年6月7日金曜日
  56. 56. データ移動に伴うレイテンシの削減• プロトコル処理よりもむしろNIC メモリ CPUキャッシュの間でのデータ移動に伴うオーバヘッドの方が重いケースがある• 特にメモリアクセスが低速13年6月7日金曜日
  57. 57. Intel Data Direct I/OTechnology• NICがDMAしたパケットのデータは、最初にCPUがアクセスした時に必ずキャッシュヒットミスを起こす         ↓• CPUのLLC(三次キャッシュ)にDMAしてしまえ!• 新しいXeonとIntel 10GbEでサポート• OS対応は不要(HWが透過的に提供する機能)13年6月7日金曜日
  58. 58. コピーが重いProcess(User)Process(Kernel)HW Intr HandlerSW Intr Handlerパケット受信プロトコル処理ソケット受信処理ユーザプログラムuserbufferinputqueuesocketqueueパケットシステムコールプロセス起床ソフトウェア割り込みスケジュールハードウェア割り込みユーザ空間へコピー13年6月7日金曜日
  59. 59. コピーが重いがゼロコピー化は困難• NICのDMAバッファはキュー毎に設定できるがフロー毎ではない→そもそもキューを一つのアプリで専有出来る前提でないと無理• バッファがページサイズにアライン・アロケートされてないと無理• パケットヘッダとペイロードが分離されてないとバッファにパケットヘッダまで書かれてしまう13年6月7日金曜日
  60. 60. • (Intel I/O ATとも呼ばれる)• NICのバッファ→アプリケーションのバッファへDMA転送• CPU負荷を削減• チップセットに実装• CONFIG_NET_DMA=y in LinuxIntel QuickData Technology13年6月7日金曜日
  61. 61. 5.プロトコルスタックを経由しないネットワークIO13年6月7日金曜日
  62. 62. プロトコルスタックを経由しないネットワークIO• プロトコル処理をする必要もSocket APIである必要も無いなら、ネットワークIOはもっと速く出来る• 特定用途向け• プロトコル処理を必要としないアプリケーション→snort、OpenvSwitchなど• プロトコル処理を自前で行なってでも性能を上げたいアプリケーション13年6月7日金曜日
  63. 63. 基本的な仕組み• 専用NICドライバと専用ライブラリを用いて、NICの受信バッファをMMAP• パケットをポーリング• アプリ固有のパケットに対する処理を実行NICRX1 RX2 RX3Kernel DriverAppRX1 RX2 RX3MMAPPacketsPollingDo somework13年6月7日金曜日
  64. 64. RAWソケット・BPFとの違い?• ゼロコピーが基本• マルチキューの受信バッファをそのままユーザランドにエクスポートしている• ↑により、マルチスレッド性能が高い(RAWソケット・BPFはシングルスレッド)• 上述の機能を実現するためNICのドライバを改造13年6月7日金曜日
  65. 65. Intel DPDK• 割り込みをやめてポーリングを使用しオーバヘッド削減• 受信バッファにHugePageを使う事によりTLB missを低減• 64 byte packetのL3フォワーディング性能(Intel資料より)• Linux network stack:Xeon E5645 x 2 → 12.2Mpps• DPDK:Xeon E5645 x 1 → 35.2Mpps• DPDK : Next generation Intel Processor x 1 → 80Mpps• OpenvSwitch対応• 対応NIC:Intel13年6月7日金曜日
  66. 66. 類似の実装• PF_RING DNAntopの実装、Linux向けlibpcapサポート対応NIC:Intel• NetmapFreeBSD向けの実装、一応Linux版ありlibpcap, OpenvSwitchサポート対応NIC:Intel, Realtek...13年6月7日金曜日
  67. 67. まとめ• 高速なネットワークIOを捌くために様々な改善が行われている事を紹介• ハードウェア・ソフトウェアの両面で実装の見直しが要求されており、その範囲はネットワークに直接関係ないような所にまで及ぶ• 取り敢えず明日から出来ること:まずはサーバに取り付けるNICを「マルチキューNIC」「RSS対応」にしよう13年6月7日金曜日

×