![キュー選択の手順
indirection_table[64] = initial_value
input[12] =
{src_addr, dst_addr, src_port, dst_port}
key = toeplitz_hash(input, 12)
index = key & 0x3f
queue = indirection_table[index]
13年6月7日金曜日](https://image.slidesharecdn.com/ethernetrx-140928015701-phpapp01/85/Ethernet-34-320.jpg)
![RPSでリモートCPUへキュー
（netif_receive_skb_internal）
cpu = get_rps_cpu(skb)
→ skb_flow_dissect(skb, &keys)
hash = __flow_hash_3words(keys.dst, keys.src, keys.ports)
map = rxqueue->rps_map
cpu = map->cpus[(hash * map->len) >> 32]
enqueue_to_backlog(skb, cpu)
→ sd = &per_cpu(softnet_data, cpu)
__skb_queue_tail(&sd->input_pkt_queue, skb)
rps_ipi_queued(sd)
&__get_cpu_var(softnet_data)->rps_ipi_list = sd
net_rx_action
napi->poll
process_backlog
net_rps_action_and_irq_enable
smp_call_function_single_async](https://image.slidesharecdn.com/ethernetrx-140928015701-phpapp01/85/Ethernet-40-320.jpg)
![システムコールコンテキストから
CPU番号をテーブルに保存
（inet_recvmsg）
sock_rps_record_flow(sk)
→ idx = sk->sk_rxhash &
rps_sock_flow_table->mask;
rps_sock_flow_table->ents[idx] =
raw_smp_processor_id()](https://image.slidesharecdn.com/ethernetrx-140928015701-phpapp01/85/Ethernet-51-320.jpg)
Ethernetの受信処理
- 2. rcu read lock receive_queue lock nf_hooks nf_iterate rcu read lock tcp_rcv_established tcp_v4_do_rcv nf_hook_slow nf_hook_thresh ___napi_schedule __napi_schedule e1000_intr handle_irq do_IRQ common_interrupt interrupt get_rps_cpu sock_queue_rcv_skb ip_queue_rcv_skb __udp_queue_rcv_skb udp_queue_rcv_skb __udp4_lib_rcv ip_local_deliver_finish NF_HOOK ip_defrag ip_rcv_finish NF_HOOK ip_rcv __netif_recive_skb process_backlog net_rx_action __do_softirq netif_receive_skb do_softirq e1000_receive_skb e1000_clean_rx_irq e1000_clean net_rx_action __do_softirq do_softirq rps flow table backlog lock backlog enqueue_to_backlog sk->sk_data_ready fib_lookup ip_route_input_slow ip_route_input_common fib ip_mkroute_input ___napi_schedule rps_trigger_softirq handle_irq do_IRQ common_interrupt interrupt arch_send_call_function_single_ipi generic_exec_single __smp_call_function_single net_rps_action_and_irq_enable ___napi_schedule process_backlog NF_HOOK_THRESH ip_route_input_noref rt_hash_table ip_local_deliver ipq lock ipq_put ip_frag_queue ip_find udp_rcv udp_table __udp4_lib_lookup_skb tcp_v4_rcv sk->sk_data_ready tcp_hashinfo __inet_lookup_skb read sys_read sys_read vfs_read file->f_op->read sock_aio_read do_sock_read __sock_recvmsg_nosec inet_recvmsg sk_wait_data tcp_recvmsg udp_recvmsg __skb_recv_datagram wait_for_packet finish_wait sk_receiv e_queue sk_backlog
- 3. Traditional Network Stack Process(User) Process(Kernel) SW Intr Handler ソフトウェア割り込みスケジュール ハードウェア割り込み HW Intr Handler ユーザ プログラム システムコール ソケット 受信処理 プロセス起床 プロトコル処理 パケット受信 user buffer socket queue input queue パケット ユーザ空間へコピー netif_rx()
- 4. 旧来のパケット受信処理 Process(User) Process(Kernel) SW Intr Handler ソフトウェア割り込みスケジュール ハードウェア割り込み HW Intr Handler ユーザ プログラム システムコール ソケット 受信処理 プロセス起床 プロトコル処理 パケット受信 user buffer socket queue input queue パケット ユーザ空間へコピー ハードウェア割り込み ↓ 受信キューにキュー イング ↓ ソフトウェア割り込 みスケジュール 13年6月7日金曜日
- 5. 旧来のパケット受信処理 • １パケット受信するたびに割り込みを 受けて処理を行っている • 64byte frameの最大受信可能数： • GbE：約1.5Mpps（150万） • 10GbE：約15Mpps（1500万） 13年6月7日金曜日
- 6. 1. 割り込みが多すぎる Process(User) Process(Kernel) SW Intr Handler ソフトウェア割り込みスケジュール ハードウェア割り込み HW Intr Handler ユーザ プログラム システムコール ソケット 受信処理 プロセス起床 プロトコル処理 パケット受信 user buffer socket queue input queue パケット ユーザ空間へコピー 13年6月7日金曜日
- 7. 割り込みが多すぎる • NICの性能向上によって、一定時間に NICが処理できるパケット数が飛躍的に 増加 • １パケット毎に割り込みが来ると、通 信量が多いときにコンテキストスイッ チ回数が増えすぎ性能が劣化 13年6月7日金曜日
- 8. 割り込みを無効にする？ • ポーリング方式 • NICの割り込みを禁止し、代わりにクロック割り込み を用いて定期的に受信キューをチェック • デメリット：レイテンシが上がる・定期的にCPUを起 こす必要がある • ハイブリッド方式 • 通信量が多く連続してパケット処理を行っている時の み割り込みを無効化してポーリングで動作 13年6月7日金曜日
- 9. NAPI（ハイブリッド方式） Process(User) Process(Kernel) SW Intr Handler パケット受信 ソフトウェア割り込みスケジュール ハードウェア割り込み HW Intr Handler ユーザ プログラム システムコール ソケット 受信処理 プロセス起床 プロトコル処理 割り込み無効化 user buffer socket queue パケット ユーザ空間へコピー パパケケッットト パケットが無くなる まで繰り返し ハードウェア割り込み ↓ 割り込み無効化＆ ポーリング開始 ↓ パケットが無くなっ たら割り込み有効化 13年6月7日金曜日
- 10. NICの割り込みハンドラと NAPI（e1000_intr） sd = &_get_cpu_var(softnet_data) if (napi_schedule_prep(&adapter->napi)) __napi_schedule(&adapter->napi) → list_add_tail(&napi->poll_list, sd->poll_list) __raise_softirq_irqoff(NET_RX_SOFTIRQ) // 割り込みを再開しない！
- 11. 受信ソフト割り込み （net_rx_action） sd = &_get_cpu_var(softnet_data) foreach (napi : sd->poll_list) napi->poll(napi->weight)
- 12. NAPI poll処理 （e1000_clean） Interrupt Coalescing • NICがOS負荷を考慮して割り込みを間 引く • パケット数個に一回割り込む、 或いは一定期間待ってから割り込む • デメリット：レイテンシが上がる while (weight̶) skb <- RX queue napi_gro_receive(skb) → netif_receive_skb(skb) → ip_rcv() if (RX queue.empty) napi_complete(napi) → list_del(&napi->poll_list) e1000_irq_enable() 13年6月7日金曜日
- 13. 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日金曜日
- 14. 2.プロトコル処理が重い Process(User) Process(Kernel) SW Intr Handler パケット受信 ソフトウェア割り込みスケジュール ハードウェア割り込み HW Intr Handler ユーザ プログラム システムコール ソケット 受信処理 プロセス起床 プロトコル処理 割り込み無効化 user buffer socket queue パケット ユーザ空間へコピー パパケケッットト パケットが無くなる まで繰り返し 13年6月7日金曜日
- 15. プロトコル処理が重い • 特に小さなパケットが大量に届く場合にプ ロトコル処理でCPU時間を大量に使ってしま う • パケット数分プロトコルスタックが呼び出 される 例：64byte frameの場合 →理論上の最大値は1500万回/s 13年6月7日金曜日
- 16. LRO (Large Receive Offload) • NICが受信したTCPパケットを結合し、 大きなパケットにしてからOSへ渡す • プロトコルスタックの呼び出し回数を 削減 • LinuxではソフトウェアによるLROが実 装されている（GRO） 13年6月7日金曜日
- 17. LROが無い場合 To network stack seq 10000 seq 10001 seq 10002 seq 10003 ←1500bytes→ • パケット毎にネットワークスタックを 実行 13年6月7日金曜日
- 18. LROが有る場合 To network stack big one packet seq 10000 seq 10001 seq 10002 seq 10003 ←1500bytes→ • パケットを結合してからネットワークスタックを 実行、ネットワークスタックの実行回数を削減 13年6月7日金曜日
- 19. Functions — Intel® 82599 10 GbE Controller LRO on ixgbe(RSC) First packet in the RSC Header Payload-1 CRC Header Payload-2 CRC Header Rx Payload-3 CRC Header Payload-4 CRC Packets Large Rx “Packet” Header Payload-1 Payload-2 Payload-3 Payload-4 Large Rx Buffers Large Rx Descriptors NEXTP Data Length = whole buffer size NEXTP Data Length = whole buffer size Figure 7.41. RSC Functionality (No Header Split) Last packet in the RSC Header Payload-1 Payload-2 Payload-3 Large Receive example while using Advanced receive descriptors (SRRCTL.DESCTYPE = 1) Payload-4 EOP Data Length = partial buffer size
- 20. GROの仕組み • napi_complete()が来るかMAX_GRO_SKBSに 達するまでnapi->gro_listにskbを繋いでいく • リスト上に繋いだskbが同じflowの隣り合ったパ ケットかチェック • くっつけられるところまで一つのskbにくっつけ て、netif_receive_skbに渡す
- 21. GROの効果 • Intel 82599(ixgbe)で比較 • MultiQueueは無効化 • iperfのTCPモードで計測 • ethtool -K ix0 gro off packets network stack called 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日金曜日
- 22. 3.複数のCPUでパケット処理したい cpu0 Process(User) Process(Kernel) SW Intr Handler パケット受信 ソフトウェア割り込みスケジュール ハードウェア割り込み HW Intr Handler ユーザ プログラム システムコール ソケット 受信処理 プロセス起床 プロトコル処理 割り込み無効化 user buffer socket queue パケット ユーザ空間へコピー パパケケッットト パケットが無くなる まで繰り返し cpu1 Process(User) Process(Kernel) SW Intr Handler パケット受信 ソフトウェア割り込みスケジュール ハードウェア割り込み HW Intr Handler ユーザ プログラム システムコール ソケット 受信処理 プロセス起床 プロトコル処理 割り込み無効化 user buffer socket queue パケット ユーザ空間へコピー パパケケッットト パケットが無くなる まで繰り返し 13年6月7日金曜日
- 24. 何故偏る？ ソフト割り込みはNICの割り込みがかかったCPUへ スケジュールされる ↓ ポーリングからプロトコルスタックの実行まで ソフト割り込み内で実行される ↓ NICの割り込みがかかっているCPUだけに 負荷がかかる 13年6月7日金曜日
- 25. ソフト割り込みが１つのコ アに偏って性能が出ない • memcachedなどショートパケットを大 量に捌くワークロードで顕在化 • ソフトウェア割り込みを実行している CPUがボトルネックになり、性能がス ケールしなくなる 13年6月7日金曜日
- 26. 解決方法 • パケットを複数のCPUへ分散させてから プロトコル処理する仕組みがあれば良い • 但し、TCPには順序保証が有るので並列 に処理されるとパケットの並べ直し（リ オーダ）が発生してパフォーマンスが落 ちる 13年6月7日金曜日
- 27. TCP Reordering １ 2 3 4 5 6 １ 2 3 4 5 6 protocol processing user buffer • シーケンスナンバー通りの順序でパケットが 着信していれば順にバッファへコピーしてい くだけでよいが… 13年6月7日金曜日
- 28. TCP Reordering １ 2 4 5 3 6 reorder queue 3 4 5 １ 2 3 4 5 6 protocol processing user buffer • 順序が乱れているとパケットの並べ直し （リオーダ）作業が必要になる 13年6月7日金曜日
- 29. 解決方法（続） • １つのフローは１つのCPUで処理され る方が都合が良い 13年6月7日金曜日
- 30. RSS （Receive Side Scaling） • CPUごとに別々の受信キューを持つNIC （MultiQueue NICと呼ばれる） • 受信キューごとに独立した割り込みを持つ • 同じフローに属するパケットは同じキューへ、 異なるフローに属するパケットはなるべく別のキュ ーへ分散 →パケットヘッダのハッシュ値を計算する事により 宛先キューを決定 13年6月7日金曜日
- 31. MSI-X割り込み • PCI Expressでサポート • デバイスあたり2048個のIRQを持てる • それぞれのIRQの割り込み先CPUを選べ る →1つのNICがCPUコア数分のIRQを持 てる 13年6月7日金曜日
- 32. おさらい：MultiQueue NICの割り込み 47: 7602 0 0 0 0 3 23 0 PCI-MSI-edge p1p1-TxRx-0 48: 0 7602 0 0 0 0 13 12 PCI-MSI-edge p1p1-TxRx-1 49: 12 0 7605 0 0 0 10 0 PCI-MSI-edge p1p1-TxRx-2 50: 0 12 0 7602 3 0 10 0 PCI-MSI-edge p1p1-TxRx-3 51: 0 0 12 0 7602 3 10 0 PCI-MSI-edge p1p1-TxRx-4 52: 0 0 0 20 0 7602 13 0 PCI-MSI-edge p1p1-TxRx-5 53: 0 0 0 0 12 0 7612 3 PCI-MSI-edge p1p1-TxRx-6 54: 3 0 0 0 0 13 10 7602 PCI-MSI-edge p1p1-TxRx-7 55: 0 2 0 0 0 0 2 0 PCI-MSI-edge p1p1 CPU毎に送受信キュー、キュー毎に MSI-X割り込みを持つ 正しいsmp_affinityは固定的に決まっ ている 複数CPUへ散らしてはならない
- 33. RSSによる パケット振り分け NIC cpu0 cpu1 cpu2 cpu3 ハッシュ計算 パケット着信 パパケパケッケットットト hash queue ディスパッチ 参照 受信処理 RX Queue #0 RX Queue #1 RX Queue #2 RX Queue #3 受信処理 割り込み ■ ■ 0 1 13年6月7日金曜日
- 34. キュー選択の手順 indirection_table[64] = initial_value input[12] = {src_addr, dst_addr, src_port, dst_port} key = toeplitz_hash(input, 12) index = key & 0x3f queue = indirection_table[index] 13年6月7日金曜日
- 37. RPS • RSS非対応のオンボードNICをうまくつかってサー バの性能を向上させたい • ソフトでRSSを実装してしまおう • ソフト割り込みの段階でパケットを各CPUへばら まく • CPU間割り込みを使って他のCPUを稼動させる • RSSのソフトウエアによるエミュレーション 13年6月7日金曜日
- 38. cpu0 cpu1 cpu2 cpu3 ユーザ プログラム システム コール ソケット 受信処理 プロセス起床 プロトコル処理 ディスパッチ ハッシュ計算 パケット受信 ソフトウェア割り込み 割り込み無効化 user buffer socket queue ハードウェア割り込み パケット ユーザ空間へコピー パパケケッットト ユーザ プログラムuser ソケット 受信処理 プロトコル処理 buffer socket queue backlog #1 hash queue 参照0 1 ■ ■CPU間 割り込み backlog #2 backlog #3 13年6月7日金曜日
- 39. RPSの使い方 # echo "f" > /sys/class/net/eth0/queues/rx-0/rps_cpus # echo 4096 > /sys/class/net/eth0/queues/rx-0/ rps_flow_cnt 13年6月7日金曜日
- 40. RPSでリモートCPUへキュー （netif_receive_skb_internal） cpu = get_rps_cpu(skb) → skb_flow_dissect(skb, &keys) hash = __flow_hash_3words(keys.dst, keys.src, keys.ports) map = rxqueue->rps_map cpu = map->cpus[(hash * map->len) >> 32] enqueue_to_backlog(skb, cpu) → sd = &per_cpu(softnet_data, cpu) __skb_queue_tail(&sd->input_pkt_queue, skb) rps_ipi_queued(sd) &__get_cpu_var(softnet_data)->rps_ipi_list = sd net_rx_action napi->poll process_backlog net_rps_action_and_irq_enable smp_call_function_single_async
- 43. RPS netperf result netperf benchmark result on lwn.net: e1000e on 8 core Intel Without RPS: 90K tps at 33% CPU With RPS: 239K tps at 60% CPU foredeth on 16 core AMD Without RPS: 103K tps at 15% CPU With RPS: 285K tps at 49% CPU 13年6月7日金曜日
- 44. RFS • プロセス追跡機能をRPSに追加 13年6月7日金曜日
- 45. RFS フローに割り当てら れたキューが宛先プ ロセスのCPUと異な るとオーバヘッドが 発生する 13年6月7日金曜日
- 46. RFS ハッシュテーブルの 設定値を変更する 事でCPUを一致さ せる事ができる 13年6月7日金曜日
- 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_entries 13年6月7日金曜日
- 48. RFSの実装 • ソフト割り込みコンテキストからパケット届け先 のプロセスが動いているCPUなんて分からない • システムコールコンテキストからパケットヘッダ のハッシュ値なんて分からない • パケットヘッダのハッシュ値とプロセスが動いて いるCPU番号の対応表を更新し続ける必要があ る
- 49. cpu0 cpu1 cpu2 cpu3 ユーザ プログラム システム コール ソケット 受信処理 プロセス起床 プロトコル処理 ディスパッチ ハッシュ計算 パケット受信 ソフトウェア割り込み 割り込み無効化 user buffer socket queue ハードウェア割り込み パケット ユーザ空間へコピー パパケケッットト ユーザ プログラムuser ソケット 受信処理 プロトコル処理 buffer socket queue backlog #1 hash queue 参照0 1 ■ ■CPU間 割り込み backlog #2 backlog #3 13年6月7日金曜日
- 50. ソフト割り込みコンテキストから ハッシュ値をソケットに保存 （tcp_v4_do_rcv） sock_rps_save_rxhash(sk, skb) → sk->sk_rxhash = skb->hash
- 51. システムコールコンテキストから CPU番号をテーブルに保存 （inet_recvmsg） sock_rps_record_flow(sk) → idx = sk->sk_rxhash & rps_sock_flow_table->mask; rps_sock_flow_table->ents[idx] = raw_smp_processor_id()
- 52. 受信処理の真っ最中に 配送先CPUを変更すると…？ • 変更前CPUと変更後CPUで同時に１つのフロー の受信処理が実行される • 変更後CPUの方が空いていて処理が早かった場 合、受信順序が前後する可能性がある • TCP Reordering発生 → 遅くなる
- 53. 無難なタイミングで 宛先CPU変更 • システムコール側のテーブル （rps_sock_flow_table）とパケットディスパッ チに使うテーブル（rxqueue->rps_flow_table） を別に持つ • 変更元CPUのbacklogに積み残しが無いタイミ ングで切り替えを行う
- 54. RFS netperf result netperf 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% CPU RPC 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.61 13年6月7日金曜日
- 55. Accelerated RFS • RFSをMultiQueue NICでも実現するため のNICドライバ拡張 • Linux kernelはプロセスの実行中CPUを NICドライバに通知 • NICドライバは通知を受けてフローのキ ュー割り当てを更新 13年6月7日金曜日
- 56. Receive Side Scalingの制限 • 32bitのハッシュ値をそのまま使用して いればハッシュ衝突しにくいが、 Indirection Tableが小さいので少ないビッ ト数でindex値をマスクしている →フローが多い時にハッシュ衝突する • Accelerated RFSには不向き 13年6月7日金曜日
- 57. • Disabling RSS on the fly is not allowed, and the 82599 must be reset after RSS is disabled. • When RSS is disabled, packets are assigned an RSS output index = zero. When multiple request queues are enabled in RSS mode, un-decodable packets are assigned an RSS output index = zero. The 32-bit tag (normally a result of the hash function) equals zero. Receive Side Scalingの制限 Parsed receive packet RSS hash 7 LS bits 32 Packet Descriptor 7 128フローしか 識別出来ない RSS Disable or (RSS & not decodable) Redirection Table 128 x 4 4 0 4 RSS output index 32bitのハッシュ値のうち 4bitしか使ってない フローが多いとハッシュ衝突する為、特定フローを Figure 7.10. RSS Block Diagram 特定CPUへキューするのには向いていない
- 58. Flow Steering • フローとキューの対応情報を記憶 4tuple：キュー番号のような形式で設定 • RSSのような明確な共通仕様は無いが、 各社の10GbEに実装されている • Accelerated RFSはFlow Steeringを前提と している 13年6月7日金曜日
- 59. Intel Ethernet Flow Director • Accelerated RFSガン無視 • 32kのハッシュテーブルの先にリンクドリスト • 2つのFilter mode • Signature Mode：ハッシュ値 最大32k個 • Perfect Match Mode：ヘッダの完全マッチ（dst-ip, dst-port, src-ip, src-port, protocol） 最大8k個
- 60. following figure shows a block diagram of the flow director filters. Received flows are identified buckets by a hash function on the relevant tuples as defined by the FDIR...M registers. Each bucket organized in a linked list indicated by the hash lookup table. Buckets can have a variable length while last filter in each bucket is indicated as a last. There is no upper limit for a linked list length during Flow Director programming; however, a received packet that matches a filter that exceeds the FDIRCTRL.Max-Length reported to software (see Section 7.1.2.7.5). Logic AND of Rx Packet tuples with the Flexible filters Mask registers ~350 Hash 15 bit output 15 bit address Bucket Valid First Filter PTR Bucket Valid First Filter PTR . . . . . . Flow ID Fields in “Perfect Match mode” Hash (Signature) 15 bit output Flow ID Field in “Signature mode” 32K Filter Action Hash Lookup Table Shares the Rx packet buffer memory space Addr 0 1 2 . . . M Bucket Valid First Filter PTR Bucket Valid First Filter PTR Hash-Index = 0 Flow ID fields Filter Action Collision flag Next Filter PTR Hash-Index = 1 Flow ID fields Filter Action Collision flag Next Filter PTR Hash-Index = N Flow ID fields . . . Filter Action Collision flag Next Filter PTR Hash-Index = N+1 Flow ID fields Filter Action . . . Collision flag Next Filter PTR Max recommended linked list length (FDIRCTRL.Max-Length) Hash-Index = 0 Flow ID fields Filter Action Collision flag Next Filter PTR Hash-Index = 1 Flow ID fields Collision flag Next Filter PTR . . . Bucket Valid First Filter PTR Bucket M (linked list M) Bucket 0 (linked list 0) ‘too long’ Linked list Flexible Filters table - Shares the Rx packet buffer memory space
- 61. Linuxでの利用例#1（自 動） 送信処理 プロトコル スタック ソケット システムコール proce ss ドライバ Txq NIC Flow Director Filters フィルタ 更新 プロセスコンテキストからのパケット送出時に送信 元CPUとパケットヘッダを用いてフィルタを更新
- 62. Linuxでの利用例#2（手 動） • ethtoolからフィルタをマニュアル追加 ethtool -K ntuple on ethtool -U eth0 flow-type udp4 src-ip 0xa0a0a000 src-ip-mask 0xFFFFFF00 dst-ip 0 dst-ip-mask 0 src-port 9 src-port-mask 0 dst-port 9 ethtool -U eth0 flow-type tcp4 vlan 100 vlan-mask 0xF000 action 8 • フィルタの表示 ethtool -u eth0