Download as PDF, PPTX
![キュー選択の手順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日金曜日](/image.pl?url=https%3a%2f%2fimage.slidesharecdn.com%2f10gbeio-130607024551-phpapp01%2f75%2f10GbE-I-O-35-2048.jpg&f=jpg&w=240)
Uploaded byTakuya ASADA
PDF, PPTX60,785 views
10GbE時代のネットワークI/O高速化
10GbE、40GbEなどの極めて高速な通信をサポートするNICが、PCサーバの領域でも使われるようになってきている。このような速度の通信をソフトウェア（OS）で処理し高い性能を得るには様々な障害があり、ハードウェア・ソフトウェア両面の実装を見直す必要がある。本セッションでは、ハードウェア・ソフトウェア両面にどのような改良が行われてきており、性能を引き出すにはどのようにこれらを使用したらよいのかについて紹介する。
More Related Content
What's hot
Similar to 10GbE時代のネットワークI/O高速化
![[kernel/vm] Implements the RPS/RFS for FreeBSD](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2fkernelvmgsoc-110522025039-phpapp02-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
More from Takuya ASADA
10GbE時代のネットワークI/O高速化
- 1.
- 2.
- 3.今日のトピック1. 割り込みが多すぎる2. プロトコル処理が重い3.複数のCPUでパケット処理したい4. データ移動に伴うレイテンシの削減5. プロトコルスタックを経由しないネットワークIO13年6月7日金曜日
- 4.1. 割り込みが多すぎるProcess(User)Process(Kernel)HW IntrHandlerSW Intr Handlerパケット受信プロトコル処理ソケット受信処理ユーザプログラムuserbufferinputqueuesocketqueueパケットシステムコールプロセス起床ソフトウェア割り込みスケジュールハードウェア割り込みユーザ空間へコピー13年6月7日金曜日
- 5.
- 6.旧来のパケット受信処理Process(User)Process(Kernel)HW Intr HandlerSWIntr Handlerパケット受信プロトコル処理ソケット受信処理ユーザプログラムuserbufferinputqueuesocketqueueパケットシステムコールプロセス起床ソフトウェア割り込みスケジュールハードウェア割り込みユーザ空間へコピーハードウェア割り込み↓受信キューにキューイング↓ソフトウェア割り込みスケジュール13年6月7日金曜日
- 7.旧来のパケット受信処理• １パケット受信するたびに割り込みを受けて処理を行っている• 64byteframeの最大受信可能数：• GbE：約1.5Mpps（150万）• 10GbE：約15Mpps（1500万）13年6月7日金曜日
- 8.割り込みを無効にする？• ポーリング方式• NICの割り込みを禁止し、代わりにクロック割り込みを用いて定期的に受信キューをチェック•デメリット：レイテンシが上がる・定期的にCPUを起こす必要がある• ハイブリッド方式• 通信量が多く連続してパケット処理を行っている時のみ割り込みを無効化してポーリングで動作13年6月7日金曜日
- 9.NAPI（ハイブリッド方式）Process(User)Process(Kernel)HW Intr HandlerSWIntr Handler割り込み無効化プロトコル処理ソケット受信処理ユーザプログラムuserbuffersocketqueueパケットシステムコールプロセス起床ハードウェア割り込みユーザ空間へコピーパケットパケットソフトウェア割り込みスケジュールパケット受信パケットが無くなるまで繰り返しハードウェア割り込み↓割り込み無効化＆ポーリング開始↓パケットが無くなったら割り込み有効化13年6月7日金曜日
- 10.Interrupt Coalescing• NICがOS負荷を考慮して割り込みを間引く•パケット数個に一回割り込む、或いは一定期間待ってから割り込む• デメリット：レイテンシが上がる13年6月7日金曜日
- 11.Interrupt Coalescingの効果• Intel82599(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.Process(User)Process(Kernel)HW Intr HandlerSWIntr Handler割り込み無効化プロトコル処理ソケット受信処理ユーザプログラムuserbuffersocketqueueパケットシステムコールプロセス起床ハードウェア割り込みユーザ空間へコピーパケットパケットソフトウェア割り込みスケジュールパケット受信パケットが無くなるまで繰り返し2.プロトコル処理が重い13年6月7日金曜日
- 13.プロトコル処理が重い• 特に小さなパケットが大量に届く場合にプロトコル処理でCPU時間を大量に使ってしまう• パケット数分プロトコルスタックが呼び出される例：64byteframeの場合→理論上の最大値は1500万回/s13年6月7日金曜日
- 14.TOE(TCP Offload Engine)•OSでプロトコル処理するのをやめて、NICで処理する• デメリット• セキュリティ：TOEにセキュリティホールが生じても、OS側から対処が出来ない• 複雑性：OSのネットワークスタックをTOEで置き換えるにはかなり広範囲の変更が必要メーカによってTOEの実装が異なり共通インタフェース定義が困難• Linux：サポート予定無し13年6月7日金曜日
- 15.Checksum Offloading• IP・TCP・UDPchecksumの計算をNICで行う13年6月7日金曜日
- 16.Checksum Offloadingの効果• Intel82599(ixgbe)で比較• iperfのTCPモードで計測• MultiQueueは無効化• ethtool -K ix0 rx offthroughput CPU%(sy+si)無効有効8.27 Gbps 868.27 Gbps 85.213年6月7日金曜日
- 17.LRO(Large Receive Offload)•NICが受信したTCPパケットを結合し、大きなパケットにしてからOSへ渡す• プロトコルスタックの呼び出し回数を削減• LinuxではソフトウェアによるLROが実装されている（GRO）13年6月7日金曜日
- 18.LROが無い場合• パケット毎にネットワークスタックを実行seq 10000seq 10001 seq 10002 seq 10003←1500bytes→To network stack13年6月7日金曜日
- 19.LROが有る場合• パケットを結合してからネットワークスタックを実行、ネットワークスタックの実行回数を削減seq 10000seq 10001 seq 10002 seq 10003←1500bytes→To network stackbig one packet13年6月7日金曜日
- 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.TSO(TCP Segmentation Offload)•LROの逆• パケットをフラグメント化せずに送信NICがパケットをMTUサイズに分割• OSはパケット分割処理を省略出来る• LinuxではソフトウェアによるGSO、ハードウェアによるTSO／UFOをサポート13年6月7日金曜日
- 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.3.複数のCPUでパケット処理したいcpu0Process(User)Process(Kernel)HW Intr HandlerSWIntr Handler割り込み無効化プロトコル処理ソケット受信処理ユーザプログラムuserbuffersocketqueueパケットシステムコールプロセス起床ハードウェア割り込みユーザ空間へコピーパケットパケットソフトウェア割り込みスケジュールパケット受信パケットが無くなるまで繰り返しcpu1Process(User)Process(Kernel)HW Intr HandlerSW Intr Handler割り込み無効化プロトコル処理ソケット受信処理ユーザプログラムuserbuffersocketqueueパケットシステムコールプロセス起床ハードウェア割り込みユーザ空間へコピーパケットパケットソフトウェア割り込みスケジュールパケット受信パケットが無くなるまで繰り返し13年6月7日金曜日
- 24.
- 25.ソフト割り込みとは？Process(User)Process(Kernel)HW Intr HandlerSWIntr Handler割り込み無効化プロトコル処理ソケット受信処理ユーザプログラムuserbuffersocketqueueパケットシステムコールプロセス起床ハードウェア割り込みユーザ空間へコピーパケットパケットソフトウェア割り込みスケジュールパケット受信パケットが無くなるまで繰り返しポーリングからプロトコル処理まで→ネットワークIOの大半部分13年6月7日金曜日
- 26.
- 27.
- 28.
- 29.TCP Reordering• シーケンスナンバー通りの順序でパケットが着信していれば順にバッファへコピーしていくだけでよいが…１2 3 4 5 6１ 2 3 4 5 6protocolprocessinguser buffer13年6月7日金曜日
- 30.TCP Reordering１ 24 5 3 6１ 2 3 4 5 6protocolprocessinguser bufferreorderqueue3 4 5• 順序が乱れているとパケットの並べ直し（リオーダ）作業が必要になる13年6月7日金曜日
- 31.
- 32.RSS（Receive Side Scaling）•CPUごとに別々の受信キューを持つNIC（MultiQueue NICと呼ばれる）• 受信キューごとに独立した割り込みを持つ• 同じフローに属するパケットは同じキューへ、異なるフローに属するパケットはなるべく別のキューへ分散→パケットヘッダのハッシュ値を計算する事により宛先キューを決定13年6月7日金曜日
- 33.MSI-X割り込み• PCI Expressでサポート•デバイスあたり2048個のIRQを持てる• それぞれのIRQの割り込み先CPUを選べる→1つのNICがCPUコア数分のIRQを持てる13年6月7日金曜日
- 34.RSSによるパケット振り分けNICパケットパケットパケットハッシュ計算パケット着信hash queueディスパッチ参照RXQueue#0RXQueue#1RXQueue#2RXQueue#3cpu0 cpu1cpu2 cpu3受信処理割り込み受信処理■■0113年6月7日金曜日
- 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.
- 37.
- 38.RPS• RSS非対応のオンボードNICをうまくつかってサーバの性能を向上させたい• ソフトでRSSを実装してしまおう•ソフト割り込みの段階でパケットを各CPUへばらまく• CPU間割り込みを使って他のCPUを稼動させる• RSSのソフトウエアによるエミュレーション13年6月7日金曜日
- 39.
- 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.
- 42.
- 43.RPS netperf resultnetperfbenchmark 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.
- 45.
- 46.
- 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.RFS netperf resultnetperfbenchmark 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.Accelerated RFS• RFSをMultiQueueNICでも実現するためのNICドライバ拡張• Linux kernelはプロセスの実行中CPUをNICドライバに通知• NICドライバは通知を受けてフローのキュー割り当てを更新13年6月7日金曜日
- 50.Receive Side Scalingの制限•32bitのハッシュ値をそのまま使用していればハッシュ衝突しにくいが、Indirection Tableが小さいので少ないビット数でindex値をマスクしている→フローが多い時にハッシュ衝突する• Accelerated RFSには不向き13年6月7日金曜日
- 51.Flow Steering• フローとキューの対応情報を記憶4tuple：キュー番号のような形式で設定•RSSのような明確な共通仕様は無いが、各社の10GbEに実装されている• Accelerated RFSはFlow Steeringを前提としている13年6月7日金曜日
- 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.XPS• MultiQueue NICは送信キューも複数持っている•XPSはCPUと送信キューの割り当てを決めるインタフェース13年6月7日金曜日
- 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.
- 56.データ移動に伴うレイテンシの削減• プロトコル処理よりもむしろNIC メモリCPUキャッシュの間でのデータ移動に伴うオーバヘッドの方が重いケースがある• 特にメモリアクセスが低速13年6月7日金曜日
- 57.Intel Data DirectI/OTechnology• NICがDMAしたパケットのデータは、最初にCPUがアクセスした時に必ずキャッシュヒットミスを起こす ↓• CPUのLLC（三次キャッシュ）にDMAしてしまえ！• 新しいXeonとIntel 10GbEでサポート• OS対応は不要（HWが透過的に提供する機能）13年6月7日金曜日
- 58.コピーが重いProcess(User)Process(Kernel)HW Intr HandlerSWIntr Handlerパケット受信プロトコル処理ソケット受信処理ユーザプログラムuserbufferinputqueuesocketqueueパケットシステムコールプロセス起床ソフトウェア割り込みスケジュールハードウェア割り込みユーザ空間へコピー13年6月7日金曜日
- 59.コピーが重いがゼロコピー化は困難• NICのDMAバッファはキュー毎に設定できるがフロー毎ではない→そもそもキューを一つのアプリで専有出来る前提でないと無理• バッファがページサイズにアライン・アロケートされてないと無理•パケットヘッダとペイロードが分離されてないとバッファにパケットヘッダまで書かれてしまう13年6月7日金曜日
- 60.• （Intel I/OATとも呼ばれる）• NICのバッファ→アプリケーションのバッファへDMA転送• CPU負荷を削減• チップセットに実装• CONFIG_NET_DMA=y in LinuxIntel QuickData Technology13年6月7日金曜日
- 61.
- 62.プロトコルスタックを経由しないネットワークIO• プロトコル処理をする必要もSocket APIである必要も無いなら、ネットワークIOはもっと速く出来る•特定用途向け• プロトコル処理を必要としないアプリケーション→snort、OpenvSwitchなど• プロトコル処理を自前で行なってでも性能を上げたいアプリケーション13年6月7日金曜日
- 63.基本的な仕組み• 専用NICドライバと専用ライブラリを用いて、NICの受信バッファをMMAP• パケットをポーリング•アプリ固有のパケットに対する処理を実行NICRX1 RX2 RX3Kernel DriverAppRX1 RX2 RX3MMAPPacketsPollingDo somework13年6月7日金曜日
- 64.RAWソケット・BPFとの違い？• ゼロコピーが基本• マルチキューの受信バッファをそのままユーザランドにエクスポートしている•↑により、マルチスレッド性能が高い（RAWソケット・BPFはシングルスレッド）• 上述の機能を実現するためNICのドライバを改造13年6月7日金曜日
- 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.類似の実装• PF_RING DNAntopの実装、Linux向けlibpcapサポート対応NIC：Intel•NetmapFreeBSD向けの実装、一応Linux版ありlibpcap, OpenvSwitchサポート対応NIC：Intel, Realtek...13年6月7日金曜日
- 67.まとめ• 高速なネットワークIOを捌くために様々な改善が行われている事を紹介• ハードウェア・ソフトウェアの両面で実装の見直しが要求されており、その範囲はネットワークに直接関係ないような所にまで及ぶ•取り敢えず明日から出来ること：まずはサーバに取り付けるNICを「マルチキューNIC」「RSS対応」にしよう13年6月7日金曜日