2023 年 10 ⽉ 17 ⽇ ‒ IIJ Lab Seminar ‒ TechTrend Talk Series vol. 6

NIC の⾼速化とシステムソフトウェア研究2010 年くらいからの振り返り

NIC

技術研究所 安形1

2
資料
• 発表資料• https://seminar-materials.iijlab.net/iijlab-seminar/iijlab-seminar20231017.pdf• https://iijlab-seminars.connpass.com/event/297595/ から辿れます• ファイルのサイズが⼤きいため (16 MB 程度) ダウンロードしていただく場合はご注意ください• 技術レポート：Internet Infrastructure Review (IIR) Vol. 60• システムソフトウェアの通信分野における2010年頃からの研究まとめ• 2023 年 9 ⽉ 26 ⽇発⾏• HTML / PDF 版：https://www.iij.ad.jp/dev/report/iir/060.html

3
概要• 2010 年くらいから 10 Gbps を超えるような速度の NIC が⽐較的安価で⼊⼿可能になり、広く利⽤されるようになった• 既存のソフトウェアの実装にとって、⾼速な NIC の性能を⼗分に引き出すのは難しいという課題が顕著になった• この課題について、システムソフトウェア分野でのこれまでの取り組みを紹介4

背景
⾼速な NIC と⽤途

5Network Interface Card (NIC)• コンピューターへ搭載可能な通信⽤ハードウェア

ケーブル接続⽤のポート

NIC

ケーブル
コンピューターへ接続するための端⼦62010 年くらいの利⽤シナリオ
サービス利⽤者の端末

サービス提供側PC
インターネット
データセンタースマートフォン

7
2010 年くらいの利⽤シナリオ
アプリケーション例
サービス利⽤者の端末
SNS

サービス提供側

検索エンジン
動画ストリーミング
クラウドストレージPC

オンラインゲーム
ビッグデータ分析
その他たくさんのスマートフォン
Web・スマホ向けサービス

インターネット
データセンター82010 年くらいの利⽤シナリオ
サービス利⽤者の端末

サービス提供側PC
インターネット
データセンタースマートフォン

92010 年くらいの利⽤シナリオ
サービス利⽤者の端末

サービス提供側

インターネット
データセンター102010 年くらいの利⽤シナリオ
サービス利⽤者の端末

サービス提供側

インターネット
データセンター
⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい112010 年くらいの利⽤シナリオ
データセンター内のサーバー
サービス利⽤者の端末

サービス提供側

NIC

10 ~ Gbps
インターネット
データセンター
⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい122010 年くらいの利⽤シナリオ
データセンター内のサーバー
サービス利⽤者の端末

サービス提供側
要求
⼤量のクライアントへ
短時間でサービスを提供したい

NIC

10 ~ Gbps
インターネット

NIC の⾼速化により各サーバーが送受信できるデータの量が増加した
データセンター

⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい132010 年くらいの利⽤シナリオ
データセンター内のサーバー
サービス利⽤者の端末

サービス提供側
要求
⼤量のクライアントへ
短時間でサービスを提供したい

NIC

10 ~ Gbps
インターネット

NIC の⾼速化により各サーバーが送受信できるデータの量が増加した
データセンター

しかし、NIC
⼤量のリクエストが集まってくるが速くなったからといって⼤量のクライアントに短時間でサービスを提供できるわけではなかった
サービス提供側はなるべく短い応答時間でサービスを提供したい14
通信関連のシステムソフトウェア
データセンター内のサーバー
サービス利⽤者の端末

サービス提供側

NIC

10 ~ Gbps
インターネット
データセンター
⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい15
通信関連のシステムソフトウェア
データセンター内のサーバー
サービス利⽤者の端末

NIC

通信関連ソフトウェア
サービス提供側
アプリケーション
ユーザー空間カーネル

TCP/IP スタック
NIC デバイスドライバ

10 ~ Gbps
インターネット
データセンター
⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい16
通信関連のシステムソフトウェア
データセンター内のサーバー
サービス利⽤者の端末

通信関連ソフトウェア
サービス提供側
アプリケーション
ユーザー空間
仮想マシン

NIC

カーネル

10 ~ Gbps

TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

インターネット

ホスト
⼤量のリクエストが集まってくる

仮想スイッチ
データセンター
NIC デバイスドライバ

サービス提供側はなるべく短い応答時間でサービスを提供したい17
通信関連のシステムソフトウェア
データセンター内のサーバー
サービス利⽤者の端末

通信関連ソフトウェア
サービス提供側
アプリケーション
ユーザー空間
仮想マシン

NIC

カーネル

10 ~ Gbps

TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

インターネット

ホスト

仮想スイッチ
データセンターハードウェア ( NIC ) が速くなった結果
⼤量のリクエストが集まってくる NIC デバイスドライバ
ソフトウェアの効率が更に重要になった
サービス提供側はなるべく短い応答時間でサービスを提供したい18

背景
既存のシステムの性能

19
通信関連のシステムソフトウェア
データセンター内のサーバー
サービス利⽤者の端末

通信関連ソフトウェア
サービス提供側
アプリケーション
ユーザー空間
仮想マシン

NIC

カーネル

10 ~ Gbps

TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

インターネット

ホスト

仮想スイッチ
データセンターハードウェア ( NIC ) が速くなった結果
⼤量のリクエストが集まってくる NIC デバイスドライバ
ソフトウェアの効率が更に重要になった
サービス提供側はなるべく短い応答時間でサービスを提供したい20
既存の実装の性能2012 年の論⽂の発表資料より

Sangjin Han, Scott Marshall, Byung-Gon Chun, Sylvia Ratnasamy, "MegaPipe: A New Programming Interface for Scalable Network I/O", OSDI 2012https://www.usenix.org/conference/osdi12/technical-sessions/presentation/han• Linux TCP スタックのメッセージ(パケット)サイズごとの性能• 論⽂が提案⼿法との⽐較対象としているベースラインの性能
アプリ

アプリ

TCP/IP
スタック
NIC
デバドラ

TCP/IP
スタック
NIC
デバドラ
10 Gbps
メッセージ交換

クライアントサーバー (8 CPU core)８(posix)スレッド

21
既存の実装の性能2012 年の論⽂の発表資料より

Sangjin Han, Scott Marshall, Byung-Gon Chun, Sylvia Ratnasamy, "MegaPipe: A New Programming Interface for Scalable Network I/O", OSDI 2012https://www.usenix.org/conference/osdi12/technical-sessions/presentation/han1.)Small)Messages)Are)Bad)• Linux TCP スタックのメッセージ(パケット)サイズごとの性能• 論⽂が提案⼿法との⽐較対象としているベースラインの性能
CPU Usage

アプリ

10

100

TCP/IP
スタック
NIC
デバドラ

TCP/IP
スタック
NIC
デバドラ

8

80

6

60

4

40

2

20

サーバー (8 CPU core) 0８(posix)スレッド

0

10 Gbps
メッセージ交換
クライアントThroughput (Gbps)

アプリ

64

128

256

Low)throughput)

512

1K

2K

Message Size (B)

4K

8K

16K

High)overhead)

CPU Usage (%)

Throughput

22
既存の実装の性能2012 年の論⽂の発表資料より

Sangjin Han, Scott Marshall, Byung-Gon Chun, Sylvia Ratnasamy, "MegaPipe: A New Programming Interface for Scalable Network I/O", OSDI 2012https://www.usenix.org/conference/osdi12/technical-sessions/presentation/han1.)Small)Messages)Are)Bad)• Linux TCP スタックのメッセージ(パケット)サイズごとの性能• 論⽂が提案⼿法との⽐較対象としているベースラインの性能• 10 Gbps を達成できない

CPU Usage

10

100

8

80

6

60

4

40

2

20

0

0

64

128

256

Low)throughput)

512

1K

2K

Message Size (B)

4K

8K

16K

High)overhead)

CPU Usage (%)• メッセージサイズ <= 1K

Throughput (Gbps)

Throughput

23
既存の実装の性能2012 年の論⽂の発表資料より

Sangjin Han, Scott Marshall, Byung-Gon Chun, Sylvia Ratnasamy, "MegaPipe: A New Programming Interface for Scalable Network I/O", OSDI 2012https://www.usenix.org/conference/osdi12/technical-sessions/presentation/han1.)Small)Messages)Are)Bad)• Linux TCP スタックのメッセージ(パケット)サイズごとの性能• 論⽂が提案⼿法との⽐較対象としているベースラインの性能• 10 Gbps を達成できない• メッセージサイズ <= 4K• 依然、⾼い CPU 使⽤率

CPU Usage

10

100

8

80

6

60

4

40

2

20

0

0

64

128

256

Low)throughput)

512

1K

2K

Message Size (B)

4K

8K

16K

High)overhead)

CPU Usage (%)• メッセージサイズ <= 1K

Throughput (Gbps)

Throughput

24
既存の実装の性能• CPU について考えると、TCP/IP スタックで費やされる時間は（厳密ではないですが概ね）パケット数に依存する25
既存の実装の性能• CPU について考えると、TCP/IP スタックで費やされる時間は（厳密ではないですが概ね）パケット数に依存する• NIC の特性上、同じ帯域でも、パケットのサイズが⼩さい場合の⽅が⼤きい場合より多くのパケットを送れる26
既存の実装の性能• CPU について考えると、TCP/IP スタックで費やされる時間は（厳密ではないですが概ね）パケット数に依存する• NIC の特性上、同じ帯域でも、パケットのサイズが⼩さい場合の⽅が⼤きい場合より多くのパケットを送れる

NI C

帯域

NI C

27
既存の実装の性能• CPU について考えると、TCP/IP スタックで費やされる時間は（厳密ではないですが概ね）パケット数に依存する• NIC の特性上、同じ帯域でも、パケットのサイズが⼩さい場合の⽅が⼤きい場合より多くのパケットを送れる

NI C

帯域

NI C

28
既存の実装の性能• CPU について考えると、TCP/IP スタックで費やされる時間は（厳密ではないですが概ね）パケット数に依存する• NIC の特性上、同じ帯域でも、パケットのサイズが⼩さい場合の⽅が⼤きい場合より多くのパケットを送れる

NI C

帯域

NI C

29
既存の実装の性能• CPU について考えると、TCP/IP スタックで費やされる時間は（厳密ではないですが概ね）パケット数に依存する• NIC の特性上、同じ帯域でも、パケットのサイズが⼩さい場合の⽅が⼤きい場合より多くのパケットを送れる

NI C

帯域

NI C

30
既存の実装の性能• CPU について考えると、TCP/IP スタックで費やされる時間は（厳密ではないですが概ね）パケット数に依存する• NIC の特性上、同じ帯域でも、パケットのサイズが⼩さい場合の⽅が⼤きい場合より多くのパケットを送れる

NI C

帯域

NI C

TCP/IP ヘッダはパケットごとについているので、パケットごとに処理が必要31
既存の実装の性能• CPU について考えると、TCP/IP スタックで費やされる時間は（厳密ではないですが概ね）パケット数に依存する• NIC の特性上、同じ帯域でも、パケットのサイズが⼩さい場合の⽅が⼤きい場合より多くのパケットを送れる
TCP/IP スタックが処理する必要があるヘッダ

NI C

帯域

NI C

TCP/IP ヘッダはパケットごとについているので、パケットごとに処理が必要32
既存の実装の性能• CPU について考えると、TCP/IP スタックで費やされる時間は（厳密ではないですが概ね）パケット数に依存する• NIC の特性上、同じ帯域でも、パケットのサイズが⼩さい場合の⽅が⼤きい場合より多くのパケットを送れる
TCP/IP スタックが処理する必要があるヘッダ

NI C

帯域

NI C

TCP/IP ヘッダはパケットごとについているので、パケットごとに処理が必要33
既存の実装の性能• CPU について考えると、TCP/IP スタックで費やされる時間は（厳密ではないですが概ね）パケット数に依存する• NIC の特性上、同じ帯域でも、パケットのサイズが⼩さい場合の⽅が⼤きい場合より多くのパケットを送れる
TCP/IP スタックが処理する必要があるヘッダ

NI C

帯域

NI C

TCP/IP ヘッダはパケットごとについているので、パケットごとに処理が必要

34
パケットサイズが⼩さい⽅が既存の実装の性能

TCP/IP スタックにとって最⼤の仕事の量が多くなる• CPU について考えると、TCP/IP スタックで費やされる時間は（厳密ではないですが概ね）パケット数に依存する• NIC の特性上、同じ帯域でも、パケットのサイズが⼩さい場合の⽅が⼤きい場合より多くのパケットを送れる
TCP/IP スタックが処理する必要があるヘッダ

NI C

帯域

NI C

TCP/IP ヘッダはパケットごとについているので、パケットごとに処理が必要

35
パケットサイズが⼩さい⽅がSangjin Han, Scott Marshall, Byung-Gon Chun, Sylvia Ratnasamy, "MegaPipe: A New Programming Interface for Scalable Network I/O", OSDI 2012https://www.usenix.org/conference/osdi12/technical-sessions/presentation/han

Throughput

CPU Usage

既存の実装の性能

TCP/IP100スタックにとって最⼤の仕事の量が多くなる
80

8

CPU Usage (%)

Throughput (Gbps)

10

6
60
• CPU について考えると、TCP/IP
スタックで費やされる時間は（厳密ではないですが概ね）パケット数に依存する
440• NIC の特性上、同じ帯域でも、パケットのサイズが220
⼩さい場合の⽅が⼤きい場合より多くのパケットを送れる
0

64

128

256

512

1K

2K

4K

8K

16K

0

Message Size (B) High)overhead)
TCP/IP スタックが処理する必要があるヘッダ
Low)throughput)
OSDI)2012)

NI C

9)

帯域

NI C

TCP/IP ヘッダはパケットごとについているので、パケットごとに処理が必要

36
パケットサイズが⼩さい⽅がSangjin Han, Scott Marshall, Byung-Gon Chun, Sylvia Ratnasamy, "MegaPipe: A New Programming Interface for Scalable Network I/O", OSDI 2012https://www.usenix.org/conference/osdi12/technical-sessions/presentation/han

Throughput

CPU Usage

既存の実装の性能

TCP/IP100スタックにとって最⼤の仕事の量が多くなる
80

8

CPU Usage (%)

Throughput (Gbps)

10

6
60
• CPU について考えると、TCP/IP
スタックで費やされる時間は（厳密ではないですが概ね）パケット数に依存する
440• NIC の特性上、同じ帯域でも、パケットのサイズが220
⼩さい場合の⽅が⼤きい場合より多くのパケットを送れる
0

64

128

256

512

1K

2K

4K

8K

16K

0

Message Size (B) High)overhead)
TCP/IP スタックが処理する必要があるヘッダ
Low)throughput)
OSDI)2012)

NI C

9)

帯域

NI C

TCP/IP ヘッダはパケットごとについているので、パケットごとに処理が必要

37
パケットサイズが⼩さい⽅がSangjin Han, Scott Marshall, Byung-Gon Chun, Sylvia Ratnasamy, "MegaPipe: A New Programming Interface for Scalable Network I/O", OSDI 2012https://www.usenix.org/conference/osdi12/technical-sessions/presentation/han

Throughput

CPU Usage

既存の実装の性能

TCP/IP100スタックにとって最⼤の仕事の量が多くなる
80

8

CPU Usage (%)

Throughput (Gbps)

10

6
60
• CPU について考えると、TCP/IP
スタックで費やされる時間は（厳密ではないですが概ね）パケット数に依存する
440• NIC の特性上、同じ帯域でも、パケットのサイズが220
⼩さい場合の⽅が⼤きい場合より多くのパケットを送れる
0

64

128

256

512

1K

2K

4K

8K

16K

0

Message Size (B) High)overhead)
TCP/IP スタックが処理する必要があるヘッダ
Low)throughput)
OSDI)2012)

NI C

9)

帯域

NI C

TCP/IP ヘッダはパケットごとについているので、パケットごとに処理が必要

38
パケットサイズが⼩さい⽅がSangjin Han, Scott Marshall, Byung-Gon Chun, Sylvia Ratnasamy, "MegaPipe: A New Programming Interface for Scalable Network I/O", OSDI 2012https://www.usenix.org/conference/osdi12/technical-sessions/presentation/han

Throughput

CPU Usage

既存の実装の性能

TCP/IP100スタックにとって最⼤の仕事の量が多くなる
80

8

CPU Usage (%)

Throughput (Gbps)

10

6
60
• CPU について考えると、TCP/IP
スタックで費やされる時間は（厳密ではないですが概ね）パケット数に依存する
440• NIC の特性上、同じ帯域でも、パケットのサイズが220
⼩さい場合の⽅が⼤きい場合より多くのパケットを送れる
0

64

128

256

512

1K

2K

4K

8K

16K

0

Message Size (B) High)overhead)
TCP/IP スタックが処理する必要があるヘッダ
Low)throughput)
OSDI)2012)

NI C

9)

帯域

NI C

TCP/IP ヘッダはパケットごとについているので、パケットごとに処理が必要39
2010 年くらいの利⽤シナリオ
サービス利⽤者の端末

サービス提供側

インターネット
データセンター
⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい40
2010 年くらいの利⽤シナリオ
サービス利⽤者の端末

サービス提供側

Web
サーバー

インメモリ
キャッシュ
サーバー

インターネット
データセンター
⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい41
2010 年くらいの利⽤シナリオ
サービス利⽤者の端末

サービス提供側

やりとりするデータのサイズが⽐較的⼩さい場合が多い
Web
サーバー

インメモリ
キャッシュ
サーバー

インターネット
データセンター
⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい42

Sangjin Han, Scott Marshall, Byung-Gon Chun, Sylvia Ratnasamy, "MegaPipe: A New Programming Interface for Scalable Network I/O", OSDI 2012https://www.usenix.org/conference/osdi12/technical-sessions/presentation/han

2010 年くらいの利⽤シナリオ
サービス利⽤者の端末

インターネット

880

インメモリ 60
キャッシュ
40
サーバー

Web
サーバー

6
4
2
0

CPU Usage (%)

Throughput (Gbps)

サービス提供側1.)Small)Messages)Are)Bad)
やりとりするデータのサイズがThroughput
CPU Usage
⽐較的⼩さい場合が多い 10
100

20

64

128

256

512

1K

2K

4K

8K

16K

0

Message Size (B) High)overhead)Low)throughput) データセンター
OSDI)2012)

⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい

9)

43

Sangjin Han, Scott Marshall, Byung-Gon Chun, Sylvia Ratnasamy, "MegaPipe: A New Programming Interface for Scalable Network I/O", OSDI 2012https://www.usenix.org/conference/osdi12/technical-sessions/presentation/han

2010 年くらいの利⽤シナリオ
サービス利⽤者の端末

インターネット

880

インメモリ 60
Web
TCP/IP
スタックが
キャッシュ
サーバー
4
40
サーバー
ボトルネックに
6

2
0CPU Usage (%)

Throughput (Gbps)

サービス提供側1.)Small)Messages)Are)Bad)
やりとりするデータのサイズがThroughput
CPU Usage
⽐較的⼩さい場合が多い 10
100

20

64

128

256

512

1K

2K

4K

8K

16K

0

Message Size (B) High)overhead)Low)throughput) データセンター
OSDI)2012)

⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい

9)44
通信関連のシステムソフトウェア
データセンター内のサーバー
サービス利⽤者の端末

通信関連ソフトウェア
サービス提供側
アプリケーション
ユーザー空間
仮想マシン

NIC

カーネル

10 ~ Gbps

TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

インターネット

ホスト

仮想スイッチ
データセンターハードウェア ( NIC ) は速くなったので
⼤量のリクエストが集まってくる NIC デバイスドライバ
ソフトウェアの効率が重要になる
サービス提供側はなるべく短い応答時間でサービスを提供したい45
通信関連のシステムソフトウェア
データセンター内のサーバー
サービス利⽤者の端末

通信関連ソフトウェア
サービス提供側
アプリケーション
ユーザー空間
仮想マシン

NIC

カーネル

10 ~ Gbps

TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

インターネット

ホスト

仮想スイッチ
データセンターハードウェア ( NIC ) は速くなったので
⼤量のリクエストが集まってくる NIC デバイスドライバ
ソフトウェアの効率が重要になる
サービス提供側はなるべく短い応答時間でサービスを提供したい46
既存の実装の性能• 仮想マシンからの単純なパケット転送性能：Linux vhost-net
送信側
仮想
マシン

ホスト

アプリ
NIC デバドラ

vhost-net
Linux bridge

仮想 NIC
バックエンド
仮想
スイッチ

アプリ

NIC デバドラ

NIC デバドラ

受信側

10 Gbps47
既存の実装の性能• 仮想マシンからの単純なパケット転送性能：Linux vhost-net
送信側

ホスト

アプリ
NIC デバドラ

10

vhost-net
Linux bridge

仮想 NIC
バックエンド
仮想
スイッチ

アプリ

NIC デバドラ

NIC デバドラ

受信側

10 GbpsThroughput [Gbps]

仮想
マシン

8
6
4
2
0
64

128

256

512

Packet Size [B]1024 1472

48
2010 年くらいの利⽤シナリオ
サービス利⽤者の端末

サービス提供側

やりとりするデータのサイズが⽐較的⼩さい場合が多い
Web
サーバー

インメモリ
キャッシュ
サーバー

インターネット
データセンター
⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい49
2010 年くらいの利⽤シナリオ
サービス利⽤者の端末

サービス提供側

やりとりするデータのサイズが⽐較的⼩さい場合が多い

インターネット

Web
サーバー

インメモリ
キャッシュ
サーバー

仮想マシン

仮想マシン

データセンター
⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい50
2010 年くらいの利⽤シナリオ
サービス利⽤者の端末

サービス提供側

やりとりするデータのサイズが⽐較的⼩さい場合が多い

インターネット

Throughput [Gbps]

10

8
6
4

Web
サーバー

インメモリ
キャッシュ
サーバー

仮想マシン

仮想マシン

2

0
⼤量のリクエストが集まってくる64

データセンター
128

256

512 1024 1472

Packet Size [B]サービス提供側はなるべく短い応答時間でサービスを提供したい51
2010 年くらいの利⽤シナリオ
サービス利⽤者の端末

サービス提供側

やりとりするデータのサイズが⽐較的⼩さい場合が多い

インターネット

Throughput [Gbps]

10

8

インメモリ
Web
キャッシュ
サーバー
I/O
が
6 仮想マシンのサーバー
ボトルネックに
4

仮想マシン

2

0
⼤量のリクエストが集まってくる64

仮想マシン

データセンター
128

256

512 1024 1472

Packet Size [B]サービス提供側はなるべく短い応答時間でサービスを提供したい52

Sangjin Han, Scott Marshall, Byung-Gon Chun, Sylvia Ratnasamy, "MegaPipe: A New Programming Interface for Scalable Network I/O", OSDI 2012https://www.usenix.org/conference/osdi12/technical-sessions/presentation/han

10 Gbps NIC の普及• 1.)Small)Messages)Are)Bad)
ソフトウェアの視点から、性能について⼤きな伸び代ができた
100

8

80

伸び代

6

60

4

40

2

20

0

0

64

128

256

512

1K

2K

Message Size (B)

4K

8K

16K

10
Throughput [Gbps]

10Low)throughput)
OSDI)2012)

CPU Usage

CPU Usage (%)

Throughput (Gbps)

Throughput

8

伸び代

6
4
2
0
64

High)overhead)
9)

128

256

512 1024 1472

Packet Size [B]53

Sangjin Han, Scott Marshall, Byung-Gon Chun, Sylvia Ratnasamy, "MegaPipe: A New Programming Interface for Scalable Network I/O", OSDI 2012https://www.usenix.org/conference/osdi12/technical-sessions/presentation/han

課題• 1.)Small)Messages)Are)Bad)
伸び代をどのように引き出して有効活⽤するか？
100

8

80

伸び代

6

60

4

40

2

20

0

0

64

128

256

512

1K

2K

Message Size (B)

4K

8K

16K

10
Throughput [Gbps]

10Low)throughput)
OSDI)2012)

CPU Usage

CPU Usage (%)

Throughput (Gbps)

Throughput

8

伸び代

6
4
2
0
64

High)overhead)
9)

128

256

512 1024 1472

Packet Size [B]

54

研究紹介
システムコール呼び出しコストについて
基本的な仕組みの説明

55
システムコールの呼び出しコスト• システムコール• ユーザー空間プログラムがカーネル空間の機能を呼び出すためのインターフェース

56
通信関連のシステムソフトウェア
データセンター内のサーバー
サービス利⽤者の端末

NIC

通信関連ソフトウェア
サービス提供側
アプリケーション
ユーザー空間カーネル

TCP/IP スタック
NIC デバイスドライバ

10 ~ Gbps
インターネット
データセンター
⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい57
通信関連のシステムソフトウェア
ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

58
システムコールの呼び出しコスト

ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

59
システムコールの呼び出しコスト• システムコール• ユーザー空間プログラムがカーネル空間の機能を呼び出すためのインターフェース• ユーザー空間プログラムはカーネルに実装されている TCP/IP
スタックを、システムコールを通して利⽤する
ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

60
システムコールの呼び出しコスト• システムコール• ユーザー空間プログラムがカーネル空間の機能を呼び出すためのインターフェース• ユーザー空間プログラムはカーネルに実装されている TCP/IP
スタックを、システムコールを通して利⽤する
ユーザー空間カーネル

アプリケーション
システムコール
TCP/IP スタック
NIC デバイスドライバ

61
システムコールの呼び出しコスト• システムコール
システムコールと通常の関数呼び出しの違い• ユーザー空間プログラムがカーネル空間の機能を呼び出すためのインターフェース• ユーザー空間プログラムをカーネルに実装されている TCP/IP
スタックを、システムコールを通して利⽤する
ユーザー空間カーネル

アプリケーション
システムコール
TCP/IP スタック
NIC デバイスドライバ

62
システムコールの呼び出しコスト• システムコール
システムコールと通常の関数呼び出しの違い• ユーザー空間プログラムがカーネル空間の機能を呼び出すためのインターフェース• ユーザー空間プログラムをカーネルに実装されている TCP/IP
スタックを、システムコールを通して利⽤する
⾮特権モード ユーザー空間

アプリケーション
システムコール

特権モード

TCP/IP スタック

カーネル

NIC デバイスドライバ

63
システムコールの呼び出しコスト• システムコール
システムコールと通常の関数呼び出しの違い• ユーザー空間プログラムがカーネル空間の機能を呼び出すためのインシステムコールは、CPU のモードを⾮特権モード（ユーザー空間）からターフェース
特権モード（カーネル）への切り替えた後、カーネルに実装された関数を呼ぶ• ユーザー空間プログラムをカーネルに実装されている TCP/IP
スタックを、システムコールを通して利⽤する
⾮特権モード ユーザー空間

アプリケーション
システムコール

特権モード

TCP/IP スタック

カーネル

NIC デバイスドライバ

64
システムコールの呼び出しコスト• システムコール
システムコールと通常の関数呼び出しの違い• ユーザー空間プログラムがカーネル空間の機能を呼び出すためのインシステムコールは、CPU のモードを⾮特権モード（ユーザー空間）からターフェース
特権モード（カーネル）への切り替えた後、カーネルに実装された関数を呼ぶ• ユーザー空間プログラムをカーネルに実装されている
TCP/IP
システムコールのための特権モード切り替えはスタックを、システムコールを通して利⽤する
x86-64 であれば syscall という CPU 命令を利⽤
⾮特権モード ユーザー空間

アプリケーション
システムコール

特権モード

TCP/IP スタック

カーネル

NIC デバイスドライバ

65
システムコールの呼び出しコスト• システムコール
システムコールと通常の関数呼び出しの違い• ユーザー空間プログラムがカーネル空間の機能を呼び出すためのインシステムコールは、CPU のモードを⾮特権モード（ユーザー空間）からターフェース
特権モード（カーネル）への切り替えた後、カーネルに実装された関数を呼ぶ• ユーザー空間プログラムをカーネルに実装されている
TCP/IP
システムコールのための特権モード切り替えはスタックを、システムコールを通して利⽤する
x86-64 であれば syscall という CPU 命令を利⽤
⾮特権モード ユーザー空間

アプリケーション

特権モード

TCP/IP スタック

カーネル

NIC デバイスドライバ

ユーザー空間でアプリケーションを実⾏中

66
システムコールの呼び出しコスト• システムコール
システムコールと通常の関数呼び出しの違い• ユーザー空間プログラムがカーネル空間の機能を呼び出すためのインシステムコールは、CPU のモードを⾮特権モード（ユーザー空間）からターフェース
特権モード（カーネル）への切り替えた後、カーネルに実装された関数を呼ぶ• ユーザー空間プログラムをカーネルに実装されている
TCP/IP
システムコールのための特権モード切り替えはスタックを、システムコールを通して利⽤する
x86-64 であれば syscall という CPU 命令を利⽤
⾮特権モード ユーザー空間

アプリケーション
syscall

特権モード

TCP/IP スタック

カーネル

NIC デバイスドライバ

アプリケーションがsyscall 命令を実⾏67
システムコールの呼び出しコスト• システムコール
システムコールと通常の関数呼び出しの違い• ユーザー空間プログラムがカーネル空間の機能を呼び出すためのインシステムコールは、CPU のモードを⾮特権モード（ユーザー空間）からターフェース
特権モード（カーネル）への切り替えた後、カーネルに実装された関数を呼ぶ• ユーザー空間プログラムをカーネルに実装されている
TCP/IP
システムコールのための特権モード切り替えはスタックを、システムコールを通して利⽤する
x86-64 であれば syscall という CPU 命令を利⽤
⾮特権モード ユーザー空間

アプリケーション

特権モード

TCP/IP スタック

カーネル

NIC デバイスドライバ

実⾏コンテキストがカーネルへ切り替わる

68
システムコールの呼び出しコスト• システムコール
システムコールと通常の関数呼び出しの違い• ユーザー空間プログラムがカーネル空間の機能を呼び出すためのインシステムコールは、CPU のモードを⾮特権モード（ユーザー空間）からターフェース
特権モード（カーネル）への切り替えた後、カーネルに実装された関数を呼ぶ• ユーザー空間プログラムをカーネルに実装されている
TCP/IP
システムコールのための特権モード切り替えはスタックを、システムコールを通して利⽤する
x86-64 であれば syscall という CPU 命令を利⽤
⾮特権モード ユーザー空間

アプリケーション

特権モード

TCP/IP スタック

カーネル

NIC デバイスドライバ

カーネル内に実装された関数が実⾏される(e.g., TCP/IP スタック処理)

69
システムコールの呼び出しコスト• システムコール
システムコールと通常の関数呼び出しの違い• ユーザー空間プログラムがカーネル空間の機能を呼び出すためのインシステムコールは、CPU のモードを⾮特権モード（ユーザー空間）からターフェース
特権モード（カーネル）への切り替えた後、カーネルに実装された関数を呼ぶ• ユーザー空間プログラムをカーネルに実装されている
TCP/IP
システムコールのための特権モード切り替えはスタックを、システムコールを通して利⽤する
x86-64 であれば syscall という CPU 命令を利⽤
⾮特権モード ユーザー空間

アプリケーション

特権モード

TCP/IP スタック

カーネル

NIC デバイスドライバ

カーネルは処理を完了
すると、コンテキストをユーザー空間へ戻す

70
システムコールの呼び出しコスト• システムコール
システムコールと通常の関数呼び出しの違い• ユーザー空間プログラムがカーネル空間の機能を呼び出すためのインシステムコールは、CPU のモードを⾮特権モード（ユーザー空間）からターフェース
特権モード（カーネル）への切り替えた後、カーネルに実装された関数を呼ぶ• ユーザー空間プログラムをカーネルに実装されている
TCP/IP
システムコールのための特権モード切り替えはスタックを、システムコールを通して利⽤する
x86-64 であれば syscall という CPU 命令を利⽤
⾮特権モード ユーザー空間

アプリケーション

特権モード

TCP/IP スタック

カーネル

NIC デバイスドライバ

ポイント
モード切り替えは時間がかかる処理
頻繁に呼び出すと性能劣化に繋がる71
2010 年くらいの利⽤シナリオ
サービス利⽤者の端末

サービス提供側

やりとりするデータのサイズが⽐較的⼩さい場合が多い
Web
サーバー

インメモリ
キャッシュ
サーバー

インターネット
データセンター
⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい

72
{

}

典型的なサーバーの実装/*クライアントからのリクエストデータを読み込み*/
read(fd, request_buf, sizeof(request_buf));/*リクエストに応じたレスポンスデータを⽣成*/
generate_response(request_buf, response_buf);/*レスポンスデータをクライアントへ送信*/
write(fd, response_buf, response_buf_size);

73
{

}

典型的なサーバーの実装/*クライアントからのリクエストデータを読み込み*/
read(fd, request_buf, sizeof(request_buf));/*リクエストに応じたレスポンスデータを⽣成*/
generate_response(request_buf, response_buf);/*レスポンスデータをクライアントへ送信*/
write(fd, response_buf, response_buf_size);

74
{

}

典型的なサーバーの実装/*クライアントからのリクエストデータを読み込み*/
read(fd, request_buf, sizeof(request_buf));/*リクエストに応じたレスポンスデータを⽣成*/
generate_response(request_buf, response_buf);/*レスポンスデータをクライアントへ送信*/
write(fd, response_buf, response_buf_size);

75
{

}

典型的なサーバーの実装/*クライアントからのリクエストデータを読み込み*/
read(fd, request_buf, sizeof(request_buf));/*リクエストに応じたレスポンスデータを⽣成*/
generate_response(request_buf, response_buf);/*レスポンスデータをクライアントへ送信*/
write(fd, response_buf, response_buf_size);

76
{

}

典型的なサーバーの実装/*クライアントからのリクエストデータを読み込み*/
read(fd, request_buf, sizeof(request_buf));/*リクエストに応じたレスポンスデータを⽣成*/
generate_response(request_buf, response_buf);/*レスポンスデータをクライアントへ送信*/
write(fd, response_buf, response_buf_size);

アプリケーション固有の処理（e.g., HTTP サーバー、キャッシュサーバー）

77
{

}

典型的なサーバーの実装/*クライアントからのリクエストデータを読み込み*/
read(fd, request_buf, sizeof(request_buf));/*リクエストに応じたレスポンスデータを⽣成*/
generate_response(request_buf, response_buf);/*レスポンスデータをクライアントへ送信*/
write(fd, response_buf, response_buf_size);

OS から提供されるシステムコール

78
{

}

典型的なサーバーの実装/*クライアントからのリクエストデータを読み込み*/
read(fd, request_buf, sizeof(request_buf));/*リクエストに応じたレスポンスデータを⽣成*/
generate_response(request_buf, response_buf);/*レスポンスデータをクライアントへ送信*/
write(fd, response_buf, response_buf_size);

OS から提供されるシステムコール

79
{

}

典型的なサーバーの実装/*クライアントからのリクエストデータを読み込み*/
read(fd, request_buf, sizeof(request_buf));/*リクエストに応じたレスポンスデータを⽣成*/
generate_response(request_buf, response_buf);/*レスポンスデータをクライアントへ送信*/
write(fd, response_buf, response_buf_size);
リクエスト読み込みとレスポンス書き出しを頻繁に⾏うと
システムコールが頻繁に呼び出される

80

研究紹介
システムコール呼び出しコストについて
システムコールを複数まとめてリクエストできるようにする

81
システムコールの頻度を減らす• FlexSC (OSDI 2010)

ユーザー空間アプリケーション

カーネル
カーネル機能カーネル機能82
システムコールの頻度を減らす• FlexSC (OSDI 2010)• ユーザー・カーネル空間の間に共有メモリを⽤意

ユーザー空間アプリケーション
共有メモリ

カーネル
カーネル機能カーネル機能83
システムコールの頻度を減らす• FlexSC (OSDI 2010)• ユーザー・カーネル空間の間に共有メモリを⽤意• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み

ユーザー空間アプリケーション
共有メモリ

カーネル
カーネル機能カーネル機能84
システムコールの頻度を減らす• FlexSC (OSDI 2010)• ユーザー・カーネル空間の間に共有メモリを⽤意• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取りカーネル機能を実⾏

ユーザー空間アプリケーション
共有メモリ

カーネル

カーネルスレッド
実⾏

カーネル機能カーネル機能Livio Soares and Michael Stumm. 2010. FlexSC: Flexible System Call Scheduling with Exception-Less System Calls. In 9th USENIX Symposium on Operating
Systems Design and Implementation (OSDI 10).(https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls)

Exception-less interface: syscall page
解決策：システムコールの頻度を減らす
write(fd, buf, 4096);• FlexSC (OSDI 2010)• ユーザー・カーネル空間の間に共有メモリを⽤意
entry = free_syscall_entry();• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み/* write syscall */• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取り
entry->syscall = 1;
カーネル機能を実⾏
entry->num_args = 3;
entry->args[0] = fd;
entry->args[1] = buf;
entry->args[2] = 4096;
entry->status = SUBMIT;SUBMIT

ユーザー空間while (entry->status != DONE)
DONE
do_something_else();return entry->return_code;
カーネル

DONE

アプリケーション
共有メモリ

カーネルスレッド
実⾏

カーネル機能カーネル機能1285

Livio Soares and Michael Stumm. 2010. FlexSC: Flexible System Call Scheduling with Exception-Less System Calls. In 9th USENIX Symposium on Operating
Systems Design and Implementation (OSDI 10).(https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls)

Exception-less interface: syscall page
解決策：システムコールの頻度を減らす
write(fd, buf, 4096);• FlexSC (OSDI 2010)

通常の write システムコール• ユーザー・カーネル空間の間に共有メモリを⽤意
entry = free_syscall_entry();• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み/* write syscall */• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取り
entry->syscall = 1;
カーネル機能を実⾏
entry->num_args = 3;
entry->args[0] = fd;
entry->args[1] = buf;
entry->args[2] = 4096;
entry->status = SUBMIT;SUBMIT

ユーザー空間while (entry->status != DONE)
DONE
do_something_else();return entry->return_code;
カーネル

DONE

アプリケーション
共有メモリ

カーネルスレッド
実⾏

カーネル機能カーネル機能1286

Livio Soares and Michael Stumm. 2010. FlexSC: Flexible System Call Scheduling with Exception-Less System Calls. In 9th USENIX Symposium on Operating
Systems Design and Implementation (OSDI 10).(https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls)

Exception-less interface: syscall page
解決策：システムコールの頻度を減らす
write(fd, buf, 4096);• FlexSC (OSDI 2010)• ユーザー・カーネル空間の間に共有メモリを⽤意
entry = free_syscall_entry();• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み/* write syscall */• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取り
entry->syscall = 1;
カーネル機能を実⾏
entry->num_args = 3;
entry->args[0] = fd;
entry->args[1] = buf;
entry->args[2] = 4096;
entry->status = SUBMIT;SUBMIT

ユーザー空間while (entry->status != DONE)
DONE
do_something_else();return entry->return_code;
カーネル

DONE

アプリケーション
共有メモリ
FlexSC だとこんなかんじ

カーネルスレッド
実⾏

カーネル機能カーネル機能1287

Livio Soares and Michael Stumm. 2010. FlexSC: Flexible System Call Scheduling with Exception-Less System Calls. In 9th USENIX Symposium on Operating
Systems Design and Implementation (OSDI 10).(https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls)

Exception-less interface: syscall page
解決策：システムコールの頻度を減らす
write(fd, buf, 4096);• FlexSC (OSDI 2010)• ユーザー・カーネル空間の間に共有メモリを⽤意
entry = free_syscall_entry();• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み/* write syscall */• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取り
entry->syscall = 1;
カーネル機能を実⾏
entry->num_args = 3;
entry->args[0] = fd;
entry->args[1] = buf;
entry->args[2] = 4096;
entry->status = SUBMIT;SUBMIT

ユーザー空間while (entry->status != DONE)
DONE
do_something_else();return entry->return_code;
カーネル

DONE

アプリケーション
共有メモリ
リクエスト⽤エントリを取得

カーネルスレッド
実⾏

カーネル機能カーネル機能

1288

89
Exception-less interface: syscall page
解決策：システムコールの頻度を減らす
write(fd, buf, 4096);• FlexSC (OSDI 2010)

このエントリはユーザー空間と
カーネル空間の共有メモリ上に存在• ユーザー・カーネル空間の間に共有メモリを⽤意
entry = free_syscall_entry();• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み/* write syscall */• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取り
entry->syscall = 1;
カーネル機能を実⾏
entry->num_args = 3;
entry->args[0] = fd;
entry->args[1] = buf;
entry->args[2] = 4096;
entry->status = SUBMIT;SUBMIT

DONE

アプリケーション
ユーザー空間アプリケーション
ユーザー空間while (entry->status != DONE)
while
DONE
do_something_else();return entry->return_code;
カーネル

カーネル

共有メモリ
共有メモリ
リクエスト⽤エントリを取得

カーネルスレッドカーネルスレッド実⾏
実⾏

カーネル機能カーネル機能カーネル機能カーネル機能12

Livio Soares and Michael Stumm. 2010. FlexSC: Flexible System Call Scheduling with Exception-Less System Calls. In 9th USENIX Symposium on Operating
Systems Design and Implementation (OSDI 10).(https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls)

Exception-less interface: syscall page
解決策：システムコールの頻度を減らす
write(fd, buf, 4096);• FlexSC (OSDI 2010)• ユーザー・カーネル空間の間に共有メモリを⽤意
entry = free_syscall_entry();• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み/* write syscall */• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取り
entry->syscall = 1;
カーネル機能を実⾏
entry->num_args = 3;
entry->args[0] = fd;
entry->args[1] = buf;
entry->args[2] = 4096;
entry->status = SUBMIT;SUBMIT

ユーザー空間while (entry->status != DONE)
DONE
do_something_else();return entry->return_code;
カーネル

DONE

アプリケーション
共有メモリ
システムコール番号を設定
カーネルスレッド（write は 1）
実⾏

カーネル機能カーネル機能1290

Livio Soares and Michael Stumm. 2010. FlexSC: Flexible System Call Scheduling with Exception-Less System Calls. In 9th USENIX Symposium on Operating
Systems Design and Implementation (OSDI 10).(https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls)

Exception-less interface: syscall page
解決策：システムコールの頻度を減らす
write(fd, buf, 4096);• FlexSC (OSDI 2010)• ユーザー・カーネル空間の間に共有メモリを⽤意
entry = free_syscall_entry();• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み/* write syscall */• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取り
entry->syscall = 1;
カーネル機能を実⾏
entry->num_args = 3;
entry->args[0] = fd;
entry->args[1] = buf;
entry->args[2] = 4096;
entry->status = SUBMIT;SUBMIT

ユーザー空間while (entry->status != DONE)
DONE
do_something_else();return entry->return_code;
カーネル

DONE

アプリケーション
共有メモリ
引数の数を指定カーネルスレッド
実⾏

カーネル機能カーネル機能1291

Livio Soares and Michael Stumm. 2010. FlexSC: Flexible System Call Scheduling with Exception-Less System Calls. In 9th USENIX Symposium on Operating
Systems Design and Implementation (OSDI 10).(https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls)

Exception-less interface: syscall page
解決策：システムコールの頻度を減らす
write(fd, buf, 4096);• FlexSC (OSDI 2010)• ユーザー・カーネル空間の間に共有メモリを⽤意
entry = free_syscall_entry();• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み/* write syscall */• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取り
entry->syscall = 1;
カーネル機能を実⾏
entry->num_args = 3;
entry->args[0] = fd;
entry->args[1] = buf;
entry->args[2] = 4096;
entry->status = SUBMIT;SUBMIT

ユーザー空間while (entry->status != DONE)
DONE
do_something_else();return entry->return_code;
カーネル

DONE

アプリケーション
共有メモリ
引数を指定

カーネルスレッド
実⾏

カーネル機能カーネル機能1292

Livio Soares and Michael Stumm. 2010. FlexSC: Flexible System Call Scheduling with Exception-Less System Calls. In 9th USENIX Symposium on Operating
Systems Design and Implementation (OSDI 10).(https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls)

Exception-less interface: syscall page
解決策：システムコールの頻度を減らす
write(fd, buf, 4096);• FlexSC (OSDI 2010)• ユーザー・カーネル空間の間に共有メモリを⽤意
entry = free_syscall_entry();• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み/* write syscall */• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取り
entry->syscall = 1;
カーネル機能を実⾏
entry->num_args = 3;
entry->args[0] = fd;
entry->args[1] = buf;
entry->args[2] = 4096;
entry->status = SUBMIT;SUBMIT

ユーザー空間while (entry->status != DONE)
DONE
do_something_else();return entry->return_code;
カーネル

DONE

アプリケーション
共有メモリ
ステータスをSUBMITへ変更

カーネルスレッド
実⾏

カーネル機能カーネル機能1293

Livio Soares and Michael Stumm. 2010. FlexSC: Flexible System Call Scheduling with Exception-Less System Calls. In 9th USENIX Symposium on Operating
Systems Design and Implementation (OSDI 10).(https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls)

Exception-less interface: syscall page
解決策：システムコールの頻度を減らす
write(fd, buf, 4096);• FlexSC (OSDI 2010)

アプリケーション
ユーザー空間• ユーザー・カーネル空間の間に共有メモリを⽤意 共有メモリ
entry = free_syscall_entry();• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み
カーネルスレッドカーネル/* write syscall */実⾏• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取り
entry->syscall = 1;
カーネル機能カーネル機能カーネル機能を実⾏
entry->num_args = 3;
entry->args[0] = fd;
entry->args[1] = buf;
entry->args[2] = 4096;
entry->status = SUBMIT;SUBMIT

ユーザー空間while (entry->status != DONE)
DONE
do_something_else();return entry->return_code;
カーネル

DONE

アプリケーション
共有メモリ
ステータスをSUBMITへ変更

カーネルスレッド
実⾏

カーネル機能カーネル機能1294

Livio Soares and Michael Stumm. 2010. FlexSC: Flexible System Call Scheduling with Exception-Less System Calls. In 9th USENIX Symposium on Operating
Systems Design and Implementation (OSDI 10).(https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls)

Exception-less interface: syscall page
解決策：システムコールの頻度を減らす
write(fd, buf, 4096);• FlexSC (OSDI 2010)

アプリケーション
ユーザー空間• ユーザー・カーネル空間の間に共有メモリを⽤意 共有メモリ
entry = free_syscall_entry();• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み
カーネルスレッドカーネル/* write syscall */実⾏• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取り
entry->syscall = 1;
カーネル機能カーネル機能カーネル機能を実⾏
entry->num_args = 3;
entry->args[0] = fd;
entry->args[1] = buf;
entry->args[2] = 4096;
entry->status = SUBMIT;SUBMIT

ユーザー空間while (entry->status != DONE)
DONE
do_something_else();return entry->return_code;
カーネル

DONE

アプリケーション
共有メモリ
専⽤カーネルスレッドは SUBMIT 状態を
カーネルスレッド
読み取り、リクエストの処理を開始する
実⾏

カーネル機能カーネル機能1295

Livio Soares and Michael Stumm. 2010. FlexSC: Flexible System Call Scheduling with Exception-Less System Calls. In 9th USENIX Symposium on Operating
Systems Design and Implementation (OSDI 10).(https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls)

Exception-less interface: syscall page
解決策：システムコールの頻度を減らす
write(fd, buf, 4096);• FlexSC (OSDI 2010)

アプリケーション
ユーザー空間• ユーザー・カーネル空間の間に共有メモリを⽤意 共有メモリ
entry = free_syscall_entry();• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み
カーネルスレッドカーネル/* write syscall */実⾏• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取り
entry->syscall = 1;
カーネル機能カーネル機能カーネル機能を実⾏
entry->num_args = 3;
entry->args[0] = fd;
entry->args[1] = buf;
entry->args[2] = 4096;
entry->status = SUBMIT;SUBMIT

ユーザー空間while (entry->status != DONE)
DONE
do_something_else();return entry->return_code;
カーネル

DONE

アプリケーション
共有メモリ
アプリケーションはステータスがカーネルスレッド
DONE になるまで待機
実⾏

カーネル機能カーネル機能1296

Livio Soares and Michael Stumm. 2010. FlexSC: Flexible System Call Scheduling with Exception-Less System Calls. In 9th USENIX Symposium on Operating
Systems Design and Implementation (OSDI 10).(https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls)

Exception-less interface: syscall page
解決策：システムコールの頻度を減らす
write(fd, buf, 4096);• FlexSC (OSDI 2010)

アプリケーション
ユーザー空間• ユーザー・カーネル空間の間に共有メモリを⽤意 共有メモリ
entry = free_syscall_entry();• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み
カーネルスレッドカーネル/* write syscall */実⾏• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取り
entry->syscall = 1;
カーネル機能カーネル機能カーネル機能を実⾏
entry->num_args = 3;
entry->args[0] = fd;
entry->args[1] = buf;
entry->args[2] = 4096;
entry->status = SUBMIT;SUBMIT

ユーザー空間while (entry->status != DONE)
DONE
do_something_else();return entry->return_code;
カーネル

DONE

アプリケーション
共有メモリ
カーネルスレッドは処理が完了し次第
カーネルスレッド
結果をreturn_codeに設定した後実⾏
ステータスをDONEに変更

カーネル機能カーネル機能1297

Livio Soares and Michael Stumm. 2010. FlexSC: Flexible System Call Scheduling with Exception-Less System Calls. In 9th USENIX Symposium on Operating
Systems Design and Implementation (OSDI 10).(https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls)

98

Exception-less interface: syscall page
解決策：システムコールの頻度を減らす
write(fd, buf, 4096);• FlexSC (OSDI 2010)

アプリケーション
ユーザー空間• ユーザー・カーネル空間の間に共有メモリを⽤意 共有メモリ
entry = free_syscall_entry();• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み
カーネルスレッドカーネル/* write syscall */実⾏• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取り
entry->syscall = 1;
カーネル機能カーネル機能カーネル機能を実⾏
entry->num_args = 3;
entry->args[0] = fd;
entry->args[1] = buf;
entry->args[2] = 4096;
entry->status = SUBMIT;SUBMIT

ユーザー空間while (entry->status != DONE)
DONE
do_something_else();return entry->return_code;
カーネル

DONE

アプリケーション
共有メモリ
ポイント：ユーザー空間とカーネルの間のやりとりをカーネルスレッド
共有メモリを通じて⾏うことで実⾏
syscall 命令に伴うコンテキストの切り替えをなくせる

カーネル機能カーネル機能12

Livio Soares and Michael Stumm. 2010. FlexSC: Flexible System Call Scheduling with Exception-Less System Calls. In 9th USENIX Symposium on Operating
Systems Design and Implementation (OSDI 10).(https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls)

ApacheBench throughput (4 cores)
解決策：システムコールの頻度を減らす

Throughput(requests/sec.)

45,000• FlexSC (OSDI2010)
40,000• ユーザー・カーネル空間の間に共有メモリを⽤意
35,000• ユーザー空間プログラムはリクエスト内容を共有メモリ上に書き込み
30,000115% improvement• カーネル内で専⽤のカーネルスレッドが共有リクエストを読み取り
25,000カーネル機能を実⾏
20,00015,00010,000flexscアプリケーション
ユーザー空間
5,000
sync
共有メモリ
0
0
200
400
600
800
1000
カーネルスレッド
カーネルRequest Concurrency
実⾏

カーネル機能カーネル機能

28

99

100

研究紹介
システムコール呼び出しコストについて
ユーザー空間とカーネルの境界をなくす101
システムコールの頻度を減らす• アプリとカーネルの境界をなくす

ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

102
システムコールの頻度を減らす• アプリとカーネルの境界をなくす

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

103
システムコールの頻度を減らす• アプリとカーネルの境界をなくす

具体的には
⼀般的にカーネルに実装されている機能をユーザー空間へ移す
ユーザー空間アプリケーション
TCP/IP スタック
NIC デバイスドライバ

104
システムコールの頻度を減らす• アプリとカーネルの境界をなくす

もしくは、アプリケーションをカーネル空間で動かす
アプリケーションカーネル

TCP/IP スタック
NIC デバイスドライバ

105
システムコールの頻度を減らす• アプリとカーネルの境界をなくす• Unikernels• Mirage (ASPLOS 2013)• OSv (USENIX ATC 2014)• Lupin Linux (EuroSys 2020)• Unikraft (EuroSys 2021)• Unikernel Linux (EuroSys 2023)• ライブラリ OS• VirtuOS (SOSP 2013)• EbbRT (OSDI 2016)• Demikernel (SOSP 2021)• アプリのコードを検証後カーネルで実⾏• Privbox (USENIX ATC 2022)• Userspace bypass (OSDI 2023)

106
システムコールの頻度を減らす• アプリとカーネルの境界をなくす• Unikernels• Mirage (ASPLOS 2013)• OSv (USENIX ATC 2014)• Lupin Linux (EuroSys 2020)• Unikraft (EuroSys 2021)• Unikernel Linux (EuroSys 2023)• ライブラリ OS

仮想マシン
アプリケーションカーネル• VirtuOS (SOSP 2013)• EbbRT (OSDI 2016)• Demikernel (SOSP 2021)

NIC デバイスドライバ• アプリのコードを検証後カーネルで実⾏• Privbox (USENIX ATC 2022)• Userspace bypass (OSDI 2023)

TCP/IP スタック

ホスト（ハイパーバイザー）

アプリケーションはカーネル空間で動く107
システムコールの頻度を減らす• アプリとカーネルの境界をなくす• Unikernels• Mirage (ASPLOS 2013)• OSv (USENIX ATC 2014)• Lupin Linux (EuroSys 2020)• Unikraft (EuroSys 2021)• Unikernel Linux (EuroSys 2023)• ライブラリ OS

仮想マシン
アプリケーションカーネル• VirtuOS (SOSP 2013)• EbbRT (OSDI 2016)• Demikernel (SOSP 2021)

NIC デバイスドライバ• アプリのコードを検証後カーネルで実⾏• Privbox (USENIX ATC 2022)• Userspace bypass (OSDI 2023)

TCP/IP スタック

ホスト（ハイパーバイザー）

アプリケーションはカーネル空間で動く

108
システムコールの頻度を減らす• アプリとカーネルの境界をなくす• Unikernels• Mirage (ASPLOS 2013)• OSv (USENIX ATC 2014)• Lupin Linux (EuroSys 2020)• Unikraft (EuroSys 2021)• Unikernel Linux (EuroSys 2023)• ライブラリ OS

アプリケーション

ユーザー空間• VirtuOS (SOSP 2013)• EbbRT (OSDI 2016)• Demikernel (SOSP 2021)

TCP/IP スタック
NIC デバイスドライバ• アプリのコードを検証後カーネルで実⾏• Privbox (USENIX ATC 2022)• Userspace bypass (OSDI 2023)

OS 機能がユーザー空間で動く

109
システムコールの頻度を減らす• アプリとカーネルの境界をなくす• Unikernels• Mirage (ASPLOS 2013)• OSv (USENIX ATC 2014)• Lupin Linux (EuroSys 2020)• Unikraft (EuroSys 2021)• Unikernel Linux (EuroSys 2023)• ライブラリ OS

アプリケーション

ユーザー空間• VirtuOS (SOSP 2013)• EbbRT (OSDI 2016)• Demikernel (SOSP 2021)

TCP/IP スタック
NIC デバイスドライバ• アプリのコードを検証後カーネルで実⾏• Privbox (USENIX ATC 2022)• Userspace bypass (OSDI 2023)

OS 機能がユーザー空間で動く

110
システムコールの頻度を減らす• アプリとカーネルの境界をなくす• Unikernels• Mirage (ASPLOS 2013)• OSv (USENIX ATC 2014)• Lupin Linux (EuroSys 2020)• Unikraft (EuroSys 2021)• Unikernel Linux (EuroSys 2023)• ライブラリ OS

アプリケーションカーネル• VirtuOS (SOSP 2013)• EbbRT (OSDI 2016)• Demikernel (SOSP 2021)

TCP/IP スタック
NIC デバイスドライバ• アプリのコードを検証後カーネルで実⾏• Privbox (USENIX ATC 2022)• Userspace bypass (OSDI 2023)

アプリケーションはカーネル空間で動く111

Hsuan-Chi Kuo, Dan Williams, Ricardo Koller, and Sibin Mohan. 2020. A Linux in Unikernel Clothing. In Proceedings of the Fifteenth European Conference on
Computer Systems (EuroSys ʼ 20).(https://doi.org/10.1145/3342195.3387526)

システムコールの頻度を減らす• アプリとカーネルの境界をなくす• Unikernels• ライブラリ OS• VirtuOS (SOSP 2013)• EbbRT (OSDI 2016)• Demikernel (SOSP 2021)

0.1

Latency (μs)• Mirage (ASPLOS 2013)• OSv (USENIX ATC 2014)• Lupin Linux (EuroSys 2020)• Unikraft (EuroSys 2021)• Unikernel Linux (EuroSys 2023)

論⽂中グラフより.19.17

null
read
write

0.08
0.06
0.04
0.02
0

mi

lup
lup
cro
ine
ine
vm
-no
km
l

lup

ine

-ge

he
ne

rm
i

ral

tux

os
v

• アプリのコードを検証後カーネルで実⾏
Figure 9. System call latency via lmbench.
• Privbox (USENIX ATC 2022)• Userspace bypass (OSDI 2023)

rumpHsuan-Chi Kuo, Dan Williams, Ricardo Koller, and Sibin Mohan. 2020. A Linux in Unikernel Clothing. In Proceedings of the Fifteenth European Conference on
Computer Systems (EuroSys ʼ 20).(https://doi.org/10.1145/3342195.3387526)

112

システムコールの頻度を減らす• アプリとカーネルの境界をなくす• Mirage (ASPLOS 2013)• OSv (USENIX ATC 2014)• Lupin Linux (EuroSys 2020)• Unikraft (EuroSys 2021)• Unikernel Linux (EuroSys 2023)• ライブラリ OS• VirtuOS (SOSP 2013)• EbbRT (OSDI 2016)• Demikernel (SOSP 2021)

Latency (μs)

• Unikernels

0.1

論⽂中グラフより

0.08

null
read
write

0.06
0.04
0.02
0

• アプリのコードを検証後カーネルで実⾏• Privbox (USENIX ATC 2022)• Userspace bypass (OSDI 2023)

拡⼤

mi

lup
lup
cro
ine
ine
vm
-no
km
l

lup

ine

-ge

Hsuan-Chi Kuo, Dan Williams, Ricardo Koller, and Sibin Mohan. 2020. A Linux in Unikernel Clothing. In Proceedings of the Fifteenth European Conference on
Computer Systems (EuroSys ʼ 20).(https://doi.org/10.1145/3342195.3387526)

113

システムコールの頻度を減らす• アプリとカーネルの境界をなくす• Mirage (ASPLOS 2013)• OSv (USENIX ATC 2014)• Lupin Linux (EuroSys 2020)• Unikraft (EuroSys 2021)• Unikernel Linux (EuroSys 2023)• ライブラリ OS• VirtuOS (SOSP 2013)• EbbRT (OSDI 2016)• Demikernel (SOSP 2021)

Latency (μs)

• Unikernels

0.1

論⽂中グラフより

0.08

null
read
write

0.06
0.04
0.02
0

• アプリのコードを検証後カーネルで実⾏• Privbox (USENIX ATC 2022)• Userspace bypass (OSDI 2023)

拡⼤

mi

lup
lup
cro
ine
ine
vm
-no
km
l

lup

ine

-ge

114
システムコールの頻度を減らす• アプリとカーネルの境界をなくす• Unikernels• Mirage (ASPLOS 2013)• OSv (USENIX ATC 2014)• Lupin Linux (EuroSys 2020)• Unikraft (EuroSys 2021)• Unikernel Linux (EuroSys 2023)• ライブラリ OS• VirtuOS (SOSP 2013)• EbbRT (OSDI 2016)• Demikernel (SOSP 2021)• アプリのコードを検証後カーネルで実⾏• Privbox (USENIX ATC 2022)• Userspace bypass (OSDI 2023)

115
システムコールの頻度を減らす• アプリとカーネルの境界をなくす• Unikernels• Mirage (ASPLOS 2013)• OSv (USENIX ATC 2014)• Lupin Linux (EuroSys 2020)• Unikraft (EuroSys 2021)• Unikernel Linux (EuroSys 2023)• ライブラリ OS• VirtuOS (SOSP 2013)• EbbRT (OSDI 2016)• Demikernel (SOSP 2021)• アプリのコードを検証後カーネルで実⾏• Privbox (USENIX ATC 2022)• Userspace bypass (OSDI 2023)

既存の Linux 実装を使いたい116
システムコールの頻度を減らす• アプリとカーネルの境界をなくす• Unikernels• Mirage (ASPLOS 2013)• OSv (USENIX ATC 2014)• Lupin Linux (EuroSys 2020)• Unikraft (EuroSys 2021)• Unikernel Linux (EuroSys 2023)• ライブラリ OS• VirtuOS (SOSP 2013)• EbbRT (OSDI 2016)• Demikernel (SOSP 2021)• アプリのコードを検証後カーネルで実⾏• Privbox (USENIX ATC 2022)• Userspace bypass (OSDI 2023)

既存の Linux 実装を使いたい
開発を簡単にしたい
開発を簡単にしたい117
システムコールの頻度を減らす• アプリとカーネルの境界をなくす• Unikernels• Mirage (ASPLOS 2013)• OSv (USENIX ATC 2014)• Lupin Linux (EuroSys 2020)• Unikraft (EuroSys 2021)• Unikernel Linux (EuroSys 2023)

既存の Linux 実装を使いたい
開発を簡単にしたい• ライブラリ OS• VirtuOS (SOSP 2013)• EbbRT (OSDI 2016)• Demikernel (SOSP 2021)

開発を簡単にしたい
I/O デバイスの差異を吸収したい• アプリのコードを検証後カーネルで実⾏• Privbox (USENIX ATC 2022)• Userspace bypass (OSDI 2023)

118
システムコールの頻度を減らす• アプリとカーネルの境界をなくす• Unikernels• Mirage (ASPLOS 2013)• OSv (USENIX ATC 2014)• Lupin Linux (EuroSys 2020)• Unikraft (EuroSys 2021)• Unikernel Linux (EuroSys 2023)• ライブラリ OS• VirtuOS (SOSP 2013)• EbbRT (OSDI 2016)• Demikernel (SOSP 2021)

既存の Linux 実装を使いたい
開発を簡単にしたい
開発を簡単にしたい
I/O デバイスの差異を吸収したい• アプリのコードを検証後カーネルで実⾏• Privbox (USENIX ATC 2022)
既存のカーネル機能が使える• Userspace bypass (OSDI 2023)

119

研究紹介
パケット I/O 性能について
基本的な仕組みの説明

120
通信関連のシステムソフトウェア
データセンター内のサーバー
サービス利⽤者の端末

NIC

通信関連ソフトウェア
サービス提供側
アプリケーション
ユーザー空間カーネル

TCP/IP スタック
NIC デバイスドライバ

10 ~ Gbps
インターネット
データセンター
⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい121
通信関連のシステムソフトウェア
データセンター内のサーバー
サービス利⽤者の端末

NIC

通信関連ソフトウェア
サービス提供側
アプリケーション
ユーザー空間カーネル

TCP/IP スタック
NIC デバイスドライバ

10 ~ Gbps
既存の仕組みだと⽐較的処理が軽い UDP でもインターネット
⼩さいパケットを⾼速にやりとりできなかった
データセンター
⼤量のリクエストが集まってくる
サービス提供側はなるべく短い応答時間でサービスを提供したい122
NIC と通信関連プログラムの構成
ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

123
NIC と通信関連プログラムの構成
ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

NIC レジスタ

DMA

124
NIC と通信関連プログラムの構成
ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ

DMA

125
NIC と通信関連プログラムの構成
ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ• デスクリプタリング位置
DMA

126
NIC と通信関連プログラムの構成
ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ

デスクリプタリング• デスクリプタリング位置
ソフトウェアが任意の位置（メモリアドレス）に配置できる

DMA
送信⽤

受信⽤

127
NIC と通信関連プログラムの構成
ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ

デスクリプタリング• デスクリプタリング位置
ソフトウェアが任意の位置（メモリアドレス）に配置できる

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

128
NIC と通信関連プログラムの構成
ユーザー空間カーネル

アプリケーション

デスクリプタが保持する内容

TCP/IP スタック

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ

デスクリプタリング• デスクリプタリング位置
ソフトウェアが任意の位置（メモリアドレス）に配置できる

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

129
NIC と通信関連プログラムの構成
ユーザー空間カーネル

アプリケーション

デスクリプタが保持する内容

TCP/IP スタック

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ

デスクリプタリング• デスクリプタリング位置• 転送リング head
• 転送リング tail

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

130
NIC と通信関連プログラムの構成
ユーザー空間カーネル

アプリケーション

デスクリプタが保持する内容

TCP/IP スタック

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

131
NIC と通信関連プログラムの構成
ユーザー空間カーネル

デスクリプタが保持する内容

TCP/IP スタック

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

アプリケーション

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

132
NIC と通信関連プログラムの構成
ユーザー空間カーネル

デスクリプタが保持する内容

TCP/IP スタック

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

アプリケーション

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

133

メモリ上の概観

ユーザー空間カーネル

アプリケーション

NIC デバイスドライバ

NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

メモリ領域(DRAM)NIC と通信関連プログラムの構成

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造...
(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

メモリ上の概観

134

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ
•
•
•
•
•

...

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

メモリ上の概観

135

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング...

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ• その他：状態保持⽤フラグ
ソフトウェアはメモリを通じて
NIC のレジスタにアクセス可能

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

メモリ上の概観

136

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ
•
•
•
•
•

...

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

メモリ上の概観

137

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ
•
•
•
•
•

...

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

メモリ上の概観

138

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ
•
•
•
•
•

...

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

メモリ上の概観

139

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ
•
•
•
•
•

...

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

メモリ上の概観

140

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ
•
•
•
•
•

...

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

メモリ上の概観

141

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ
•
•
•
•
•

...

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

メモリ上の概観

142

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ
•
•
•
•
•

...

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NICのハードウェア仕様中で定義される)
ソフトウェア（デバドラ）は初期設定
として、まずデスクリプタリング⽤に
連続的なメモリ領域を確保
DMA

送信⽤

受信⽤

メモリ上の概観

143

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ...
• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ
•
•
•
•
•

...

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造...
(NICのハードウェア仕様中で定義される)
ソフトウェア（デバドラ）は初期設定
として、まずデスクリプタリング⽤に
連続的なメモリ領域を確保
DMA

送信⽤

受信⽤

メモリ上の概観

144

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ...
• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ
•
•
•
•
•

...

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造...
(NIC
NIC のハードウェア仕様中で定義される)レジスタのデスクリプタリング位置を保持するフィールドへ確保した連続的なメモリ領域のDMA
先頭アドレスを代⼊する

送信⽤

受信⽤

メモリ上の概観

145

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ...
• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ
•
•
•
•
•

...

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造...
(NIC
NIC のハードウェア仕様中で定義される)レジスタのデスクリプタリング位置を保持するフィールドへ確保した連続的なメモリ領域のDMA
先頭アドレスを代⼊する

送信⽤

受信⽤

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観

146

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング...

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ...
• その他：状態保持⽤フラグ
デスクリプタ[0]デスクリプタ[1]デスクリプタ[2]
NIC の送受信キューを表現するデータ構造...
(NICのハードウェア仕様中で定義される)
これで、確保した連続的なメモリ領域がデスクリプタの配列として
DMA
NIC から認識される

送信⽤

受信⽤

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観

147

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング...

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ...
• その他：状態保持⽤フラグ
デスクリプタ[0]デスクリプタ[1]デスクリプタ[2]
NIC の送受信キューを表現するデータ構造...
(NICのハードウェア仕様中で定義される)
これで、確保した連続的なメモリ領域がデスクリプタの配列として
DMA
NIC から認識される

送信⽤

受信⽤

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観

148

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング...

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ...
• その他：状態保持⽤フラグ
デスクリプタ[0]デスクリプタ[1]デスクリプタ[2]
NIC の送受信キューを表現するデータ構造...
(NIC
NIC のハードウェア仕様中で定義される)レジスタのうち、リングの head, tail を保持する
レジスタは、デスクリプタ配列のDMA
インデックスを保持する

送信⽤

受信⽤

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観

149

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング...

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ...
• その他：状態保持⽤フラグ
デスクリプタ[0]デスクリプタ[1]デスクリプタ[2]
NIC の送受信キューを表現するデータ構造...
(NIC
NIC のハードウェア仕様中で定義される)レジスタのうち、リングの head, tail を保持する
レジスタは、デスクリプタ配列のDMA
インデックスを保持する

送信⽤

受信⽤

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観

150

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail...

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ...
• その他：状態保持⽤フラグ
デスクリプタ[0]デスクリプタ[1]

受信⽤パケットバッファ

デスクリプタリング

デスクリプタ[2]
NIC の送受信キューを表現するデータ構造...
(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観

151

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

送信⽤

受信⽤

...

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ...
• その他：状態保持⽤フラグ
デスクリプタ[0]デスクリプタ[1]デスクリプタ[2]
NIC の送受信キューを表現するデータ構造...
(NIC のハードウェア仕様中で定義される)
次に、ソフトウェア（デバドラ）はパケットバッファ⽤メモリを確保する
DMA

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観

152

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail...

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ...
• その他：状態保持⽤フラグ
デスクリプタ[0]デスクリプタ[1]

受信⽤パケットバッファ

デスクリプタリング

デスクリプタ[2]
NIC の送受信キューを表現するデータ構造...
(NIC のハードウェア仕様中で定義される)
パケットバッファ
DMA

送信⽤

受信⽤

パケットバッファ...

パケットバッファスペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観

153

デスクリプタリング位置...

NIC と通信関連プログラムの構成転送リング head
転送リング tail

ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail...

デスクリプタが保持する内容
受信リング head
• パケットバッファのメモリアドレス
受信リング tail• パケットのサイズ...
• その他：状態保持⽤フラグ
デスクリプタ[0]デスクリプタ[1]

受信⽤パケットバッファ

デスクリプタリング

デスクリプタ[2]
NIC の送受信キューを表現するデータ構造...
(NIC のハードウェア仕様中で定義される)
パケットバッファ
DMA

送信⽤

受信⽤

パケットバッファ...

パケットバッファ154

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head
ソフトウェア（デバドラ）はデスクリプタのフィールドにパケットバッファのアドレスを書き込むことで NIC への紐付けを⾏う

転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

155

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head
ソフトウェア（デバドラ）はデスクリプタのフィールドにパケットバッファのアドレスを書き込むことで NIC への紐付けを⾏う

転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

156

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head
ソフトウェア（デバドラ）はデスクリプタのフィールドにパケットバッファのアドレスを書き込むことで NIC への紐付けを⾏う

転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

157

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head
ソフトウェア（デバドラ）はデスクリプタのフィールドにパケットバッファのアドレスを書き込むことで NIC への紐付けを⾏う

転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

158

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head
ソフトウェア（デバドラ）はデスクリプタのフィールドにパケットバッファのアドレスを書き込むことで NIC への紐付けを⾏う

転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

159

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head
ソフトウェア（デバドラ）はデスクリプタのフィールドにパケットバッファのアドレスを書き込むことで NIC への紐付けを⾏う

転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

160

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head
ソフトウェア（デバドラ）はデスクリプタのフィールドにパケットバッファのアドレスを書き込むことで NIC への紐付けを⾏う

転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

161

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head
ソフトウェア（デバドラ）はデスクリプタのフィールドにパケットバッファのアドレスを書き込むことで NIC への紐付けを⾏う

転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

162

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head
転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

163

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head
転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

新規パケットの到着

164

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head
受信したデータはデスクリプタ経由で紐づけられたパケットバッファへ書き込まれる転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

新規パケットの到着

165

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head
受信したデータはデスクリプタ経由で紐づけられたパケットバッファへ書き込まれる転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

新規パケットの到着

166

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head
NIC は受信したパケットのサイズを紐付けを⾏っているデスクリプタのフィールドに反映する

転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

新規パケットの到着

167

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head
NIC は受信したパケットのサイズを紐付けを⾏っているデスクリプタのフィールドに反映する

転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

新規パケットの到着

168

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head
NIC は受信したパケットのサイズを紐付けを⾏っているデスクリプタのフィールドに反映する

転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

新規パケットの到着

169

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head

その後、NIC によって、レジスタの受信リング head の値が更新される

転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタが保持する内容

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

新規パケットの到着

170

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head

その後、NIC によって、レジスタの受信リング head の値が更新される

転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

デスクリプタ[0]NIC デバイスドライバ

NIC レジスタ. . .

•
•
•
•
•

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

デスクリプタが保持する内容

受信⽤パケットバッファ

デスクリプタリング( 受信リング head ではなく、状態保持⽤フラグに受信状況を設定する
NIC もあります )NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

新規パケットの到着

171

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置...

NIC 転送リングと通信関連プログラムの構成
head

その後、NIC によって、レジスタの受信リング head の値が更新される

転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
ソフトウェアは NIC レジスタの受信リング head を読み取り、
デスクリプタ[0, 1] に紐づくバッファにデータが書き込まれたことを検知する
NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

新規パケットの到着

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置

172

...

NIC 転送リングと通信関連プログラムの構成
head
転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

ソフトウェアは受信パケットを受け取った後レジスタの受信リング tail の値を更新して受信パケットを消費したことを NIC へ通知する
デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
ソフトウェアは NIC レジスタの受信リング head を読み取り、
デスクリプタ[0, 1] に紐づくバッファにデータが書き込まれたことを検知する
NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

新規パケットの到着

スペースの都合で転送⽤デスクリプタは省略しています メモリ上の概観
デスクリプタリング位置

173

...

NIC 転送リングと通信関連プログラムの構成
head
転送リング tail...

アプリケーション
ユーザー空間受信リング head
受信リング tail

カーネル

...

TCP/IP スタック

デスクリプタ[0]NIC デバイスドライバ

デスクリプタ[1]ソフトウェア(デバドラ)はメモリを通じてアクセス
デスクリプタ[2]
NIC レジスタ. . .

•
•
•
•
•

デスクリプタリング位置
パケットバッファ
転送リング head
パケットバッファ
転送リング
tail
...
受信リング head
受信リング
tail
パケットバッファ

受信⽤パケットバッファ

デスクリプタリング

head がデスクリプタ配列の最後まで進められたら head はデスクリプタ[0] へ戻る(リングバッファとして機能する)
デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
ソフトウェアは NIC レジスタの受信リング head を読み取り、
デスクリプタ[0, 1] に紐づくバッファにデータが書き込まれたことを検知する
NIC の送受信キューを表現するデータ構造(NIC のハードウェア仕様中で定義される)
DMA

送信⽤

受信⽤

新規パケットの到着

174
NIC と通信関連プログラムの構成
ユーザー空間カーネル

デスクリプタが保持する内容

TCP/IP スタック

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

アプリケーション

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

175（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

デスクリプタが保持する内容

TCP/IP スタック

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

アプリケーション

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着176（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

デスクリプタが保持する内容

TCP/IP スタック

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

アプリケーション

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着177（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

デスクリプタが保持する内容

TCP/IP スタック

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

アプリケーション

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

178（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

デスクリプタが保持する内容

TCP/IP スタック

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

アプリケーション

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

179（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

デスクリプタが保持する内容

TCP/IP スタック

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

アプリケーション

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

180（ある程度）⼀般的な受信処理の流れ
ユーザー空間デスクリプタが保持する内容

TCP/IP スタック

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

ー
ハ

ド

カーネル

アプリケーションェウ

NIC デバイスドライバ
NIC からパケット受信を通知する
ハードウェア割り込みが送られる

ア

受信⽤パケットバッファ
割

み

込

り

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

181（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

アプリケーション

デスクリプタが保持する内容

TCP/IP スタック

• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

NIC デバイスドライバ
割り込みハンドラ
受信⽤パケットバッファ
ソフトウェア(デバドラ)は

NIC からパケット受信を通知する
ハードウェア割り込みが送られる

メモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタリング

ハードウェア仕様として、事前に登録された
ハードウェア割り込みハンドラが起動される

DMA
送信⽤

受信⽤

新規パケットの到着

182（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーション

TCP/IP スタック
受信処理⽤カーネルスレッド
カーネル
NIC デバイスドライバ
割り込みハンドラ
受信⽤パケットバッファ
ソフトウェア(デバドラ)はデスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

メモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタリング

ハードウェア仕様として、事前に登録された
ハードウェア割り込みハンドラが起動される

DMA
送信⽤

受信⽤

新規パケットの到着

183（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーション

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック
受信処理⽤カーネルスレッド
カーネル
NIC デバイスドライバ Kick
ハードウェア割り込みハンドラは割り込みハンドラ
受信⽤パケットバッファ 受信パケット処理⽤のカーネルスレッドを起動
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタリング

ハードウェア仕様として、事前に登録された
ハードウェア割り込みハンドラが起動される

DMA
送信⽤

受信⽤

新規パケットの到着

184（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

アプリケーション
TCP/IP スタック
受信処理⽤カーネルスレッド
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
ハードウェア割り込みハンドラは受信パケット処理⽤のカーネルスレッドを起動
このカーネルスレッドがパケットバッファ
からデータを取り出し TCP/IP 処理を実⾏

DMA
送信⽤

受信⽤

新規パケットの到着

185（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

アプリケーション
ソケット
キュー

TCP/IP スタック
受信処理⽤カーネルスレッド
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
ハードウェア割り込みハンドラは受信パケット処理⽤のカーネルスレッドを起動
このカーネルスレッドがパケットバッファ
からデータを取り出し TCP/IP 処理を実⾏

DMA
送信⽤

受信⽤

新規パケットの到着

186（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

アプリケーション
ソケット
キュー

TCP/IP スタック
受信処理⽤カーネルスレッド
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
ハードウェア割り込みハンドラは受信パケット処理⽤のカーネルスレッドを起動
このカーネルスレッドがパケットバッファ
からデータを取り出し TCP/IP 処理を実⾏＋ソケットのキューへデータを紐付け
DMA

送信⽤

受信⽤

新規パケットの到着

187（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

アプリケーション
ソケット
キュー

TCP/IP スタック
受信処理⽤カーネルスレッド
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
ハードウェア割り込みハンドラは受信パケット処理⽤のカーネルスレッドを起動
受信⽤パケットバッファと NIC の紐付きを解除＋新しいバッファを紐づける

DMA
送信⽤

受信⽤

新規パケットの到着

188（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

アプリケーション
ソケット
キュー

TCP/IP スタック
受信処理⽤カーネルスレッド
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
ハードウェア割り込みハンドラは受信パケット処理⽤のカーネルスレッドを起動
受信⽤パケットバッファと NIC の紐付きを解除＋新しいバッファを紐づける

DMA
送信⽤

受信⽤

新規パケットの到着

189（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

アプリケーション
ソケット
キュー

TCP/IP スタック
受信処理⽤カーネルスレッド
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
ハードウェア割り込みハンドラは受信パケット処理⽤のカーネルスレッドを起動
受信⽤パケットバッファと NIC の紐付きを解除＋新しいバッファを紐づける

DMA
送信⽤

受信⽤

新規パケットの到着

190（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

アプリケーション
ソケット
キュー

TCP/IP スタック
受信処理⽤カーネルスレッド
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
ハードウェア割り込みハンドラは受信パケット処理⽤のカーネルスレッドを起動
受信⽤パケットバッファと NIC の紐付きを解除＋新しいバッファを紐づける

DMA
送信⽤

受信⽤

新規パケットの到着

191（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

アプリケーション
ソケット
キュー

TCP/IP スタック
受信処理⽤カーネルスレッド
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
ハードウェア割り込みハンドラは受信パケット処理⽤のカーネルスレッドを起動
受信リングの tail を進める

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

192（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

アプリケーション
ソケット
キュー

TCP/IP スタック
受信処理⽤カーネルスレッド
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
ハードウェア割り込みハンドラは受信パケット処理⽤のカーネルスレッドを起動
受信リングの tail を進める

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

193（ある程度）⼀般的な受信処理の流れ
ユーザー空間カーネル

アプリケーション
ソケット
キュー

TCP/IP スタック
受信処理⽤カーネルスレッド
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
ハードウェア割り込みハンドラは受信パケット処理⽤のカーネルスレッドを起動
パケットは受信リングの tail より先へは
head を進めないので新規パケット受信のためには tail の更新が必要
DMA

送信⽤

受信⽤

新規パケットの到着

194（ある程度）⼀般的な受信処理の流れ
read(), select(), poll() 等でブロックされていれば、ブロックが解除される

ユーザー空間カーネル

アプリケーション
ソケット
キュー

TCP/IP スタック
受信処理⽤カーネルスレッド
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

Kick

受信⽤パケットバッファ• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
受信パケット処理⽤のカーネルスレッドがアプリケーションスレッドへ通知を送る

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

195（ある程度）⼀般的な受信処理の流れ
read(), select(), poll() 等でブロックされていれば、ブロックが解除される

ユーザー空間カーネル

アプリケーションソケット
キュー• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタが保持する内容

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

196（ある程度）⼀般的な受信処理の流れ
read(), select(), poll() 等でブロックされていれば、ブロックが解除される

ユーザー空間カーネル

アプリケーションソケット
キュー• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタが保持する内容

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着197（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット
キュー

カーネル

NIC デバイスドライバ

NIC レジスタ•••••• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

受信⽤パケットバッファ

アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

198（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット syscall
キュー

カーネル

TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

199（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット
キュー

カーネル

NIC デバイスドライバ

NIC レジスタ•••••• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

受信⽤パケットバッファ

アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

200（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット メモリコピー
キュー

カーネル

TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

201（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット
キュー

カーネル

NIC デバイスドライバ

NIC レジスタ•••••• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

受信⽤パケットバッファ

アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着202（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット
キュー

カーネル

NIC デバイスドライバ

NIC レジスタ•••••• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

受信⽤パケットバッファ

アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

203（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット
キュー

カーネル

NIC デバイスドライバ

NIC レジスタ•••••• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

受信⽤パケットバッファ

アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

204（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット
キュー

カーネル

NIC デバイスドライバ

NIC レジスタ•••••• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

受信⽤パケットバッファ

アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

205（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット syscall
キュー

カーネル

TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

206（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット
キュー

カーネル

NIC デバイスドライバ

NIC レジスタ•••••• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

受信⽤パケットバッファ

アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

207（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット
キュー

カーネル

NIC デバイスドライバ

NIC レジスタ•••••• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

受信⽤パケットバッファ

アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

208（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット メモリコピー
キュー

カーネル

TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

209（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット
キュー

カーネル

NIC デバイスドライバ

NIC レジスタ•••••• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

受信⽤パケットバッファ

アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

210（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット
キュー

カーネル

NIC デバイスドライバ

NIC レジスタ•••••• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

受信⽤パケットバッファ

アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

211（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット
キュー

カーネル

NIC デバイスドライバ

NIC レジスタ•••••• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

受信⽤パケットバッファ

アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

212（ある程度）⼀般的な受信処理の流れ
ユーザー空間アプリケーションread(), recvmsg(), etc. ソケット
キュー

カーネル

NIC デバイスドライバ

NIC レジスタ•••••• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

受信⽤パケットバッファ

アプリケーションはシステムコールを通じてソケットのキューへ紐づけられたデータを
ユーザー空間へコピーしてもらう(read(), recvmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

213（ある程度）⼀般的な送信処理の流れ
ユーザー空間カーネル

アプリケーション
ソケット
キュー

NIC デバイスドライバ

NIC レジスタ•••••• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

受信⽤パケットバッファ

アプリケーションはシステムコールを通じてデータの送信をカーネルへリクエストする(write(), sendmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

214
（ある程度）⼀般的な送信処理の流れ
ユーザー空間アプリケーション

write(), sendmsg(), etc. ソケット syscall
キュー

カーネル

TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

アプリケーションはシステムコールを通じてデータの送信をカーネルへリクエストする(write(), sendmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

215
（ある程度）⼀般的な送信処理の流れ
ユーザー空間アプリケーション

write(), sendmsg(), etc. ソケット
キュー

カーネル

NIC デバイスドライバ

NIC レジスタ•••••• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

受信⽤パケットバッファ

アプリケーションはシステムコールを通じてデータの送信をカーネルへリクエストする(write(), sendmsg() 等のシステムコールを利⽤)

デスクリプタリング

DMA
送信⽤

受信⽤

216
（ある程度）⼀般的な送信処理の流れ
ユーザー空間アプリケーション

write(), sendmsg(), etc. ソケット
キュー

カーネル

NIC デバイスドライバ

NIC レジスタ•••••• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ

TCP/IP スタック

ソフトウェア(デバドラ)はメモリを通じてアクセス

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタが保持する内容

受信⽤パケットバッファ

カーネルは送信⽤パケットバッファを確保

デスクリプタリング

DMA
送信⽤

受信⽤

217
（ある程度）⼀般的な送信処理の流れ
ユーザー空間アプリケーション

write(), sendmsg(), etc. ソケット
キュー

カーネル

TCP/IP スタック

送信⽤パケットバッファ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
カーネルは送信⽤パケットバッファを確保

デスクリプタリング

DMA
送信⽤

受信⽤

218
（ある程度）⼀般的な送信処理の流れ
ユーザー空間アプリケーション

write(), sendmsg(), etc. ソケット メモリコピー
キュー

カーネル

TCP/IP スタック

送信⽤パケットバッファ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
ユーザー空間からデータをカーネル空間で確保した送信⽤パケットバッファへコピー

デスクリプタリング

DMA
送信⽤

受信⽤

219
（ある程度）⼀般的な送信処理の流れ
ユーザー空間アプリケーション

write(), sendmsg(), etc. ソケット
キュー

カーネル

TCP/IP スタック

送信⽤パケットバッファ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
ユーザー空間からデータをカーネル空間で確保した送信⽤パケットバッファへコピー

デスクリプタリング

DMA
送信⽤

受信⽤

220
（ある程度）⼀般的な送信処理の流れ
ユーザー空間アプリケーション

write(), sendmsg(), etc. ソケット
キュー

カーネル

TCP/IP スタック

送信⽤パケットバッファ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
TCP/IP スタックの処理を実⾏（ヘッダの付与）

デスクリプタリング

DMA
送信⽤

受信⽤

221
（ある程度）⼀般的な送信処理の流れ
ユーザー空間アプリケーション

write(), sendmsg(), etc. ソケット
キュー

カーネル

TCP/IP スタック

送信⽤パケットバッファ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
転送⽤デスクリプタリングを通して送信⽤パケットバッファを NIC へ紐付け

デスクリプタリング

DMA
送信⽤

受信⽤

222
（ある程度）⼀般的な送信処理の流れ
ユーザー空間アプリケーション

write(), sendmsg(), etc. ソケット
キュー

カーネル

TCP/IP スタック

送信⽤パケットバッファ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
転送⽤デスクリプタリングを通して送信⽤パケットバッファを NIC へ紐付け

デスクリプタリング

DMA
送信⽤

受信⽤

223
（ある程度）⼀般的な送信処理の流れ
ユーザー空間アプリケーション

write(), sendmsg(), etc. ソケット
キュー

カーネル

TCP/IP スタック

送信⽤パケットバッファ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
転送⽤デスクリプタリングを通して送信⽤パケットバッファを NIC へ紐付け

デスクリプタリング

DMA
送信⽤

受信⽤

224
（ある程度）⼀般的な送信処理の流れ
ユーザー空間アプリケーション

write(), sendmsg(), etc. ソケット
キュー

カーネル

TCP/IP スタック

送信⽤パケットバッファ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
NIC レジスタの転送リングの tail の値を更新

デスクリプタリング

DMA
送信⽤

受信⽤

225
（ある程度）⼀般的な送信処理の流れ
ユーザー空間アプリケーション

write(), sendmsg(), etc. ソケット
キュー

カーネル

TCP/IP スタック

送信⽤パケットバッファ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
NIC レジスタの転送リングの tail の値を更新

デスクリプタリング

DMA
送信⽤

受信⽤

226
（ある程度）⼀般的な送信処理の流れ
ユーザー空間アプリケーション

write(), sendmsg(), etc. ソケット
キュー

カーネル

TCP/IP スタック

送信⽤パケットバッファ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
NIC レジスタの転送リングの tail の値を更新
これをきっかけに NIC から
パケットが転送される

デスクリプタリング

DMA
送信⽤

受信⽤

パケットの転送227（ある程度）⼀般的な送信処理の流れ
ユーザー空間アプリケーション

write(), sendmsg(), etc. ソケット
キュー

カーネル

TCP/IP スタック

送信⽤パケットバッファ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
NIC レジスタの転送リングの tail の値を更新
これをきっかけに NIC から
パケットが転送される
転送完了後、
NIC が転送リングの head を進める
DMA

送信⽤

受信⽤

パケットの転送228（ある程度）⼀般的な送信処理の流れ
ユーザー空間アプリケーション

write(), sendmsg(), etc. ソケット
キュー

カーネル

TCP/IP スタック

送信⽤パケットバッファ

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

デスクリプタが保持する内容• パケットバッファのメモリアドレス• パケットのサイズ• その他：状態保持⽤フラグ
NIC レジスタの転送リングの tail の値を更新
これをきっかけに NIC から
パケットが転送される
転送完了後、
NIC が転送リングの head を進める
DMA

送信⽤

受信⽤

パケットの転送229

研究紹介
パケット I/O 性能について
カーネルをバイパスするパケット I/O フレームワーク

230

Luigi Rizzo. 2012. Netmap: A Novel Framework for Fast Packet I/O. In 2012 USENIX Annual Technical Conference (USENIX ATC 12), 101112.(https://www.usenix.org/conference/atc12/technical-sessions/presentation/rizzo)

パケット I/O フレームワーク

on costs almost
negligible:
a packet generator• DPDK(2010)
reams pre-generated packets, and a packet re• netmap (USENIX ATC 2012)hich just counts incoming packets.

est equipment• 0.9 GHz で 10 Gbps NIC のe run mostof our experiments on Mpps）
systems
ラインレート（14.88
d with an
i7-870 4-core CPU at 2.93 GHzで送信できるHz with turbo-boost), memory running at
Hz, and a dual port 10 Gbit/s card based on the
599 NIC. The numbers reported in this paper
the netmap version in FreeBSD HEAD/amd64

Tx Rate (Mpps)• カーネル（の⼤部分）をバイパスしてユーザー空間から NIC の
I/O を実⾏できるようにする
16
14
12
10
8
6
4
2
0

netmap on 4 coresnetmap on 2 coresnetmap on 1 core
Linux/pktgen
FreeBSD/netsend

0

0.5

1
1.5
2
Clock speed (GHz)

2.5

3

231

Luigi Rizzo. 2012. Netmap: A Novel Framework for Fast Packet I/O. In 2012 USENIX Annual Technical Conference (USENIX ATC 12), 101112.(https://www.usenix.org/conference/atc12/technical-sessions/presentation/rizzo)

パケット I/O フレームワーク

on costs almost
negligible:
a packet generator• DPDK(2010)
reams pre-generated packets, and a packet re• netmap (USENIX ATC 2012)hich just counts incoming packets.

est equipment• 0.9 GHz で 10 Gbps NIC のe run mostof our experiments on Mpps）
systems
ラインレート（14.88
d with an
i7-870 4-core CPU at 2.93 GHzで送信できるHz with turbo-boost), memory running at
Hz, and a dual port 10 Gbit/s card based on the
599 NIC. The numbers reported in this paper
the netmap version in FreeBSD HEAD/amd64

Tx Rate (Mpps)• カーネル（の⼤部分）をバイパスしてユーザー空間から NIC の
I/O を実⾏できるようにする
16
14
12
10
8
6
4
2
0

netmap on 4 coresnetmap on 2 coresnetmap on 1 core
Linux/pktgen
FreeBSD/netsend

0

0.5

1
1.5
2
Clock speed (GHz)

2.5

3

232
DPDK の場合
ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

233
DPDK の場合
ユーザー空間カーネル

アプリケーション

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

カーネルの TCP/IP スタックは経由しない

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

234
DPDK の場合
ユーザー空間アプリケーション

カーネルの TCP/IP スタックは経由しない
デバイスドライバをユーザー空間で実⾏

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

235
DPDK の場合
ユーザー空間アプリケーション

カーネルの TCP/IP スタックは経由しない
デバイスドライバをユーザー空間で実⾏

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

NIC に紐づいたパケットバッファもユーザー空間に配置

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

236
DPDK の場合
ユーザー空間アプリケーション

デバイスドライバをユーザー空間で実⾏

DPDK APINIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

カーネルの TCP/IP スタックは経由しない

NIC に紐づいたパケットバッファもユーザー空間に配置

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

237
DPDK の場合：受信パケットの検知
ユーザー空間アプリケーション
DPDK APINIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

238
DPDK の場合：受信パケットの検知
ユーザー空間アプリケーション
DPDK API

API を通してアプリケーションのループの中で、受信リングの head の値を監視

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

239
DPDK の場合：受信パケットの検知
ユーザー空間アプリケーション
DPDK API

API を通してアプリケーションのループの中で、受信リングの head の値を監視

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

240
DPDK の場合：受信パケットの検知
ユーザー空間アプリケーション
DPDK API

API を通してアプリケーションのループの中で、受信リングの head の値を監視

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

241
DPDK の場合：受信パケットの検知
ユーザー空間アプリケーション
DPDK API

API を通してアプリケーションのループの中で、受信リングの head の値を監視
head が動いたことを確認

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ
パケットの受信を検知
デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

242
DPDK の場合：受信パケットの読み込み
ユーザー空間アプリケーション
DPDK API

受信⽤パケットバッファは
ユーザー空間にあり、受信したデータは検知された段階で既にアプリケーションから⾒えている

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

243
DPDK の場合：受信パケットの読み込み
ユーザー空間アプリケーション
DPDK APINIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

受信⽤パケットバッファは
ユーザー空間にあり、受信したデータは検知された段階で既にアプリケーションから⾒えているなので、読み込みのために追加の作業はなし

デスクリプタリング

DMA
送信⽤

受信⽤

新規パケットの到着

244
DPDK の場合：受信リング tail の更新
ユーザー空間アプリケーション
DPDK APINIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

受信⽤パケットバッファは
ユーザー空間にあり、受信したデータは検知された段階で既にアプリケーションから⾒えているなので、読み込みのために追加の作業はなし
新しいパケットを受け取れるように別のバッファを紐づけて、tail を進める

DMA
送信⽤

受信⽤

新規パケットの到着

245
DPDK の場合：受信リング tail の更新
ユーザー空間アプリケーション
DPDK APINIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

受信⽤パケットバッファは
ユーザー空間にあり、受信したデータは検知された段階で既にアプリケーションから⾒えているなので、読み込みのために追加の作業はなし
新しいパケットを受け取れるように別のバッファを紐づけて、tail を進める

DMA
送信⽤

受信⽤

新規パケットの到着

246
DPDK の場合
あとは、アプリが好きなように受信したデータを消費できる

ユーザー空間アプリケーション
DPDK APINIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

受信⽤パケットバッファは
ユーザー空間にあり、受信したデータは検知された段階で既にアプリケーションから⾒えているなので、読み込みのために追加の作業はなし
新しいパケットを受け取れるように別のバッファを紐づけて、tail を進める

DMA
送信⽤

受信⽤

新規パケットの到着

247
DPDK の場合：転送
ユーザー空間アプリケーション
DPDK APINIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

248
DPDK の場合：転送
ユーザー空間アプリケーション

DPDK は送信⽤パケットバッファをユーザー空間に予め確保

DPDK API
送信⽤パケットバッファ

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

249
DPDK の場合：転送
ユーザー空間アプリケーション
DPDK API
送信⽤パケットバッファ

DPDK は送信⽤パケットバッファをユーザー空間に予め確保
アプリケーションは確保された送信⽤パケットバッファへ直接データを書き込む

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

250
DPDK の場合：転送
ユーザー空間アプリケーション
DPDK API
送信⽤パケットバッファ

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

DPDK は送信⽤パケットバッファをユーザー空間に予め確保
アプリケーションは確保された送信⽤パケットバッファへ直接データを書き込む
DPDK は NIC のデスクリプタリングに
送信⽤パケットバッファを紐付けデスクリプタリング

DMA
送信⽤

受信⽤

251
DPDK の場合：転送
ユーザー空間アプリケーション
DPDK API
送信⽤パケットバッファ

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

DPDK は送信⽤パケットバッファをユーザー空間に予め確保
アプリケーションは確保された送信⽤パケットバッファへ直接データを書き込む
DPDK は NIC のデスクリプタリングに
送信⽤パケットバッファを紐付け
その後、転送リングの tail を更新

デスクリプタリング

DMA
送信⽤

受信⽤

252
DPDK の場合：転送
ユーザー空間アプリケーション
DPDK API
送信⽤パケットバッファ

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

DPDK は送信⽤パケットバッファをユーザー空間に予め確保
アプリケーションは確保された送信⽤パケットバッファへ直接データを書き込む
DPDK は NIC のデスクリプタリングに
送信⽤パケットバッファを紐付け
その後、転送リングの tail を更新

デスクリプタリング

これをきっかけにパケットが NIC から
転送される
DMA

送信⽤

受信⽤

パケットの転送253
DPDK の場合：削減できるコスト• 受信において、ハードウェア割り込みを起点としたカーネルス
レッドの起動に伴うスケジューリング
• 受信において、ユーザー空間プロセスへの新規データの通知に伴うスケジューリング
• プロトコルスタック内の処理• システムコール呼び出し• ユーザー空間とカーネルの間での送受信に伴うメモリコピー

254
パケット I/O フレームワークの⽤途
ユーザー空間アプリケーション
DPDK API

Network Function Virtualization (NFV)
汎⽤的なサーバーでネットワーク機能を動かす (e.g., Firewall, Router)

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

255
パケット I/O フレームワークの⽤途
ユーザー空間NFV アプリケーション
DPDK API

Network Function Virtualization (NFV)
汎⽤的なサーバーでネットワーク機能を動かす (e.g., Firewall, Router)

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

256
パケット I/O フレームワークの⽤途
ユーザー空間アプリケーション
TCP/IP スタック
DPDK API

Network Function Virtualization (NFV)
汎⽤的なサーバーでネットワーク機能を動かす (e.g., Firewall, Router)
サーバープログラムの⾼速化

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

ユーザー空間で動作する
TCP/IP スタックと組み合わせる

デスクリプタリング

DMA
送信⽤

受信⽤

257
パケット I/O フレームワークの⽤途
仮想マシン

仮想 NIC

ユーザー空間仮想 NIC バックエンド
DPDK API

ホスト

汎⽤的なサーバーでネットワーク機能を動かす (e.g., Firewall, Router)
サーバープログラムの⾼速化

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

Network Function Virtualization (NFV)

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

ユーザー空間で動作する
TCP/IP スタックと組み合わせる
仮想マシン通信の⾼速化

デスクリプタリング

仮想 I/O バックエンドに組み込む

DMA
送信⽤

受信⽤

258

研究紹介
TCP/IP スタック設計
マルチコア環境でのスケーラビリティについて
基本的なハードウェア機能の説明

259
TCP/IP スタック設計の再考• マルチコア環境で性能をスケールさせる• CPU コア間で共有されるオブジェクトのアクセスにはロックの取得が必要＝＞ロック取得待機時間がボトルネックになる

事前にロックの取得が必要
オブジェクト260
TCP/IP スタック設計の再考• マルチコア環境で性能をスケールさせる• CPU コア間で共有されるオブジェクトのアクセスにはロックの取得が必要＝＞ロック取得待機時間がボトルネックになる• 基本的なアイデア：CPU コア間で共有するオブジェクトを減らす

事前にロックの取得が必要
オブジェクト261
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる• NIC のマルチキュー機能を使う
カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

262
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる• NIC のマルチキュー機能を使う
カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

263
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる• NIC のマルチキュー機能を使う
カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

NIC キュー

264
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる• NIC のマルチキュー機能を使う
カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

NIC キュー

265
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる• NIC のマルチキュー機能を使う
カーネル
ソフトウェア(デバドラ)はメモリを通じてアクセス

TCP/IP スタック

NIC のキューが競合ポイントになる

NIC デバイスドライバ

キューへのアクセスごとにロックの取得が必要
解決策：NIC のマルチキュー機能を使う

NIC レジスタ•••••

受信⽤パケットバッファ

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタリング

DMA
送信⽤

受信⽤

NIC キュー

266
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる• NIC のマルチキュー機能を使う
カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

267
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる

NIC の機能を使って複数のキューを⽤意• NIC のマルチキュー機能を使う
カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

送信⽤

受信⽤

268
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる

NIC の機能を使って複数のキューを⽤意• NIC のマルチキュー機能を使う
カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

各コアがキューを⼀つずつ専有

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

送信⽤

受信⽤

269
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる

受信についての注意事項• NIC のマルチキュー機能を使う

カーネル

TCP/IP スタック

各コアがキューを⼀つずつ専有

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

NIC の機能を使って複数のキューを⽤意

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

送信⽤

受信⽤

270
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
TCP接続 BNIC の機能を使って複数のキューを⽤意

TCP接続 A

• NIC のマルチキュー機能を使う

カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

各コアがキューを⼀つずつ専有

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

2つのコアがそれぞれ
TCP 接続 A, B へ対応していたとしてデスクリプタリング

DMA
送信⽤

受信⽤

送信⽤

受信⽤

271
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
TCP接続 BNIC の機能を使って複数のキューを⽤意

TCP接続 A

• NIC のマルチキュー機能を使う

カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

各コアがキューを⼀つずつ専有

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

2つのコアがそれぞれ
TCP 接続 A, B へ対応していたとしてデスクリプタリング

DMA
送信⽤

受信⽤

送信⽤

受信⽤

272
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
TCP接続 BNIC の機能を使って複数のキューを⽤意

TCP接続 A

• NIC のマルチキュー機能を使う

カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

各コアがキューを⼀つずつ専有

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

2つのコアがそれぞれ
TCP 接続 A, B へ対応していたとしてデスクリプタリング

DMA
送信⽤

受信⽤

送信⽤

受信⽤

273
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
TCP接続 BNIC の機能を使って複数のキューを⽤意

TCP接続 A

• NIC のマルチキュー機能を使う

カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

各コアがキューを⼀つずつ専有

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

2つのコアがそれぞれ
TCP 接続 A, B へ対応していたとしてデスクリプタリング

DMA
送信⽤

受信⽤

送信⽤

受信⽤

274
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
TCP接続 BNIC の機能を使って複数のキューを⽤意

TCP接続 A

• NIC のマルチキュー機能を使う

カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

各コアがキューを⼀つずつ専有

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

2つのコアがそれぞれ
TCP 接続 A, B へ対応していたとしてデスクリプタリング

DMA
送信⽤

受信⽤

送信⽤

受信⽤

275
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
受信についての注意事項
TCP接続 B
TCP接続 ANIC の機能を使って複数のキューを⽤意• NIC のマルチキュー機能を使う
受信パケットがランダムにキューに割り振られるとTCP/IP スタック
各コアがキューを⼀つずつ専有
カーネル CPU コア間でデータのやりとりが必要になってしまう
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

2つのコアがそれぞれ
TCP 接続 A, B へ対応していたとしてデスクリプタリング

DMA
送信⽤

受信⽤

送信⽤

受信⽤

276
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
受信についての注意事項
TCP接続 B
TCP接続 ANIC の機能を使って複数のキューを⽤意• NIC のマルチキュー機能を使う
受信パケットがランダムにキューに割り振られるとTCP/IP スタック
各コアがキューを⼀つずつ専有
カーネル CPU コア間でデータのやりとりが必要になってしまう
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス

受信⽤パケットバッファ

2つのコアがそれぞれ
TCP 接続 A, B へ対応していたとして解決策：NIC の Receive Side Scaling (RSS) 機能を使う

NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

デスクリプタリング

DMA
送信⽤

受信⽤

送信⽤

受信⽤

277
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
TCP接続 BNIC の機能を使って複数のキューを⽤意

TCP接続 A

• NIC のマルチキュー機能を使う

カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

各コアがキューを⼀つずつ専有

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

2つのコアがそれぞれ
TCP 接続 A, B へ対応していたとしてデスクリプタリング

DMA
送信⽤

受信⽤

送信⽤

受信⽤

278
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
TCP接続 BNIC の機能を使って複数のキューを⽤意

TCP接続 A

• NIC のマルチキュー機能を使う

カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

各コアがキューを⼀つずつ専有

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

2つのコアがそれぞれ
TCP 接続 A, B へ対応していたとしてデスクリプタリング

Hash
Table
DMA

送信⽤

受信⽤

送信⽤

受信⽤

279
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
TCP接続 BNIC の機能を使って複数のキューを⽤意

TCP接続 A

• NIC のマルチキュー機能を使う

カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

各コアがキューを⼀つずつ専有

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

2つのコアがそれぞれ
TCP 接続 A, B へ対応していたとしてデスクリプタリング

Hash
Table
DMA

送信⽤

受信⽤

送信⽤

受信⽤

280
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
TCP接続 BNIC の機能を使って複数のキューを⽤意

TCP接続 A

• NIC のマルチキュー機能を使う

カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

各コアがキューを⼀つずつ専有

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

2つのコアがそれぞれ
TCP 接続 A, B へ対応していたとしてパケットのヘッダを⾒てハッシュ値を計算
Hash
Table

デスクリプタリング

DMA
送信⽤

受信⽤

送信⽤

受信⽤

281
TCP/IP スタック設計の再考*RSS: Receive Side Scaling

アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
TCP接続 BNIC の機能を使って複数のキューを⽤意

TCP接続 A

• NIC のマルチキュー機能を使う

カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

各コアがキューを⼀つずつ専有

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

2つのコアがそれぞれ
TCP 接続 A, B へ対応していたとしてパケットのヘッダを⾒てハッシュ値を計算
Hash
Table

デスクリプタリング

DMA
送信⽤

受信⽤

送信⽤

受信⽤

ハッシュ値を元に hash table を参照して宛先キューを決める282
TCP/IP スタック設計の再考*RSS: Receive Side Scaling

アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
TCP接続 BNIC の機能を使って複数のキューを⽤意

TCP接続 A

• NIC のマルチキュー機能を使う

カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

各コアがキューを⼀つずつ専有

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

2つのコアがそれぞれ
TCP 接続 A, B へ対応していたとしてデスクリプタリング

Hash
Table
DMA

送信⽤

受信⽤

送信⽤

受信⽤

283
TCP/IP スタック設計の再考*RSS: Receive Side Scaling

アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
受信についての注意事項
TCP接続 BNIC の機能を使って複数のキューを⽤意

TCP接続 A

• NIC のマルチキュー機能を使う
受信パケットがランダムにキューに割り振られるとTCP/IP スタック
各コアがキューを⼀つずつ専有
カーネル CPU コア間でデータのやりとりが必要になってしまう
NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス

受信⽤パケットバッファ

2つのコアがそれぞれ
TCP 接続 A, B へ対応していたとして解決策：NIC の Receive Side Scaling (RSS) 機能を使う

NIC レジスタ

デスクリプタリング

RSS のおかげで、特定の TCP 接続のパケットは• デスクリプタリング位置
特定のキューで受信されるようにできる• 転送リング head
• 転送リング tail
• 受信リング head
• 受信リング tail

DMA
送信⽤

受信⽤

送信⽤

受信⽤

Hash
Table

284
TCP/IP スタック設計の再考• マルチコア環境で性能をスケールさせる• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤• Receive Side Scaling (RSS) も利⽤

285
TCP/IP スタック設計の再考• マルチコア環境で性能をスケールさせる• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤• Receive Side Scaling (RSS) も利⽤

ここまでは NIC のハードウェア機能の話

286

研究紹介
TCP/IP スタック設計
マルチコア環境でのスケーラビリティについて
ソフトウェアでもコア間の共有オブジェクトを減らす

287
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる• NIC のマルチキュー機能を使う
カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

送信⽤

受信⽤

288
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる• NIC のマルチキュー機能を使う
カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tailTCP の接続確⽴時

受信⽤パケットバッファ

デスクリプタリング

DMA
送信⽤

受信⽤

送信⽤

受信⽤

289
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる• NIC のマルチキュー機能を使う
カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tailTCP の接続確⽴時

受信⽤パケットバッファ

デスクリプタリング
TCP
SYN
DMA
送信⽤

受信⽤

送信⽤

受信⽤

290
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる• NIC のマルチキュー機能を使う
カーネル

TCP/IP スタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tailTCP の接続確⽴時

受信⽤パケットバッファ

デスクリプタリング
TCP
SYN

TCP
SYN
DMA

送信⽤

受信⽤

送信⽤

受信⽤

291
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる• NIC のマルチキュー機能を使う
カーネル

TCP接続 B
TCP接続
A
TCP/IPスタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング
TCP
SYN

TCP
SYN
DMA

送信⽤

受信⽤

送信⽤

受信⽤

292
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
accept()ソケット• NIC のマルチキュー機能を使う

カーネル

TCP接続 B
TCP接続
A
TCP/IPスタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング
TCP
SYN

TCP
SYN
DMA

送信⽤

受信⽤

送信⽤

受信⽤

293
TCP/IP スタック設計の再考
accept キュー

アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
ソケット• NIC のマルチキュー機能を使う

カーネル

TCP接続 B
TCP接続
A
TCP/IPスタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング
TCP
SYN

TCP
SYN
DMA

送信⽤

受信⽤

送信⽤

受信⽤

294
TCP/IP スタック設計の再考
accept キュー

アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
ソケット• NIC のマルチキュー機能を使う

カーネル

TCP接続 B
TCP接続
A
TCP/IP
スタック

TCP接続 A

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

TCP接続 B

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング
TCP
SYN

TCP
SYN
DMA

送信⽤

受信⽤

送信⽤

受信⽤

295
TCP/IP スタック設計の再考
accept キュー

アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
ソケット• NIC のマルチキュー機能を使う

カーネル

TCP接続 B
TCP接続
A
TCP/IP
スタック

TCP接続 A

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

TCP接続 B

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング
TCP
SYN

TCP
SYN
DMA

送信⽤

受信⽤

送信⽤

受信⽤

accept キューはソケットごとに１つずつしかないため、コア間での競合のポイントになる296
TCP/IP スタック設計の再考• マルチコア環境で性能をスケールさせる• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤• Receive Side Scaling (RSS) も利⽤• accept のスケーラビリティに関して• Affinity-Accept (EuroSys 2012)• MegaPipe (OSDI 2012)• mTCP (NSDI 2014)• Fastsocket (ASPLOS 2016)

297
TCP/IP スタック設計の再考
accept キュー

アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
ソケット• NIC のマルチキュー機能を使う

カーネル

TCP接続 B
TCP接続
A
TCP/IP
スタック

TCP接続 A

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

TCP接続 B

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング
TCP
SYN

TCP
SYN
DMA

送信⽤

受信⽤

送信⽤

受信⽤

accept キューはソケットごとに１つずつしかないため、コア間での競合のポイントになる298
TCP/IP スタック設計の再考
アプリケーション•ユーザー空間マルチコア環境で性能をスケールさせる
ソケット• NIC のマルチキュー機能を使う

カーネル

TCP接続 A

TCP接続 B
TCP接続
A
TCP/IPスタック

NIC デバイスドライバ

ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

accept キュー

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

デスクリプタリング
TCP
SYN

TCP
SYN
DMA

送信⽤

解決策：コアごとに accept キューを⽤意する

受信⽤

送信⽤

受信⽤

TCP接続 B299
TCP/IP スタック設計の再考• マルチコア環境で性能をスケールさせる• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤• Receive Side Scaling (RSS) も利⽤• accept のスケーラビリティに関して• Affinity-Accept (EuroSys 2012)• MegaPipe (OSDI 2012)• mTCP (NSDI 2014)• Fastsocket (ASPLOS 2016)

300

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考• マルチコア環境で性能をスケールさせる• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤
16000

Throughput (requests / sec / core)• Receive Side Scaling (RSS) も利⽤
ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
• Affinity-Accept(EuroSys
2012)
n the network stack.
Applications that put
less stresson• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
from 30 bytes to• mTCP(NSDIrange
2014)
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file to request uniformly over all files.
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

301

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考• マルチコア環境で性能をスケールさせる
アプリケーション• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤
16000

Throughput (requests / sec / core)• Receive Side Scaling (RSS) も利⽤
ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
•TCP接続Affinity-Accept(EuroSys
2012)
n the network stack.
Applications
that putlessstress
on
A
TCP接続
B
• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
fromTCP接続
30 bytesDto•TCP接続mTCP
2014)
C(NSDIrange
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file TCP接続
to requestEuniformly overTCP接続
all files. F
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

302

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考
Fine-Accept: 全ての accept キューからラウンドロビンで accept• マルチコア環境で性能をスケールさせる
アプリケーション• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤
16000

Throughput (requests / sec / core)• Receive Side Scaling (RSS) も利⽤
ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
•TCP接続Affinity-Accept(EuroSys
2012)
n the network stack.
Applications
that putlessstress
on
A
TCP接続
B
• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
fromTCP接続
30 bytesDto•TCP接続mTCP
2014)
C(NSDIrange
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file TCP接続
to requestEuniformly overTCP接続
all files. F
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

303

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考
Fine-Accept: 全ての accept キューからラウンドロビンで accept• マルチコア環境で性能をスケールさせる
アプリケーション• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤
accept()• Receive Side Scaling (RSS) も利⽤

16000

Throughput (requests / sec / core)

ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
•TCP接続Affinity-Accept(EuroSys
2012)
n the network stack.
Applications
that putlessstress
on
A
TCP接続
B
• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
fromTCP接続
30 bytesDto•TCP接続mTCP
2014)
C(NSDIrange
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file TCP接続
to requestEuniformly overTCP接続
all files. F
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

304

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考
Fine-Accept: 全ての accept キューからラウンドロビンで accept• マルチコア環境で性能をスケールさせる
アプリケーション• 基本的なアイデア：コア間で共有するオブジェクトを減らす
TCP接続 A
• NIC のキューについて：NIC のマルチキュー機能を利⽤
accept()• Receive Side Scaling (RSS) も利⽤

16000

Throughput (requests / sec / core)

ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
• Affinity-Accept(EuroSys
2012)
n the network stack.
Applications that put
lessstress
on
TCP接続
B
• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
fromTCP接続
30 bytesDto•TCP接続mTCP
2014)
C(NSDIrange
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file TCP接続
to requestEuniformly overTCP接続
all files. F
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

305

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考
Fine-Accept: 全ての accept キューからラウンドロビンで accept• マルチコア環境で性能をスケールさせる
アプリケーション• 基本的なアイデア：コア間で共有するオブジェクトを減らす
TCP接続 A
• NIC のキューについて：NIC のマルチキュー機能を利⽤
16000

Throughput (requests / sec / core)• Receive Side Scaling (RSS) も利⽤
ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
• Affinity-Accept(EuroSys
2012)
n the network stack.
Applications that put
lessstress
on
TCP接続
B
• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
fromTCP接続
30 bytesDto•TCP接続mTCP
2014)
C(NSDIrange
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file TCP接続
to requestEuniformly overTCP接続
all files. F
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

306

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考
Fine-Accept: 全ての accept キューからラウンドロビンで accept• マルチコア環境で性能をスケールさせる
アプリケーション• 基本的なアイデア：コア間で共有するオブジェクトを減らす
TCP接続 A
• NIC のキューについて：NIC のマルチキュー機能を利⽤
accept()• Receive Side Scaling (RSS) も利⽤

16000

Throughput (requests / sec / core)

ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
• Affinity-Accept(EuroSys
2012)
n the network stack.
Applications that put
lessstress
on
TCP接続
B
• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
fromTCP接続
30 bytesDto•TCP接続mTCP
2014)
C(NSDIrange
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file TCP接続
to requestEuniformly overTCP接続
all files. F
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

307

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考
Fine-Accept: 全ての accept キューからラウンドロビンで accept• マルチコア環境で性能をスケールさせる
TCP接続 B
アプリケーション• 基本的なアイデア：コア間で共有するオブジェクトを減らす
TCP接続 A
• NIC のキューについて：NIC のマルチキュー機能を利⽤
accept()• Receive Side Scaling (RSS) も利⽤

16000

Throughput (requests / sec / core)

ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
• Affinity-Accept(EuroSys
2012)
n the network stack.
Applications that put
less stresson• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
fromTCP接続
30 bytesDto•TCP接続mTCP
2014)
C(NSDIrange
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file TCP接続
to requestEuniformly overTCP接続
all files. F
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

308

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考
Fine-Accept: 全ての accept キューからラウンドロビンで accept• マルチコア環境で性能をスケールさせる
TCP接続 B
アプリケーション• 基本的なアイデア：コア間で共有するオブジェクトを減らす
TCP接続 A
• NIC のキューについて：NIC のマルチキュー機能を利⽤
16000

Throughput (requests / sec / core)• Receive Side Scaling (RSS) も利⽤
ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
• Affinity-Accept(EuroSys
2012)
n the network stack.
Applications that put
less stresson• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
fromTCP接続
30 bytesDto•TCP接続mTCP
2014)
C(NSDIrange
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file TCP接続
to requestEuniformly overTCP接続
all files. F
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

309

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考
Fine-Accept: 全ての accept キューからラウンドロビンで accept• マルチコア環境で性能をスケールさせる
TCP接続 B
アプリケーション• 基本的なアイデア：コア間で共有するオブジェクトを減らす
TCP接続 A
• NIC のキューについて：NIC のマルチキュー機能を利⽤
accept()• Receive Side Scaling (RSS) も利⽤

16000

Throughput (requests / sec / core)

ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
• Affinity-Accept(EuroSys
2012)
n the network stack.
Applications that put
less stresson• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
fromTCP接続
30 bytesDto•TCP接続mTCP
2014)
C(NSDIrange
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file TCP接続
to requestEuniformly overTCP接続
all files. F
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

310

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考
Fine-Accept: 全ての accept キューからラウンドロビンで accept•TCP接続マルチコア環境で性能をスケールさせる
C
TCP接続 B
アプリケーション• 基本的なアイデア：コア間で共有するオブジェクトを減らす
TCP接続 A
• NIC のキューについて：NIC のマルチキュー機能を利⽤
accept()• Receive Side Scaling (RSS) も利⽤

16000

Throughput (requests / sec / core)

ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
• Affinity-Accept(EuroSys
2012)
n the network stack.
Applications that put
less stresson• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
fromTCP接続
30 bytesDto• mTCP(NSDIrange
2014)
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file TCP接続
to requestEuniformly overTCP接続
all files. F
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

311

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考
Affinity-Accept: 基本的に特定の accept キューからのみ accept• マルチコア環境で性能をスケールさせる
アプリケーション• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤
accept()• Receive Side Scaling (RSS) も利⽤

16000

Throughput (requests / sec / core)

ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
•TCP接続Affinity-Accept(EuroSys
2012)
n the network stack.
Applications
that putlessstress
on
A
TCP接続
B
• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
fromTCP接続
30 bytesDto•TCP接続mTCP
2014)
C(NSDIrange
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file TCP接続
to requestEuniformly overTCP接続
all files. F
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

312

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考
Affinity-Accept: 基本的に特定の accept キューからのみ accept• マルチコア環境で性能をスケールさせる
アプリケーション

TCP接続 A
• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤
16000

Throughput (requests / sec / core)• Receive Side Scaling (RSS) も利⽤
ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
• Affinity-Accept(EuroSys
2012)
n the network stack.
Applications that put
lessstress
on
TCP接続
B
• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
fromTCP接続
30 bytesDto•TCP接続mTCP
2014)
C(NSDIrange
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file TCP接続
to requestEuniformly overTCP接続
all files. F
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

313

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考
Affinity-Accept: 基本的に特定の accept キューからのみ accept• マルチコア環境で性能をスケールさせる
アプリケーション

TCP接続 A
• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤
accept()• Receive Side Scaling (RSS) も利⽤

16000

Throughput (requests / sec / core)

ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
• Affinity-Accept(EuroSys
2012)
n the network stack.
Applications that put
lessstress
on
TCP接続
B
• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
fromTCP接続
30 bytesDto•TCP接続mTCP
2014)
C(NSDIrange
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file TCP接続
to requestEuniformly overTCP接続
all files. F
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

314

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考
Affinity-Accept: 基本的に特定の accept キューからのみ accept
TCP接続 C• マルチコア環境で性能をスケールさせる

アプリケーション

TCP接続 A
• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤
accept()• Receive Side Scaling (RSS) も利⽤

16000

Throughput (requests / sec / core)

ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
• Affinity-Accept(EuroSys
2012)
n the network stack.
Applications that put
lessstress
on
TCP接続
B
• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
fromTCP接続
30 bytesDto• mTCP(NSDIrange
2014)
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file TCP接続
to requestEuniformly overTCP接続
all files. F
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

315

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考• マルチコア環境で性能をスケールさせる• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤
16000

Throughput (requests / sec / core)• Receive Side Scaling (RSS) も利⽤
ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
• Affinity-Accept(EuroSys
2012)
n the network stack.
Applications that put
less stresson• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
from 30 bytes to• mTCP(NSDIrange
2014)
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file to request uniformly over all files.
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

316

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考• マルチコア環境で性能をスケールさせる• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤

デフォルト実装はコアが増えるほど１コアが処理するリクエストが減っている

16000

Throughput (requests / sec / core)• Receive Side Scaling (RSS) も利⽤
ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
• Affinity-Accept(EuroSys
2012)
n the network stack.
Applications that put
less stresson• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
from 30 bytes to• mTCP(NSDIrange
2014)
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file to request uniformly over all files.
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

317

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考• マルチコア環境で性能をスケールさせる• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤
Affinity/Fine-Accept は下降がゆるやか
16000

Throughput (requests / sec / core)• Receive Side Scaling (RSS) も利⽤
ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
• Affinity-Accept(EuroSys
2012)
n the network stack.
Applications that put
less stresson• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
from 30 bytes to• mTCP(NSDIrange
2014)
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file to request uniformly over all files.
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000
6000
4000
Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

318

Aleksey Pesterev, Jacob Strauss, Nickolai Zeldovich, and Robert T. Morris. 2012. Improving Network Connection Locality on Multicore Systems. In Proceedings ofthe 7th ACM European Conference on Computer Systems (EuroSys ʼ12), 337-350.(https://doi.org/10.1145/2168836.2168870)

TCP/IP スタック設計の再考• マルチコア環境で性能をスケールさせる• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤
16000

Throughput (requests / sec / core)• Receive Side Scaling (RSS) も利⽤
ectly because it does not sufficiently stress the network
ck: some requests involve performing SQL queries or• acceptのスケーラビリティに関して
ning PHP code,
which stresses
the disk and CPU more
• Affinity-Accept(EuroSys
2012)
n the network stack.
Applications that put
less stresson• see
MegaPipe(OSDI 2012)
network stack willless pronounced
improvementsh Affinity-Accept. The
files served
from 30 bytes to• mTCP(NSDIrange
2014)
70 bytes. The web •server
serves 30,000
distinctfiles, andFastsocket(ASPLOS
2016)
ient chooses a file to request uniformly over all files.
Unlessotherwise
all experiments a client reApache
HTTP stated,server in
パフォーマンス
ests aベンチマーククライアントは1回のtotal of 6 files per connection withTCP
requests
spaced接続で６ファイル取得by think time. First, a client requests one file and waits for

14000
12000
10000
8000

Fine-Accept (ラウンドロビン)よりAffinity-Accept の⽅が速い
4000 キャッシュ効率が原因との説明
6000

Stock-Accept
Fine-Accept
Affinity-Accept

2000
0

1

4

8

12

16

20

24 28
Cores

32

36

40

44

48

319
TCP/IP スタック設計の再考• マルチコア環境で性能をスケールさせる• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤• Receive Side Scaling (RSS) も利⽤• accept のスケーラビリティに関して• Affinity-Accept (EuroSys 2012)• MegaPipe (OSDI 2012)• mTCP (NSDI 2014)• Fastsocket (ASPLOS 2016)
POSIX socket に変わる API の提案- accept のキューをコアごとに分ける

320
TCP/IP スタック設計の再考• マルチコア環境で性能をスケールさせる• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤• Receive Side Scaling (RSS) も利⽤• accept のスケーラビリティに関して• Affinity-Accept (EuroSys 2012)• MegaPipe (OSDI 2012)• mTCP (NSDI 2014)• Fastsocket (ASPLOS 2016)
POSIX socket に変わる API の提案- accept のキューをコアごとに分ける- ファイルデスクリプタのテーブルも分ける- 複数のリクエストをバッチ可能 (FlexSC と同様の効果を期待)321

Sangjin Han, Scott Marshall, Byung-Gon Chun, Sylvia Ratnasamy, "MegaPipe: A New Programming Interface for Scalable Network I/O", OSDI 2012https://www.usenix.org/conference/osdi12/technical-sessions/presentation/han

TCP/IP スタック設計の再考• マルチコア環境で性能をスケールさせる• 基本的なアイデア：コア間で共有するオブジェクトを減らす• NIC のキューについて：NIC のマルチキュー機能を利⽤

1.8

12

400.6
1

20

80

16

MegaPipe

60

12Baseline

3.6
3• Affinity-Accept (EuroSys 2012)60
12 2.440
40
8• MegaPipe (OSDI 2012)
1.820
20
4
•
mTCP
(NSDI
2014)
40
8
8
1.20
0
0 2016)•
Fastsocket(ASPLOS
2 3 4 5 6 7 8
1 2 3 4 5 6 7 820
4# of CPU Cores
4 0.6# of CPU Cores

12

1.2

20

60

Baseline
80
16
16• accept のスケーラビリティに関して

60

0

16

100
100

100

Improvement
Improvement

60
40
60

8
4

20

40
40

0

1

2

3

4

5

6

7

1 latency
2 3 with
4 low
5 concurrency
6 7 8(thusand 200µs (tail) lower

8# of CPU Cores

2

80

80
60

nginx HTTP server パフォーマンス
Figure 7: Evaluation of nginx throughput for the (a) SpecWeb, (b) Yahoo,and (c) Yahoo/2 workloads.
00 ベンチマーククライアントは1回の
0
00
1 2 3 4 5 6 7
TCP 接続で６ファイル取得

1

100

80

3

50% of the total traffic.

4

5

6

# of CPU Cores

7

8

8

0

20
20
0

0

Improvement (%)

802.4

80

Throughput (Gbps)

Throughput (Gbps)

MegaPipe

3

20

Improvement (%)(RSS) も利⽤
100
20 • Receive Side Scaling
100
20

100
3.6

322

研究紹介
TCP/IP スタック設計
パケット I/O フレームワークを適⽤する
ユーザー空間 TCP/IP スタック実装

323
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• zIO (OSDI 2021)• Demikernel (SOSP 2021)

324
パケット I/O フレームワークの⽤途
ユーザー空間アプリケーション
TCP/IP スタック
DPDK API

Network Function Virtualization (NFV)
汎⽤的なサーバーでネットワーク機能を動かす (e.g., Firewall, Router)
サーバープログラムの⾼速化

NIC デバイスドライバ
ソフトウェア(デバドラ)はメモリを通じてアクセス
NIC レジスタ•••••

デスクリプタリング位置
転送リング head
転送リング tail
受信リング head
受信リング tail

受信⽤パケットバッファ

ユーザー空間で動作する
TCP/IP スタックと組み合わせる

デスクリプタリング

DMA
送信⽤

受信⽤

325
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

326
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

Web サーバー
netmap + ユーザー空間 TCP/IP スタック
（コンテンツをパケットバッファ上に事前配置）

Ilias Marinos, Robert N. M. Watson, and Mark Handley. 2014. Network Stack Specialization for Performance. In Proceedings of the 2014 ACM Conference on
SIGCOMM (SIGCOMM ʼ14), 175-186.(https://doi.org/10.1145/2619239.2626311)

327

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

Web サーバー
netmap + ユーザー空間 TCP/IP スタック
（コンテンツをパケットバッファ上に事前配置）
コンテンツ配送速度（6つの 10Gbps NIC 合計）

328
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

ユーザー空間 TCP/IP スタック
- accept キュー等をコアごとに⽤意- リクエストをバッチ

15
15 15

10
10 10

saturated
LinkLink
saturated

329

TCP/IP4 スタック設計の再考
6 66
44
6 66

30
30 30

20
20 20

9 99

3 33
2 22 フレームワーク上で TCP/IP• パケット I/O
スタックを動かす10
10 10

Throughput
Throughput (Gbps)(Gbps)

1212 12Throughput (Gbps)

40
40 40

5
Messages/sec
Messages/sec (x
(x 10
105))

Messages/sec (x 105)

Messages/sec (x 1055)

8 88

Messages/sec (x 105)

Throughput
Throughput (Gbps)(Gbps)

Throughput (Gbps)

Link
saturated
50 Park. 2014. mTCP: A Highly Scalable
EunYoung
Jeong,
Shinae Wood, Muhammad Jamshed, Haewon Jeong, Sunghwan Ihm, Dongsu Han, and 50
KyoungSoo
50
1User-Level8
11 2 22 4 10
44 10
10
Link
saturated
LinkLink
saturatedsaturated
TCP Stack for Multicore Systems. In 11th USENIX Symposium on Networked Systems Design and Implementation (NSDI 14), 489Numberof
Message
Numberof Messages
per
Numberof Messages
502.(https://www.usenix.org/conference/nsdi14/technical-sessions/presentation/jeong)

8 88
6 66
4 44
2 22

5
Messages/sec (xMessages/sec
(x 10
105))

Messages/sec (x 105)

Throughput (Gbps)
Throughput(Gbps)

nections/sec (x 105)

55)
(x
10
Messages/sec
Throughput (Gbps)

Messages/sec (x 105)5
Messages/sec (xMessages/sec
(x 10
105))

Messages/sec (x 105)0- 0-00 00 (SIGCOMM 2014)• Sandstorm
ユーザー空間TCP/IP スタック
-0 -0-0
1 112 22 4 44 6 66 8 880 00
000
32 64 6464128128128
64B256B
256B1KiB
1KiB4KiB
4KiB8KiB
8KiB
64B64B88 32 32
256B
1KiB
4KiB
8KiB
- accept キュー等をコアごとに⽤意
32 64 6464128128128
1 11 2 22 8 88 32 32
•
mTCP
(NSDI
2014)
NumberofCPU
Cores
NumberofCPU
Cores
NumberofCPU
Cores
Message
SizeSizees
per Connection
MessageSizessagesper Connection
Connection
Messagessagesper- リクエストをバッチ
Numberof Messages
per Connection
Numberof Messages
Messages
per Connection
Connection
Numberofper• Arrakis (OSDI 2014)
Linux
Linux REUSEPORTREUSEPORT MegaPipe
MegaPipe mTCP
mTCP
Linux
REUSEPORTMegaPipemTCP• IX (OSDI 2014)
50 50
10
50
50 50
50
1510 10saturated
Link
saturated 15 15
Linksaturated• StackMap(USENIX ATCLink
2016)
40
40
• Atlas40(SIGCOMM
2017)
40 40
40
12 12
128 88• ZygOS2017)
30 (SOSP
30
30
30 30
30
9 996 66
4•
Shenango
(NSDI
2019)
REUSEPORTMegaPipe
Linux
20 20
20
Linux
REUSEPORTMegaPipe
20 20
20
6 6644 44
REUSEPORT• Shinjuku (NSDI 2019)
3
10 10
2 22
10
10 10
10
3
3
3
Multiprocess
3• TAS (EuroSys 2019)
0 0002 00
MegaPipe-0 -0-0-0 -0-0- -•Caladan(OSDI
2020)
1 11 2 22 8 88 32 32
64
8KiB
32 64mTCP
64128128
128
64B
256B
1KiB
4KiB
8KiB 16 66
8 88
44
0 2001 164B
4 256B
6 1KiB
84KiB
22 256B
44 1KiB
66 4KiB
88 8KiB
12 64B
Numberof Messages
per perConnection• Demikernel(SOSP
NumberofMessages
N
Numberof2021)
Messages
perConnection
Connection
PU
Cores
f CPU
Cores
Message
Size
Numberof CPU
Cores
of
CPU
Cores
Message
Size
NumberofCores
Message
Size
Numberof CPU
CPU
Cores
1

330
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

新しい OS- アプリ＋lwIP が直接 NIC へアクセス- NIC の SR-IOV 機能で多重化Adam Belay, George Prekas, Ana Klimovic, Samuel Grossman, Christos Kozyrakis, and Edouard Bugnion. 2014. IX: A Protected Dataplane Operating System for HighThroughput and Low Latency. In 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14), 4965.(https://www.usenix.org/conference/osdi14/technical-sessions/presentation/belay)

331

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす

TCP$Echo:$Mul3core$Scalability$
for$Short$Connec3ons$

新しい OS- アプリ＋lwIP が直接 NIC へアクセス- NIC の SR-IOV 機能で多重化
4

Messages/sec (x 106)• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

IX 10GbE
IX 4x10GbE
Linux 10GbE
Linux 4x10GbE
mTCP 10GbE

3.5
3
2.5

Saturates%
1x10GbE%

2
1.5
1
0.5
0
0

1

2

3
4
5
6
Number of CPU cores

7

8

332

研究紹介
TCP/IP スタック設計
パケット I/O フレームワークを適⽤する
既存の OS の TCP/IP スタックを使えるようにする

Kenichi Yasukata, Michio Honda, Douglas Santry, and Lars Eggert. 2016. StackMap: Low-Latency Networking with the OS Stack and Dedicated NICs. In 2016 USENIX
Annual Technical Conference (USENIX ATC 16), 43-56.(https://www.usenix.org/conference/atc16/technical-sessions/presentation/yasukata)333

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす
netmap + カーネル TCP/IP スタック
- アプリの API とデータパスは（ほぼ） netmap- ヘッダの処理にカーネル TCP/IP スタックを利⽤

kernel user

• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)
StackMap Architecture• Arrakis (OSDI 2014)• IX (OSDI 2014)
1. Socket)API)for)control)path• StackMap(USENIX ATC 2016)! socket(),)bind(),)listen()• Atlas (SIGCOMM 2017)
NetmapAPI)for)data)path)• ZygOS 2.
(SOSP
2017)
(extended)• Shenango
2019)! (NSDI
Syscall and)packet)I/O)
batching,)zero)copy,)run-to• Shinjuku (NSDI2019)
completion• TAS (EuroSys 2019)
3. Persistent,)fixed-size)• Caladan (OSDI2020)
sk_buffs• Demikernel(SOSP 2021)! Efficiently)call)into)kernel)TCP/IP

Regular3app

StackMap app
1.
2.

Socket3API
TCP/IP/Eth3.

netmap framework
Packet3buffers

Linux3packet3I/O
Device3drivers
NIC

4.

NIC

Kenichi Yasukata, Michio Honda, Douglas Santry, and Lars Eggert. 2016. StackMap: Low-Latency Networking with the OS Stack and Dedicated NICs. In 2016 USENIX
Annual Technical Conference (USENIX ATC 16), 43-56.(https://www.usenix.org/conference/atc16/technical-sessions/presentation/yasukata)334

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす
netmap + カーネル TCP/IP スタック
- アプリの API とデータパスは（ほぼ） netmap- ヘッダの処理にカーネル TCP/IP スタックを利⽤

kernel user

• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)
StackMap Architecture• Arrakis (OSDI 2014)• IX (OSDI 2014)
1. Socket)API)for)control)path• StackMap(USENIX ATC 2016)! socket(),)bind(),)listen()• Atlas (SIGCOMM 2017)
NetmapAPI)for)data)path)• ZygOS 2.
(SOSP
2017)
(extended)• Shenango
2019)! (NSDI
Syscall and)packet)I/O)
batching,)zero)copy,)run-to• Shinjuku (NSDI2019)
completion• TAS (EuroSys 2019)
3. Persistent,)fixed-size)• Caladan (OSDI2020)
sk_buffs• Demikernel(SOSP 2021)! Efficiently)call)into)kernel)TCP/IP

Regular3app

StackMap app
1.
2.

Socket3API
TCP/IP/Eth

3.

データパス

netmap framework
Packet3buffers

Linux3packet3I/O
Device3drivers
NIC

4.

NIC

Kenichi Yasukata, Michio Honda, Douglas Santry, and Lars Eggert. 2016. StackMap: Low-Latency Networking with the OS Stack and Dedicated NICs. In 2016 USENIX
Annual Technical Conference (USENIX ATC 16), 43-56.(https://www.usenix.org/conference/atc16/technical-sessions/presentation/yasukata)335

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす

kernel user

• Sandstorm (SIGCOMM 2014)
netmap + カーネル TCP/IP スタック
- アプリの API とデータパスは（ほぼ） netmap• mTCP (NSDI 2014)- ヘッダの処理にカーネル TCP/IP スタックを利⽤
StackMap Architecture• Arrakis (OSDI 2014)
パケットは Socket API と Linux の通常の I/O サブシステムをバイパス• IX (OSDI 2014)
1. Socket)API)for)control)path
Regular3app StackMap app• StackMap(USENIX ATC 2016)! socket(),)bind(),)listen()• Atlas (SIGCOMM 2017)
1.
データパス
2.
2.
NetmapAPI)for)data)path)• ZygOS (SOSP 2017)
netmap framework
Socket3API(extended)• Shenango
2019)! (NSDI
Syscall and)packet)I/O)
3.
TCP/IP/Eth
Packet3buffers
batching,)zero)copy,)run-to• Shinjuku (NSDI 2019)
completion
Linux3packet3I/O• TAS (EuroSys 2019)4.
3. Persistent,)fixed-size)
Device3drivers• Caladan (OSDI2020)
sk_buffs
NIC
NIC• Demikernel(SOSP 2021)! Efficiently)call)into)kernel)TCP/IP

Kenichi Yasukata, Michio Honda, Douglas Santry, and Lars Eggert. 2016. StackMap: Low-Latency Networking with the OS Stack and Dedicated NICs. In 2016 USENIX
Annual Technical Conference (USENIX ATC 16), 43-56.(https://www.usenix.org/conference/atc16/technical-sessions/presentation/yasukata)336

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす

kernel user

• Sandstorm (SIGCOMM 2014)
netmap + カーネル TCP/IP スタック
- アプリの API とデータパスは（ほぼ） netmap• mTCP (NSDI 2014)- ヘッダの処理にカーネル TCP/IP スタックを利⽤
StackMap Architecture• Arrakis (OSDI 2014)
パケットは Socket API と Linux の通常の I/O サブシステムをバイパス• IX (OSDI 2014)
1. Socket)API)for)control)path
Regular3app StackMap app• StackMap(USENIX ATC 2016)! socket(),)bind(),)listen()• Atlas (SIGCOMM 2017)
1.
データパス
2.
2.
NetmapAPI)for)data)path)• ZygOS (SOSP 2017)
netmap framework
Socket3API(extended)• Shenango
2019)! (NSDI
Syscall and)packet)I/O)
3.
TCP/IP/Eth
Packet3buffers
batching,)zero)copy,)run-to• Shinjuku (NSDI 2019)
completion
Linux3packet3I/O• TAS (EuroSys 2019)4.
送受信に際してカーネルのTCP/IPスタックが3. Persistent,)fixed-size)
Device3drivers• Caladan (OSDI2020)
ヘッダの処理を⾏う
sk_buffs
NIC
NIC• Demikernel(SOSP 2021)! Efficiently)call)into)kernel)TCP/IP

Kenichi Yasukata, Michio Honda, Douglas Santry, and Lars Eggert. 2016. StackMap: Low-Latency Networking with the OS Stack and Dedicated NICs. In 2016 USENIX
Annual Technical Conference (USENIX ATC 16), 43-56.(https://www.usenix.org/conference/atc16/technical-sessions/presentation/yasukata)

Performance

337

TCP/IP スタック設計の再考
500e)HTTP)server

Latency [µs]Linux (99th %ile)
400
Linux (mean)th• パケット I/O フレームワーク上で
TCP/IP
スタックを動かす%ile)
StackMap(99300(mean)ng) 1KB)messages)(single)core) 2014)• Sandstorm (SIGCOMM
netmapStackMap+ カーネルTCP/IP スタック200- アプリの API とデータパスは（ほぼ） netmap

Throughput [Gb/s]• mTCP (NSDI 2014)
100- ヘッダの処理にカーネル TCP/IP スタックを利⽤• Arrakis (OSDI 2014)
0
１コアで 1 KB データを送信• IX (OSDI 2014)
0
20
40
60
80
100
• StackMap (USENIX ATC 2016)
Concurrent TCP Connections
8• Atlas (SIGCOMM 2017)
Linux
StackMap
6• ZygOS (SOSP 2017)• Shenango (NSDI 2019)4• Shinjuku (NSDI 2019)2• TAS (EuroSys 2019)0• Caladan (OSDI 2020)
0
20
40
60
80
100
• Demikernel (SOSP 2021)
Concurrent TCP Connections

338

研究紹介
TCP/IP スタック設計
パケット I/O フレームワークを適⽤するディスクとの親和性を⾼めるIlias Marinos, Robert N.M. Watson, Mark Handley, and Randall R. Stewart. 2017. Disk|Crypt|Net: rethinking the stack for high-performance video streaming. In
Proceedings of the Conference of the ACM Special Interest Group on Data Communication (SIGCOMM '17). Association for Computing Machinery, New York, NY, USA,211‒224. https://doi.org/10.1145/3098822.3098844

339

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす
ビデオストリーミング⽤サーバー（Sandstorm 拡張）- ディスクアクセス時にカーネルをバイパスする
diskmap 機構を追加- diskmap を netmap と統合して、ディスクからの読み取ったデータの配送を効率化

The Atlas Execution Pipeline
webserver
TCP/IPuser

libnmio2

kernel• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

libnvme
7

RX

SQ

TX

buffers

1

NIC

6

3
CQ

4

NVMe Disk

5

Ilias Marinos, Robert N.M. Watson, Mark Handley, and Randall R. Stewart. 2017. Disk|Crypt|Net: rethinking the stack for high-performance video streaming. In
Proceedings of the Conference of the ACM Special Interest Group on Data Communication (SIGCOMM '17). Association for Computing Machinery, New York, NY, USA,211‒224. https://doi.org/10.1145/3098822.3098844

340

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす
ビデオストリーミング⽤サーバー（Sandstorm 拡張）- ディスクアクセス時にカーネルをバイパスする
diskmap 機構を追加- diskmap を netmap と統合して、ディスクからの読み取ったデータの配送を効率化

The Atlas Execution Pipeline
webserver
TCP/IPuser

libnmio2

kernel• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

netmapRX

libnvme7

SQ

TX

buffers

1

NIC

6

3
CQ

4

NVMe Disk

5

Ilias Marinos, Robert N.M. Watson, Mark Handley, and Randall R. Stewart. 2017. Disk|Crypt|Net: rethinking the stack for high-performance video streaming. In
Proceedings of the Conference of the ACM Special Interest Group on Data Communication (SIGCOMM '17). Association for Computing Machinery, New York, NY, USA,211‒224. https://doi.org/10.1145/3098822.3098844

341

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす
ビデオストリーミング⽤サーバー（Sandstorm 拡張）- ディスクアクセス時にカーネルをバイパスする
diskmap 機構を追加- diskmap を netmap と統合して、ディスクからの読み取ったデータの配送を効率化

The Atlas Execution Pipeline
webserver
TCP/IPuser

libnmio2

kernel• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

netmapRX

libnvme
7

3

SQ

TX

buffers

1

NIC

6

diskmap
CQ

4

NVMe Disk

5

Ilias Marinos, Robert N.M. Watson, Mark Handley, and Randall R. Stewart. 2017. Disk|Crypt|Net: rethinking the stack for high-performance video streaming. In
Proceedings of the Conference of the ACM Special Interest Group on Data Communication (SIGCOMM '17). Association for Computing Machinery, New York, NY, USA,211‒224. https://doi.org/10.1145/3098822.3098844

342

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす

kerneluser• Sandstorm (SIGCOMM 2014)
ビデオストリーミング⽤サーバー（Sandstorm 拡張）- ディスクアクセス時にカーネルをバイパスする• mTCP (NSDI 2014)
diskmap
機構を追加
The
Atlas
Execution
Pipeline• Arrakis (OSDI 2014)- diskmap を netmap と統合して、ディスクからの読み取ったデータの配送を効率化• IX (OSDI 2014)• StackMap (USENIX ATC 2016)
webserver• Atlas (SIGCOMM 2017)
TCP/IP• ZygOS (SOSP 2017) NIC I/O と Disk I/O に
libnmiolibnvme
同じバッファが使える• Shenango (NSDI 2019)2
7
3 diskmap 6
netmap• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)buffers
4
5
1• Caladan (OSDI 2020)
NIC
NVMe Disk• Demikernel (SOSP 2021)
RX

TX

SQ

CQ

Ilias Marinos, Robert N.M. Watson, Mark Handley, and Randall R. Stewart. 2017. Disk|Crypt|Net: rethinking the stack for high-performance video streaming. In
Proceedings of the Conference of the ACM Special Interest Group on Data Communication (SIGCOMM '17). Association for Computing Machinery, New York, NY, USA,211‒224. https://doi.org/10.1145/3098822.3098844

343

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす

kerneluser• Sandstorm (SIGCOMM 2014)
ビデオストリーミング⽤サーバー（Sandstorm 拡張）- ディスクアクセス時にカーネルをバイパスする• mTCP (NSDI 2014)
diskmap
機構を追加
The
Atlas
Execution
Pipeline• Arrakis (OSDI 2014)- diskmap を netmap と統合して、ディスクからの読み取ったデータの配送を効率化• IX (OSDI 2014)• StackMap (USENIX ATC 2016)
webserver• Atlas (SIGCOMM 2017)
TCP/IP• ZygOS (SOSP 2017) NIC I/O と Disk I/O に
libnmiolibnvme
同じバッファが使える• Shenango (NSDI 2019)2
7
3 diskmap 6
netmap• Shinjuku (NSDI 2019) Disk から NIC への• TAS (EuroSys 2019) データの移動にコピーが不要buffers
4
5
1• Caladan (OSDI 2020)
NIC
NVMe Disk• Demikernel (SOSP 2021)
RX

TX

SQ

CQ

Ilias Marinos, Robert N.M. Watson, Mark Handley, and Randall R. Stewart. 2017. Disk|Crypt|Net: rethinking the stack for high-performance video streaming. In
Proceedings of the Conference of the ACM Special Interest Group on Data Communication (SIGCOMM '17). Association for Computing Machinery, New York, NY, USA,211‒224. https://doi.org/10.1145/3098822.3098844

344

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす

ビデオストリーミング⽤サーバー（Sandstorm 拡張）- ディスクアクセス時にカーネルをバイパスする
diskmap 機構を追加
Disk|Crypt|Net:
rethinking
the と統合して、ディスクからのstack for high-performance video streamin- diskmap を
netmap
読み取ったデータの配送を効率化
コンテンツ配送速度（２つの 40Gbps NIC 合計）
Net Throughput (Gb/s)• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

80
60
40
20

Netflix 0% BC
Netflix 100% BC
Atlas

0

2000 4000 6000 8000 10000 12000 14000 16000# Concurrent HTTP persistent connections(a) Network throughput (Error bars indicate the 95% CI)

Ilias Marinos, Robert N.M. Watson, Mark Handley, and Randall R. Stewart. 2017. Disk|Crypt|Net: rethinking the stack for high-performance video streaming. In
Proceedings of the Conference of the ACM Special Interest Group on Data Communication (SIGCOMM '17). Association for Computing Machinery, New York, NY, USA,211‒224. https://doi.org/10.1145/3098822.3098844

345

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす

ビデオストリーミング⽤サーバー（Sandstorm 拡張）- ディスクアクセス時にカーネルをバイパスする
Netflix機構を追加の最適化を含む FreeBSD との⽐較
diskmap
配送コンテンツのバッファキャッシュヒット率
Disk|Crypt|Net:
rethinking
the と統合して、ディスクからのstack for high-performance video streamin-BC:
diskmapを
netmap
読み取ったデータの配送を効率化
コンテンツ配送速度（２つの 40Gbps NIC 合計）
Net Throughput (Gb/s)• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

80
60
40
20

Netflix 0% BC
Netflix 100% BC
Atlas

0

2000 4000 6000 8000 10000 12000 14000 16000# Concurrent HTTP persistent connections(a) Network throughput (Error bars indicate the 95% CI)

Ilias Marinos, Robert N.M. Watson, Mark Handley, and Randall R. Stewart. 2017. Disk|Crypt|Net: rethinking the stack for high-performance video streaming. In
Proceedings of the Conference of the ACM Special Interest Group on Data Communication (SIGCOMM '17). Association for Computing Machinery, New York, NY, USA,211‒224. https://doi.org/10.1145/3098822.3098844% BC• パケットTCP/IP スタックを動かす
SIGCOMM ’17,I/O
Augustフレームワーク上で21-25, 2017, Los Angeles, CA, USA
⾼い性能を低いCPU
使⽤率で達成できる
実験時のCPU
使⽤率 2014)• Sandstorm(SIGCOMM• mTCP (NSDI 2014)• Arrakis (OSDI 2014)
600• IX (OSDI 2014)400• StackMap (USENIX ATC 2016)
Netflix 0% BC
200
Netflix 100% BC• Atlas (SIGCOMM 2017)
Atlas•0 ZygOS(SOSP 2017)2000 4000 6000 8000 10000 12000 14000 16000# Concurrent(NSDI
HTTP persistentconnections• Shenango
2019)(b) CPU utilization (Average)• Shinjuku(NSDI 2019)
CPU 使⽤率で⾼い性能を達成• 少ない
TAS (EuroSys
2019)
150
• Caladan (OSDI 2020)• Demikernel (SOSP 2021)
100
800

16000

ughput (Gb/s)

ns

ビデオストリーミング⽤サーバー（Sandstorm 拡張）- ディスクアクセス時にカーネルをバイパスする
Netflix機構を追加の最適化を含む FreeBSD との⽐較
diskmap
配送コンテンツのバッファキャッシュヒット率
Disk|Crypt|Net:
rethinking
the と統合して、ディスクからのstack for high-performance video streamin-BC:
diskmapを
netmap
読み取ったデータの配送を効率化
コンテンツ配送速度（２つの 40Gbps NIC 合計）
Net Throughput (Gb/s)% BC

TCP/IP スタック設計の再考

CPU utilization (%)

eo streaming

346

80
60
40
20

Netflix 0% BC
Netflix 100% BC
Atlas

0

2000 4000 6000 8000 10000 12000 14000 16000# Concurrent HTTP persistent connections(a) Network throughput (Error bars indicate the 95% CI)

347

研究紹介
TCP/IP スタック設計
パケット I/O フレームワークを適⽤する
各リクエストの処理時間の分散に配慮する

348
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

349
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

着眼点
既存のシステムはアプリへ届くリクエストにかかる処理時間のばらつきへの考慮が不⼗分

Head-of-Line Blocking 問題を引き起こす

350
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1

351
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1

CPU Core0 ⽤

CPU Core1 ⽤
アプリのリクエストキュー

352
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1

CPU Core0 ⽤

CPU Core1 ⽤
アプリのリクエストキュー

TCP/IP処理

TCP/IP処理

RSSによる
振り分け353
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1

CPU Core0 ⽤

CPU Core1 ⽤
アプリのリクエストキュー

TCP/IP処理

TCP/IP処理

RSSによる
振り分け354
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
処理完了まで• Shinjuku (NSDI 2019)
時間がかかるリクエスト• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1

CPU Core0 ⽤

CPU Core1 ⽤
アプリのリクエストキュー

TCP/IP処理

TCP/IP処理

RSSによる
振り分け

355
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
処理完了まで• Shinjuku (NSDI 2019)
時間がかかるリクエスト• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1

CPU Core0 ⽤

CPU Core1 ⽤
アプリのリクエストキュー

TCP/IP処理

TCP/IP処理

RSSによる
振り分け

短時間で処理が
完了できる
リクエスト

356
TCP/IP スタック設計の再考

順番に処理していくと• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
処理完了まで• Shinjuku (NSDI 2019)
時間がかかるリクエスト• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1

CPU Core0 ⽤

CPU Core1 ⽤
アプリのリクエストキュー

TCP/IP処理

TCP/IP処理

RSSによる
振り分け

短時間で処理が
完了できる
リクエスト

357
TCP/IP スタック設計の再考

順番に処理していくと• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
処理完了まで• Shinjuku (NSDI 2019)
時間がかかるリクエスト• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1 リクエストの処理完了

CPU Core0 ⽤

CPU Core1 ⽤
アプリのリクエストキュー

TCP/IP処理

TCP/IP処理

RSSによる
振り分け

短時間で処理が
完了できる
リクエスト

358
TCP/IP スタック設計の再考

順番に処理していくと• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
処理完了まで• Shinjuku (NSDI 2019)
時間がかかるリクエスト• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1 リクエストの処理完了

CPU Core0 ⽤

次のリクエスト
CPU Core1 ⽤ の処理を開始
アプリのリクエストキュー

TCP/IP処理

TCP/IP処理

RSSによる
振り分け

短時間で処理が
完了できる
リクエスト

359
TCP/IP スタック設計の再考

順番に処理していくと• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
処理完了まで• Shinjuku (NSDI 2019)
時間がかかるリクエスト• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1

CPU Core0 ⽤

CPU Core1 ⽤
アプリのリクエストキュー

TCP/IP処理

TCP/IP処理

RSSによる
振り分け

短時間で処理が
完了できる
リクエスト

360
TCP/IP スタック設計の再考

順番に処理していくと• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
処理完了まで• Shinjuku (NSDI 2019)
時間がかかるリクエスト• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1

CPU Core0 ⽤

CPU Core1 ⽤
アプリのリクエストキュー

TCP/IP処理

TCP/IP処理

RSSによる
振り分け

短時間で処理が
完了できる
リクエスト

361
TCP/IP スタック設計の再考

順番に処理していくと• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
処理完了まで• Shinjuku (NSDI 2019)
時間がかかるリクエスト• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1

CPU Core0 ⽤

CPU Core1 ⽤
アプリのリクエストキュー

TCP/IP処理

TCP/IP処理

RSSによる
振り分け

短時間で処理が
完了できる
リクエスト

362
TCP/IP スタック設計の再考

順番に処理していくと• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
処理完了まで• Shinjuku (NSDI 2019)
時間がかかるリクエスト• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1

CPU Core0 ⽤

CPU Core1 ⽤
アプリのリクエストキュー

TCP/IP処理

TCP/IP処理

RSSによる
振り分け

短時間で処理が
完了できる
リクエスト

363
TCP/IP スタック設計の再考

順番に処理していくと• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
処理完了まで• Shinjuku (NSDI 2019)
時間がかかるリクエスト• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1

CPU Core0 ⽤

CPU Core1 ⽤
アプリのリクエストキュー

TCP/IP処理

TCP/IP処理

RSSによる
振り分け

短時間で処理が
完了できる
リクエスト

364
TCP/IP スタック設計の再考

順番に処理していくと• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
処理完了まで• Shinjuku (NSDI 2019)
時間がかかるリクエスト• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1

CPU Core0 ⽤

CPU Core1 ⽤
アプリのリクエストキュー

TCP/IP処理

TCP/IP処理

RSSによる
振り分け

短時間で処理が
完了できる
リクエスト

365
TCP/IP スタック設計の再考

順番に処理していくと• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1

CPU Core0 ⽤

CPU Core1 ⽤

処理完了まで時間がかかるリクエストに処理の開始がブロックされている アプリのリクエストキュークライアントの体感する遅延の増加に繋がる
TCP/IP処理

TCP/IP処理

RSSによる
振り分け366
TCP/IP スタック設計の再考

順番に処理していくと• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリスレッドon CPU Core0

アプリスレッドon CPU Core1
CPU Core1 は idle 状態

CPU Core0 ⽤

CPU Core1 ⽤

処理完了まで時間がかかるリクエストに処理の開始がブロックされている アプリのリクエストキュークライアントの体感する遅延の増加に繋がる
TCP/IP処理

TCP/IP処理

RSSによる
振り分け367
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす
アプリスレッド
アプリスレッド• Sandstorm (SIGCOMM 2014)
on CPU Core0on CPU Core1• mTCP (NSDI 2014)• Arrakis (OSDI 2014)
CPU Core1 ⽤
CPU Core0 ⽤• IX (OSDI 2014)• StackMap (USENIX ATC 2016)
アプリのリクエストキュー• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
TCP/IP処理
TCP/IP処理• Shinjuku (NSDI 2019)
提案⼿法：• TAS (EuroSys 2019)
Shuffle 層を追加
RSSによる• Caladan (OSDI 2020)振り分け• Demikernel (SOSP 2021)

368
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす
アプリスレッド
アプリスレッド• Sandstorm (SIGCOMM 2014)
on CPU Core0on CPU Core1• mTCP (NSDI 2014)
shuffle• Arrakis (OSDI 2014)
CPU Core1 ⽤
CPU Core0 ⽤• IX (OSDI 2014)• StackMap (USENIX ATC 2016)
アプリのリクエストキュー• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
TCP/IP処理
TCP/IP処理• Shinjuku (NSDI 2019)
提案⼿法：• TAS (EuroSys 2019)
Shuffle 層を追加
RSSによる• Caladan (OSDI 2020)振り分け• Demikernel (SOSP 2021)

369
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす
アプリスレッド
アプリスレッド• Sandstorm (SIGCOMM 2014)
on CPU Core0on CPU Core1• mTCP (NSDI 2014)
shuffle• Arrakis (OSDI 2014)
CPU Core1 ⽤
CPU Core0 ⽤• IX (OSDI 2014)• StackMap (USENIX ATC 2016)
アプリのリクエストキュー• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
TCP/IP処理
TCP/IP処理• Shinjuku (NSDI 2019)
提案⼿法：• TAS (EuroSys 2019)
Shuffle 層を追加
RSSによる• Caladan (OSDI 2020)振り分け• Demikernel (SOSP 2021)

370
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす
アプリスレッド
アプリスレッド• Sandstorm (SIGCOMM 2014)
on CPU Core0on CPU Core1• mTCP (NSDI 2014)
shuffle• Arrakis (OSDI 2014)
CPU Core1 ⽤
CPU Core0 ⽤• IX (OSDI 2014)• StackMap (USENIX ATC 2016)
アプリのリクエストキュー• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
TCP/IP処理
TCP/IP処理• Shinjuku (NSDI 2019)
提案⼿法：• TAS (EuroSys 2019)
Shuffle 層を追加
RSSによる• Caladan (OSDI 2020)振り分け• Demikernel (SOSP 2021)

371
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす
アプリスレッド
アプリスレッド• Sandstorm (SIGCOMM 2014)
on CPU Core0on CPU Core1
Core1が idle に• mTCP (NSDI 2014)
shuffle• Arrakis (OSDI 2014)
CPU Core1 ⽤
CPU Core0 ⽤• IX (OSDI 2014)• StackMap (USENIX ATC 2016)
アプリのリクエストキュー• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
TCP/IP処理
TCP/IP処理• Shinjuku (NSDI 2019)
提案⼿法：• TAS (EuroSys 2019)
Shuffle 層を追加
RSSによる• Caladan (OSDI 2020)振り分け• Demikernel (SOSP 2021)

372
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす
アプリスレッド
アプリスレッド• Sandstorm (SIGCOMM 2014)
on CPU Core0on CPU Core1
Core1が idle に• mTCP (NSDI 2014)
shuffle• Arrakis (OSDI 2014)
CPU Core1 ⽤
CPU Core0 ⽤• IX (OSDI 2014)
Shuffle 層を通じた• StackMap (USENIX ATC 2016)
work-stealing
アプリのリクエストキュー• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
TCP/IP処理
TCP/IP処理• Shinjuku (NSDI 2019)
提案⼿法：• TAS (EuroSys 2019)
Shuffle 層を追加
RSSによる• Caladan (OSDI 2020)振り分け• Demikernel (SOSP 2021)

George Prekas, Marios Kogias, and Edouard Bugnion. 2017. ZygOS: Achieving Low Tail Latency for Microsecond-Scale Networked Tasks. In Proceedings of the 26th
Symposium on Operating Systems Principles (SOSP ʼ17), 325-341.(https://doi.org/10.1145/3132747.3132780)

373

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かすLinux (partitioned connections)

SLO

Linux (floating connections)

IX

150

Latency (us)• Sandstorm (SIGCOMM 2014)
Linux (partitioned connections)• mTCPSLO(NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

125
100

IX

ZygOS

Bimodal
150
125
100

75
50

75
50

リクエストの分布25
25 ９割：短時間で完了するリクエスト
１割：時間を要するリクエスト
0
0.0
0.5
1.0
1
0
0.0
0.5
1.0
1.5
Throughput(MRPS)

Throughput (MRPS)

George Prekas, Marios Kogias, and Edouard Bugnion. 2017. ZygOS: Achieving Low Tail Latency for Microsecond-Scale Networked Tasks. In Proceedings of the 26th
Symposium on Operating Systems Principles (SOSP ʼ17), 325-341.(https://doi.org/10.1145/3132747.3132780)

374

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす

Latency (us)Linux (partitioned connections)• Sandstorm (SIGCOMM 2014)
SLO
IX
Linux (floating connections)
ZygOS
Linux (partitioned connections)• mTCPSLO(NSDI 2014)
IX
150• Arrakis (OSDI 2014)
Bimodal150• IX (OSDI 2014)125• StackMap (USENIX ATC 2016)
125
100• Atlas (SIGCOMM 2017)
100
75• ZygOS (SOSP 2017)75
拡張• Shenango (NSDI 2019)50
50
リクエストの分布• Shinjuku (NSDI 2019)25
25 ９割：短時間で完了するリクエスト
１割：時間を要するリクエスト• TAS (EuroSys 2019)
IX と⽐較して
0
0.0
0.5
1.0
1
⾼いスループット
0• Caladan (OSDI 2020)
0.0
0.5
1.0
1.5
Throughput(MRPS)
Throughput (MRPS)• Demikernel (SOSP 2021)

George Prekas, Marios Kogias, and Edouard Bugnion. 2017. ZygOS: Achieving Low Tail Latency for Microsecond-Scale Networked Tasks. In Proceedings of the 26th
Symposium on Operating Systems Principles (SOSP ʼ17), 325-341.(https://doi.org/10.1145/3132747.3132780)

375

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす

Latency (us)Linux (partitioned connections)• Sandstorm (SIGCOMM 2014)
SLO
IX
Linux (floating connections)
ZygOS
Linux (partitioned connections)• mTCPSLO(NSDI 2014)
IX
150• Arrakis (OSDI 2014)
Bimodal150• IX (OSDI 2014)125• StackMap (USENIX ATC 2016)
125
100• Atlas (SIGCOMM 2017)
100
75• ZygOS (SOSP 2017)75
拡張• Shenango (NSDI 2019)50
50
リクエストの分布• Shinjuku (NSDI 2019)25
25 ９割：短時間で完了するリクエスト
１割：時間を要するリクエスト• TAS (EuroSys 2019)
IX と⽐較して
0
0.0
0.5
1.0
1
⾼いスループット
0• Caladan (OSDI 2020)
0.0
0.5
1.0
1.5
Throughput(MRPS)
低い遅延を達成
Throughput (MRPS)• Demikernel (SOSP 2021)

376
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019) 拡張• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

377
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす
アプリスレッド
アプリスレッド• Sandstorm (SIGCOMM 2014)
on CPU Core0on CPU Core1
Core1が idle に• mTCP (NSDI 2014)
shuffle• Arrakis (OSDI 2014)
CPU Core1 ⽤
CPU Core0 ⽤• IX (OSDI 2014)
Shuffle 層を通じた• StackMap (USENIX ATC 2016)
work-stealing
アプリのリクエストキュー• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
拡張• Shenango (NSDI 2019)
TCP/IP処理
TCP/IP処理• Shinjuku (NSDI 2019)
提案⼿法：• TAS (EuroSys 2019)
Shuffle 層を追加
RSSによる• Caladan (OSDI 2020)振り分け• Demikernel (SOSP 2021)

378
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす
アプリスレッド
アプリスレッド• Sandstorm (SIGCOMM 2014)
on CPU Core0on CPU Core1• mTCP (NSDI 2014)
shuffle• Arrakis (OSDI 2014)
CPU Core1 ⽤
CPU Core0 ⽤• IX (OSDI 2014)• StackMap (USENIX ATC 2016)
アプリのリクエストキュー• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019) 拡張
TCP/IP処理
TCP/IP処理• Shinjuku (NSDI 2019)問題：• TAS (EuroSys 2019) 全部のコアに時間のかかる
RSSによる• Caladan (OSDI 2020)リクエストが来ると振り分け
Work-stealing できない
• Demikernel (SOSP 2021)

379
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014) アプリスレッド アプリスレッド
on CPU Core0on CPU Core1• mTCP (NSDI 2014)
CPU Core1 ⽤
CPU Core0 ⽤• Arrakis (OSDI 2014)• IX (OSDI 2014)
アプリの
リクエスト
• StackMap (USENIX ATC 2016)
キュー• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
提案⼿法• Shenango (NSDI 2019) 拡張
ディスパッチャスレッドが• Shinjuku (NSDI 2019)
リクエストを振り分ける• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

ディスパッチャスレッド
on CPU Core2

通信処理実⾏スレッド
on CPU Core3
TCP/IP処理

380
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014) アプリスレッド アプリスレッド
on CPU Core0on CPU Core1• mTCP (NSDI 2014)
CPU Core1 ⽤
CPU Core0 ⽤• Arrakis (OSDI 2014)• IX (OSDI 2014)
アプリの
リクエスト
• StackMap (USENIX ATC 2016)
キュー• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
提案⼿法• Shenango (NSDI 2019) 拡張
ディスパッチャスレッドが• Shinjuku (NSDI 2019)
リクエストを振り分ける• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

ディスパッチャスレッド
on CPU Core2

通信処理実⾏スレッド
on CPU Core3
TCP/IP処理

381
TCP/IP スタック設計の再考

割り込み• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014) アプリスレッド アプリスレッド
ディスパッチャon CPU Core0on CPU Core1
スレッド• mTCP (NSDI 2014)
CPU Core1 ⽤
CPU Core0 ⽤
on CPU Core2• Arrakis (OSDI 2014)• IX (OSDI 2014)
アプリの
リクエスト
• StackMap (USENIX ATC 2016)
キュー
通信処理実⾏• Atlas (SIGCOMM 2017)スレッド
on CPU Core3• ZygOS (SOSP 2017)
提案⼿法• Shenango (NSDI 2019) 拡張
TCP/IP処理• Shinjuku (NSDI 2019)
ディスパッチャはアプリスレッドが• TAS (EuroSys 2019)⻑時間同じリクエストを処理し続けていと• Caladan (OSDI 2020)
割り込みを送って、そのコアで別の• Demikernel (SOSP 2021) リクエストの処理に切り替えるよう指⽰する

382
TCP/IP スタック設計の再考

割り込み• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014) アプリスレッド アプリスレッド
ディスパッチャon CPU Core0on CPU Core1
スレッド• mTCP (NSDI 2014)
CPU Core1 ⽤
CPU Core0 ⽤
on CPU Core2• Arrakis (OSDI 2014)• IX (OSDI 2014)
アプリの
リクエスト
• StackMap (USENIX ATC 2016)
キュー
通信処理実⾏• Atlas (SIGCOMM 2017)スレッド
on CPU Core3• ZygOS (SOSP 2017)
提案⼿法• Shenango (NSDI 2019) 拡張
TCP/IP処理• Shinjuku (NSDI 2019)
ディスパッチャはアプリスレッドが• TAS (EuroSys 2019)⻑時間同じリクエストを処理し続けていと• Caladan (OSDI 2020)
割り込みを送って、そのコアで別の• Demikernel (SOSP 2021) リクエストの処理に切り替えるよう指⽰する

383
TCP/IP スタック設計の再考

割り込み• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014) アプリスレッド アプリスレッド
ディスパッチャon CPU Core0on CPU Core1
スレッド• mTCP (NSDI 2014)
CPU Core1 ⽤
CPU Core0 ⽤
on CPU Core2• Arrakis (OSDI 2014)• IX (OSDI 2014)
アプリの
リクエスト
• StackMap (USENIX ATC 2016)
キュー
通信処理実⾏• Atlas (SIGCOMM 2017)スレッド
on CPU Core3• ZygOS (SOSP 2017)
提案⼿法• Shenango (NSDI 2019) 拡張
TCP/IP処理
切り替え判断は 5us おきに⾏われる• Shinjuku (NSDI 2019)
ディスパッチャはアプリスレッドが• TAS (EuroSys 2019)⻑時間同じリクエストを処理し続けていと• Caladan (OSDI 2020)
割り込みを送って、そのコアで別の• Demikernel (SOSP 2021) リクエストの処理に切り替えるよう指⽰する

384

Kostis Kaffes, Timothy Chong, Jack Tigar Humphries, Adam Belay, David Mazières, and Christos Kozyrakis. 2019. Shinjuku: Preemptive Scheduling for μsecond-scale
Tail Latency. In 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19), 345360.(https://www.usenix.org/conference/nsdi19/presentation/kaffes)

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす
Shinjuku under high variability
RocksDB
99.5% GET - 5us
0.5% SCAN - 250us

IX and ZygOS: Taillatency determined by
SCAN requests

6.6x
Better• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019) 拡張• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

88% lower
Better

26

385

研究紹介
TCP/IP スタック設計
パケット I/O フレームワークを適⽤する
様々なワークロードを⼀つのサーバーで動かしつつ遅延が重要なアプリが⽬標の応答性能を達成できるようにする

386
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

要件
⾊々なワークロードを⼀つのサーバーで動かしたい- 低遅延が重要なワークロード (Key-Value Store 等)- CPU を消費するワークロード (Hadoop, Spark 等)

387
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

要件
⾊々なワークロードを⼀つのサーバーで動かしたい- 低遅延が重要なワークロード (Key-Value Store 等)- CPU を消費するワークロード (Hadoop, Spark 等)

Key-ValueStore

Key-ValueStore

Key-ValueStore

Hadoop

Spark

Spark

388
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)
要件• mTCP (NSDI 2014)
⾊々なワークロードを⼀つのサーバーで動かしたい• Arrakis (OSDI 2014)- 低遅延が重要なワークロード (Key-Value Store 等)• IX (OSDI 2014)- CPU を消費するワークロード (Hadoop, Spark 等)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)
Key-Value
Key-Value
Key-Value• ZygOS (SOSP 2017)
Store
Store
Store
• Shenango (NSDI 2019)
Spark
HadoopSpark• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)
CPU の専有を想定した• Caladan (OSDI 2020)
DPDK のようなシステムとの• Demikernel (SOSP 2021) 組み合わせが広まる389
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)
要件• mTCP (NSDI 2014)
⾊々なワークロードを⼀つのサーバーで動かしたい• Arrakis (OSDI 2014)- 低遅延が重要なワークロード (Key-Value Store 等)• IX (OSDI 2014)- CPU を消費するワークロード (Hadoop, Spark 等)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
Key-Value
Key-Value
Key-Value
Store
Store
Store
• Shenango (NSDI 2019)+ DPDK+ DPDK+ DPDK• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)
CPU の専有を想定した• Caladan (OSDI 2020)
DPDK のようなシステムとの• Demikernel (SOSP 2021) 組み合わせが広まる

390
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)
要件• mTCP (NSDI 2014)
⾊々なワークロードを⼀つのサーバーで動かしたい• Arrakis (OSDI 2014)- 低遅延が重要なワークロード (Key-Value Store 等)• IX (OSDI 2014)- CPU を消費するワークロード (Hadoop, Spark 等)• StackMap (USENIX ATC 2016)問題：DPDK 等に CPU を占有させるとHadoop, Spark 等のワークロードへ割り当てるCPU サイクルがなくなる• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
Key-Value
Key-Value
Key-Value
Store
Store
Store
• Shenango (NSDI 2019)+ DPDK+ DPDK+ DPDK• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)
CPU の専有を想定した• Caladan (OSDI 2020)
DPDK のようなシステムとの• Demikernel (SOSP 2021) 組み合わせが広まる391
TCP/IP スタック設計の再考

⽬的

低遅延が重要なワークロードに適切な数の CPU コアを割り当てられるようにしたい• パケット I/O フレームワーク上で
TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)
要件• mTCP (NSDI 2014)
⾊々なワークロードを⼀つのサーバーで動かしたい• Arrakis (OSDI 2014)- 低遅延が重要なワークロード (Key-Value Store 等)• IX (OSDI 2014)- CPU を消費するワークロード (Hadoop, Spark 等)• StackMap (USENIX ATC 2016)問題：DPDK 等に CPU を占有させるとHadoop, Spark 等のワークロードへ割り当てるCPU サイクルがなくなる• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
Key-Value
Key-Value
Key-Value
Store
Store
Store
• Shenango (NSDI 2019)+ DPDK+ DPDK+ DPDK• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)
CPU の専有を想定した• Caladan (OSDI 2020)
DPDK のようなシステムとの• Demikernel (SOSP 2021) 組み合わせが広まる392
TCP/IP スタック設計の再考

⽬的

低遅延が重要なワークロードに適切な数の CPU コアを割り当てられるようにしたい• パケット I/O フレームワーク上で
TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)
要件• mTCP (NSDI 2014)
⾊々なワークロードを⼀つのサーバーで動かしたい• Arrakis (OSDI 2014)- 低遅延が重要なワークロード(Key-Value Store 等)
Key-Value Store へのリクエストが少ない時• IX (OSDI 2014)- CPU を消費するワークロード (Hadoop, Spark 等)• StackMap (USENIX ATC 2016)問題：DPDK 等に CPU を占有させるとHadoop, Spark 等のワークロードへ割り当てるCPU サイクルがなくなる• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
Key-Value
HadoopStore
Spark• Shenango (NSDI 2019)+ DPDKSpark• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)
CPU の専有を想定した• Caladan (OSDI 2020)
DPDK のようなシステムとの• Demikernel (SOSP 2021) 組み合わせが広まる393
TCP/IP スタック設計の再考

⽬的

低遅延が重要なワークロードに適切な数の CPU コアを割り当てられるようにしたい• パケット I/O フレームワーク上で
TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)
要件• mTCP (NSDI 2014)
⾊々なワークロードを⼀つのサーバーで動かしたい• Arrakis (OSDI 2014)- 低遅延が重要なワークロード(Key-Value Store 等)
Key-Value Store へのリクエストが多い時• IX (OSDI 2014)- CPU を消費するワークロード (Hadoop, Spark 等)• StackMap (USENIX ATC 2016)問題：DPDK 等に CPU を占有させるとHadoop, Spark 等のワークロードへ割り当てるCPU サイクルがなくなる• Atlas (SIGCOMM 2017)
Hadoop• ZygOS (SOSP 2017)
Key-Value
Key-Value
Store
Store
Spark
• Shenango (NSDI 2019)+ DPDK+ DPDKSpark• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)
CPU の専有を想定した• Caladan (OSDI 2020)
DPDK のようなシステムとの• Demikernel (SOSP 2021) 組み合わせが広まる394
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリプロセス
パケット
RUNNABLE キュー
threadRUNNABLE
threadIOKernel

395
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)
アプリプロセス• IX (OSDI 2014)
パケット• StackMap (USENIX ATC 2016) RUNNABLE キュー
thread• Atlas (SIGCOMM 2017)
RUNNABLE
thread• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)
IOKernel• TAS (EuroSys 2019)
アプリプロセスに属する• Caladan (OSDI 2020)
実⾏可能なスレッドと• Demikernel (SOSP 2021)
パケットキューを監視

396
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)
アプリプロセス• IX (OSDI 2014)
パケット• StackMap (USENIX ATC 2016) RUNNABLE キュー
thread• Atlas (SIGCOMM 2017)
RUNNABLE
thread• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)
IOKernel• TAS (EuroSys 2019)
アプリプロセスに属する• Caladan (OSDI 2020)
実⾏可能なスレッドと• Demikernel (SOSP 2021)
パケットキューを監視

実⾏可能なスレッドや処理されていないパケットがあれば、アプリが利⽤可能なCPU コアを追加

397
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)
アプリプロセス• IX (OSDI 2014)
パケット• StackMap (USENIX ATC 2016) RUNNABLE キュー
実⾏可能なスレッドやthread処理されていないパケットが• Atlas (SIGCOMM 2017)
RUNNABLE
あれば、アプリが利⽤可能な
thread• ZygOS (SOSP 2017)
CPU コアを追加• Shenango (NSDI 2019)
5us ごとにコア数の調整• Shinjuku (NSDI 2019)
IOKernel• TAS (EuroSys 2019)
アプリプロセスに属する• Caladan (OSDI 2020)
実⾏可能なスレッドと• Demikernel (SOSP 2021)
パケットキューを監視

398
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)
アプリプロセス• IX (OSDI 2014)
パケット
RUNNABLE• StackMap (USENIX ATC 2016) RUNNABLE キュー
threadthread• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)
5us ごとにコア数の調整• Shinjuku (NSDI 2019)
IOKernel• TAS (EuroSys 2019)
アプリプロセスに属する• Caladan (OSDI 2020)
実⾏可能なスレッドと• Demikernel (SOSP 2021)
パケットキューを監視399

Amy Ousterhout, Joshua Fried, Jonathan Behrens, Adam Belay, and Hari Balakrishnan. 2019. Shenango: Achieving High CPU Efficiency for Latency-Sensitive
Datacenter Workloads. In 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19), 361378.(https://www.usenix.org/conference/nsdi19/presentation/ousterhout)

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす

Median Latency (μs)

99.9% Latency (μs)

Linux

Batch Ops/s• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019) Memcached と
PARSEC swaptions• TAS (EuroSys 2019)を実⾏• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

ArachneShenango

ZygOS

400
300
200
100
0
0

2

4

6

0

2

4

6

0

2

4

6

60
40
20
0

100
75
50
25
0

Memcached Offered Load (million requests/s)

400

Amy Ousterhout, Joshua Fried, Jonathan Behrens, Adam Belay, and Hari Balakrishnan. 2019. Shenango: Achieving High CPU Efficiency for Latency-Sensitive
Datacenter Workloads. In 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19), 361378.(https://www.usenix.org/conference/nsdi19/presentation/ousterhout)

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす

Median Latency (μs)

99.9% Latency (μs)

Linux

Batch Ops/s• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019) Memcached と
PARSEC swaptions• TAS (EuroSys 2019)を実⾏• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

ArachneShenango

ZygOS

400

ZygOS と近い
スループットと低遅延

300
200
100
0
0

2

4

6

0

2

4

6

0

2

4

6

60
40
20
0

100
75
50
25
0

Memcached Offered Load (million requests/s)

401

Amy Ousterhout, Joshua Fried, Jonathan Behrens, Adam Belay, and Hari Balakrishnan. 2019. Shenango: Achieving High CPU Efficiency for Latency-Sensitive
Datacenter Workloads. In 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19), 361378.(https://www.usenix.org/conference/nsdi19/presentation/ousterhout)

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす

Batch Ops/s

Median Latency (μs)

99.9% Latency (μs)

Linux
ArachneShenango
ZygOS• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)
ZygOS はバッチ処理 (PARSEC swaptions) に• Shinjuku (NSDI 2019) Memcached と
PARSEC swaptions 費やせる CPU サイクルはない• TAS (EuroSys 2019)を実⾏• Caladan (OSDI 2020)• Demikernel (SOSP 2021)
Memcached Offered Load (million requests/s)
400
300
200
100
0

0

2

4

6

0

2

4

6

0

2

4

6

60
40
20

0

100
75
50
25

0

402

Amy Ousterhout, Joshua Fried, Jonathan Behrens, Adam Belay, and Hari Balakrishnan. 2019. Shenango: Achieving High CPU Efficiency for Latency-Sensitive
Datacenter Workloads. In 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19), 361378.(https://www.usenix.org/conference/nsdi19/presentation/ousterhout)

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす

Batch Ops/s

Median Latency (μs)

99.9% Latency (μs)

Linux
ArachneShenango
ZygOS• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
Shenango は Memcached ロードが低い時に• Shenango (NSDI 2019)
バッチ処理 (PARSEC swaptions) を実⾏できる
Memcachedと• Shinjuku (NSDI 2019)
PARSEC swaptions• TAS (EuroSys 2019)を実⾏• Caladan (OSDI 2020)• Demikernel (SOSP 2021)
Memcached Offered Load (million requests/s)
400
300
200
100
0

0

2

4

6

0

2

4

6

0

2

4

6

60
40
20

0

100
75
50
25

0

403
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)• Arrakis (OSDI 2014)• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)• TAS (EuroSys 2019)
拡張• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリ１

アプリ２

アプリ３

アプリ４

Hyper
ThreadHyper
ThreadHyper
ThreadHyper
Thread

キャッシュ

キャッシュ

404
TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)
アプリ１
アプリ２
• mTCP (NSDI 2014)
Hyper
Hyper
• Arrakis (OSDI 2014)
ThreadThread• IX (OSDI 2014)• StackMap (USENIX ATC 2016)• Atlas (SIGCOMM 2017)
キャッシュ• ZygOS (SOSP 2017)• Shenango (NSDI 2019)• Shinjuku (NSDI 2019)
アプリのワークロード
によって⼲渉が発⽣する• TAS (EuroSys 2019)
拡張• Caladan (OSDI 2020)• Demikernel (SOSP 2021)

アプリ３

アプリ４

Hyper
ThreadHyper
Threadキャッシュ

Joshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on
Operating Systems Design and Implementation (OSDI 20), 281-297.(https://www.usenix.org/conference/osdi20/presentation/fried)

405

TCP/IP スタック設計の再考

Interference
ExampleGarbageCollection
を⾏うタスクと、Memcachedを同じマシンで動かす場合• パケット
I/O
フレームワーク上で
TCP/IP
スタックを動かす

Better

99.9% Lat. (μs)

0em. %/W (%)• Sandstorm100(SIGCOMM 2014)
Garbage• mTCP (NSDI 2014)
アプリ３
アプリ１
アプリ４
アプリ２
Collection• Arrakis (OSDI
50 2014)
Hyper
Hyper
Hyper
Hyper
GC Task
ThreadThread• 20IXcores(OSDI 2014)
ThreadThread0• StackMap (USENIX
ATC
2016)
0
1
2
3
4
5
6
• Atlas (SIGCOMM 2017)
Time (s)105 2017)• ZygOS (SOSP
Memcached
キャッシュ
cores
1000 x キャッシュ104• 2Shenango
(NSDI
2019)
latency• Shinjuku (NSDI
2019)
103
increase
2• TAS (EuroSys
10 2019)
アプリのワークロード
によって⼲渉が発⽣する• Caladan (OSDI
2020)
0
1
2
3
4
5
6
TLme (s)拡張• zIO (OSDI 2021)
6
Collectionが動くとメモリ帯域が⼲渉してMemcached の応答遅延が増加する•Garbage
Demikernel
(SOSP
2021)

Joshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on
Operating Systems Design and Implementation (OSDI 20), 281-297.(https://www.usenix.org/conference/osdi20/presentation/fried)

TCP/IP スタック設計の再考

406

⽬的：このような⼲渉を避けて、遅延が重要なシステムの遅延が⼀定以上を越えないようにしたいInterference
ExampleGarbageCollection
を⾏うタスクと、Memcachedを同じマシンで動かす場合• パケット
I/O
フレームワーク上で
TCP/IP
スタックを動かす

Better

99.9% Lat. (μs)

0em. %/W (%)• Sandstorm100(SIGCOMM 2014)
Garbage• mTCP (NSDI 2014)
アプリ３
アプリ１
アプリ４
アプリ２
Collection• Arrakis (OSDI
50 2014)
Hyper
Hyper
Hyper
Hyper
GC Task
ThreadThread• 20IXcores(OSDI 2014)
ThreadThread0• StackMap (USENIX
ATC
2016)
0
1
2
3
4
5
6
• Atlas (SIGCOMM 2017)
Time (s)105 2017)• ZygOS (SOSP
Memcached
キャッシュ
cores
1000 x キャッシュ104• 2Shenango
(NSDI
2019)
latency• Shinjuku (NSDI
2019)
103
increase
2• TAS (EuroSys
10 2019)
アプリのワークロード
によって⼲渉が発⽣する• Caladan (OSDI
2020)
0
1
2
3
4
5
6
TLme (s)拡張• zIO (OSDI 2021)
6
Collectionが動くとメモリ帯域が⼲渉してMemcached の応答遅延が増加する•Garbage
Demikernel
(SOSP
2021)

Joshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on
Operating Systems Design and Implementation (OSDI 20), 281-297.(https://www.usenix.org/conference/osdi20/presentation/fried)

407

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014){Work Stealing}• mTCP (NSDI 2014)
Task 1
Task 2
Unallocated• Arrakis (OSDI 2014)
Runtime
Runtime• IX (OSDI 2014)kschedkschedkschedkschedkschedksched• StackMap (USENIX ATC 2016)
Core 1
Core 2
Core 3
Core 4
Core 5
Core 6• Atlas (SIGCOMM 2017){Core Allocation}• ZygOS (SOSP 2017)
Shared Memory• Shenango (NSDI 2019)
Scheduler
DRAM
ioctl()
Controller• Shinjuku (NSDI 2019)(PCIe)
kschedCore 0• TAS (EuroSys 2019)
拡張
Figure 2: Caladan’s system architecture. Caladan relies on a sched• Caladan (OSDI 2020)• Demikernel (SOSP 2021) uler core to gather control signals from shared memory regions

Joshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on
Operating Systems Design and Implementation (OSDI 20), 281-297.(https://www.usenix.org/conference/osdi20/presentation/fried)

408

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014){Work Stealing}• mTCP (NSDI 2014)
Task 1
Task 2
Unallocated• Arrakis (OSDI 2014)
Runtime
Runtime• IX (OSDI 2014)kschedkschedkschedkschedkschedksched• StackMap (USENIX ATC 2016)
Core 1
Core 2
Core 3
Core 4
Core 5
Core 6• Atlas (SIGCOMM 2017){Core Allocation}• ZygOS (SOSP 2017)
Shared Memory• Shenango (NSDI 2019)
Scheduler
DRAM
ioctl()
Controller• Shinjuku (NSDI 2019)(PCIe)
kschedCore 0• TAS (EuroSys 2019)
拡張
Figure 2:Caladan
Caladan’ssystem architecture.
Caladanrelies on a sched• Caladan (OSDI 2020)
scheduler
が Caladan
ランタイム環境とto gather
control signals from shared memory regions
コントローラーのカウンタを通して⼲渉を検知• Demikernel (SOSP 2021) uler coreDRAMJoshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on
Operating Systems Design and Implementation (OSDI 20), 281-297.(https://www.usenix.org/conference/osdi20/presentation/fried)

409

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014){Work Stealing}• mTCP (NSDI 2014)
Task 1
Task 2
Unallocated• Arrakis (OSDI 2014)
Runtime
Runtime• IX (OSDI 2014)kschedkschedkschedkschedkschedksched• StackMap (USENIX ATC 2016)
Core 1
Core 2
Core 3
Core 4
Core 5
Core 6• Atlas (SIGCOMM 2017){Core Allocation}• ZygOS (SOSP 2017)
Shared Memory• Shenango (NSDI 2019)
Scheduler
DRAM
ioctl()
Controller• Shinjuku (NSDI 2019)(PCIe)
kschedCore 0• TAS (EuroSys 2019)
拡張
Figure 2:Caladan
Caladan’ssystem architecture.
Caladanrelies on a sched• Caladan (OSDI 2020)
schedulerと Caladan
ランタイム環境は
to gather control signals from shared memory regions• Demikernel (SOSP 2021) uler core共有メモリを通じて情報をやりとりするJoshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on
Operating Systems Design and Implementation (OSDI 20), 281-297.(https://www.usenix.org/conference/osdi20/presentation/fried)

410

TCP/IP スタック設計の再考
Mitigating Interference

Signals スタックを動かす
Actions• パケット I/O フレームワーク上で TCP/IP• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014){Work Stealing}
DRAM
RevokeDirect• Arrakis (OSDI
2014)
Task 1
Unallocated
DRAM
Bandwidthcores from Task 2
LLC Misses• IX (OSDI 2014) Interference
Bandwidth
antagonist Runtime
Runtime• StackMap (USENIX ATC 2016)
task kschedkschedkschedkschedkschedksched• Atlas (SIGCOMM 2017)
Core 1
Core 2
Core 3
Core 4
Core 5
Core 6Hyperthread
RequestRemove{Core Allocation}• ZygOS (SOSP 2017)
Interference
Processing
task onShared Memory• Shenango (NSDI 2019)Times
sibling core
• Shinjuku (NSDI 2019)
Scheduler
DRAM
ioctl()
Controller• TAS (EuroSys
2019)(PCIe)
kschedIndirect LLC and other• Caladan (OSDIinterference,
2020)
Core 0 Add core to
Queueing
victimrelies on a sched• zIO (OSDI 2021)load changes 拡張 FigureDelay
2:Caladan
Caladan’ssystem architecture.
Caladanschedulerと Caladan
ランタイム環境は• Demikernel (SOSP 2021) uler core共有メモリを通じて情報をやりとりする
to gather control signals from shared memory regions+

17

Joshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on
Operating Systems Design and Implementation (OSDI 20), 281-297.(https://www.usenix.org/conference/osdi20/presentation/fried)

411

TCP/IP スタック設計の再考
Mitigating Interference

Signals スタックを動かす
Actions• パケット I/O フレームワーク上で TCP/IP

メモリ帯域の⼲渉は DRAM コントローラーの• Sandstorm (SIGCOMM 2014)
カウンタとキャッシュミスから検知• mTCP (NSDI 2014){Work Stealing}
DRAM
RevokeDirect• Arrakis (OSDI
2014)
Task 1
Unallocated
DRAM
Bandwidthcores from Task 2
LLC Misses• IX (OSDI 2014) Interference
Bandwidth
antagonist Runtime
Runtime• StackMap (USENIX ATC 2016)
task kschedkschedkschedkschedkschedksched• Atlas (SIGCOMM 2017)
Core 1
Core 2
Core 3
Core 4
Core 5
Core 6Hyperthread
RequestRemove{Core Allocation}• ZygOS (SOSP 2017)
Interference
Processing
task onShared Memory• Shenango (NSDI 2019)Times
sibling core
• Shinjuku (NSDI 2019)
Scheduler
DRAM
ioctl()
Controller• TAS (EuroSys
2019)(PCIe)
kschedIndirect LLC and other• Caladan (OSDIinterference,
2020)
Core 0 Add core to
Queueing
victimrelies on a sched• zIO (OSDI 2021)load changes 拡張 FigureDelay
2:Caladan
Caladan’ssystem architecture.
Caladanschedulerと Caladan
ランタイム環境は• Demikernel (SOSP 2021) uler core共有メモリを通じて情報をやりとりする
to gather control signals from shared memory regions+

17

Joshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on
Operating Systems Design and Implementation (OSDI 20), 281-297.(https://www.usenix.org/conference/osdi20/presentation/fried)

412

TCP/IP スタック設計の再考
Mitigating Interference

Signals スタックを動かす
Actions• パケット I/O フレームワーク上で TCP/IP

メモリ帯域の⼲渉は DRAM コントローラーの• Sandstorm (SIGCOMM 2014)
カウンタとキャッシュミスから検知• mTCP (NSDI 2014){Work Stealing}
DRAM
RevokeDirect• Arrakis (OSDI
2014)
Task 1
Unallocated
DRAM
Bandwidthcores from Task 2
LLC Misses• IX (OSDI 2014) Interference
Bandwidth
antagonist Runtime
Runtime• StackMap (USENIX ATC 2016)
task ksched
この場合、⼲渉の原因となる
kschedkschedkschedkschedksched• Atlas (SIGCOMM 2017)
ワークロードを実⾏しているCore 1
Core 2
Core 3
Core 4
Core 5
Core 6Hyperthread
コアを、ワークロードが所属
RequestRemove{Core Allocation}• ZygOS (SOSP 2017)
Interference
Processingするタスクから奪う
task onShared Memory• Shenango (NSDI 2019)Times
sibling core
• Shinjuku (NSDI 2019)
Scheduler
DRAM
ioctl()
Controller• TAS (EuroSys
2019)(PCIe)
kschedIndirect LLC and other• Caladan (OSDIinterference,
2020)
Core 0 Add core to
Queueing
victimrelies on a sched• zIO (OSDI 2021)load changes 拡張 FigureDelay
2:Caladan
Caladan’ssystem architecture.
Caladanschedulerと Caladan
ランタイム環境は• Demikernel (SOSP 2021) uler core共有メモリを通じて情報をやりとりする
to gather control signals from shared memory regions+

17

Joshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on
Operating Systems Design and Implementation (OSDI 20), 281-297.(https://www.usenix.org/conference/osdi20/presentation/fried)

413

TCP/IP スタック設計の再考
Mitigating Interference

Signals スタックを動かす
Actions• パケット I/O フレームワーク上で TCP/IP

ハイパースレッドの⼲渉は• Sandstorm (SIGCOMM 2014)
リクエスト処理時間の増加を元に検知• mTCP (NSDI 2014){Work Stealing}
DRAM
RevokeDirect• Arrakis (OSDI
2014)
Task 1
Unallocated
DRAM
Bandwidthcores from Task 2
LLC Misses• IX (OSDI 2014) Interference
Bandwidth
antagonist Runtime
Runtime• StackMap (USENIX ATC 2016)
task kschedkschedkschedkschedkschedksched• Atlas (SIGCOMM 2017)
Core 1
Core 2
Core 3
Core 4
Core 5
Core 6Hyperthread
RequestRemove{Core Allocation}• ZygOS (SOSP 2017)
Interference
Processing
task onShared Memory• Shenango (NSDI 2019)Times
sibling core
• Shinjuku (NSDI 2019)
Scheduler
DRAM
ioctl()
Controller• TAS (EuroSys
2019)(PCIe)
kschedIndirect LLC and other• Caladan (OSDIinterference,
2020)
Core 0 Add core to
Queueing
victimrelies on a sched• zIO (OSDI 2021)load changes 拡張 FigureDelay
2:Caladan
Caladan’ssystem architecture.
Caladanschedulerと Caladan
ランタイム環境は• Demikernel (SOSP 2021) uler core共有メモリを通じて情報をやりとりする
to gather control signals from shared memory regions+

17

Joshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on
Operating Systems Design and Implementation (OSDI 20), 281-297.(https://www.usenix.org/conference/osdi20/presentation/fried)

414

TCP/IP スタック設計の再考
Mitigating Interference

Signals スタックを動かす
Actions• パケット I/O フレームワーク上で TCP/IP

ハイパースレッドの⼲渉は• Sandstorm (SIGCOMM 2014)
リクエスト処理時間の増加を元に検知• mTCP (NSDI 2014){Work Stealing}
DRAM
RevokeDirect• Arrakis (OSDI
2014)
Task 1
Unallocated
DRAM
Bandwidthcores from Task 2
LLC Misses• IX (OSDI 2014) Interference
Bandwidth
antagonist Runtime
Runtime• StackMap (USENIX ATC 2016)
task ksched
この場合、隣接するハイパースレッドで動作する
kschedkschedkschedkschedksched• Atlas (SIGCOMM 2017)
タスクを取り除く
Core 1
Core 2
Core 3
Core 4
Core 5
Core 6Hyperthread
RequestRemove{Core Allocation}• ZygOS (SOSP 2017)
Interference
Processing
task onShared Memory• Shenango (NSDI 2019)Times
sibling core
• Shinjuku (NSDI 2019)
Scheduler
DRAM
ioctl()
Controller• TAS (EuroSys
2019)(PCIe)
kschedIndirect LLC and other• Caladan (OSDIinterference,
2020)
Core 0 Add core to
Queueing
victimrelies on a sched• zIO (OSDI 2021)load changes 拡張 FigureDelay
2:Caladan
Caladan’ssystem architecture.
Caladanschedulerと Caladan
ランタイム環境は• Demikernel (SOSP 2021) uler core共有メモリを通じて情報をやりとりする
to gather control signals from shared memory regions+

17

Joshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on
Operating Systems Design and Implementation (OSDI 20), 281-297.(https://www.usenix.org/conference/osdi20/presentation/fried)

415

TCP/IP スタック設計の再考
Mitigating Interference

Signals スタックを動かす
Actions• パケット I/O フレームワーク上で TCP/IP

スレッドのランキューやパケットキューが• Sandstorm (SIGCOMM 2014)
いっぱいになってきた場合に• mTCP (NSDI 2014){Work Stealing}
DRAM
RevokeDirect• Arrakis (OSDI
2014)
Task 1
Unallocated
DRAM
Bandwidthcores from Task 2
LLC Misses• IX (OSDI 2014) Interference
Bandwidth
antagonist Runtime
Runtime• StackMap (USENIX ATC 2016)
task kschedkschedkschedkschedkschedksched• Atlas (SIGCOMM 2017)
Core 1
Core 2
Core 3
Core 4
Core 5
Core 6Hyperthread
RequestRemove{Core Allocation}• ZygOS (SOSP 2017)
Interference
Processing
task onShared Memory• Shenango (NSDI 2019)Times
sibling core
• Shinjuku (NSDI 2019)
Scheduler
DRAM
ioctl()
Controller• TAS (EuroSys
2019)(PCIe)
kschedIndirect LLC and other• Caladan (OSDIinterference,
2020)
Core 0 Add core to
Queueing
victimrelies on a sched• zIO (OSDI 2021)load changes 拡張 FigureDelay
2:Caladan
Caladan’ssystem architecture.
Caladanschedulerと Caladan
ランタイム環境は• Demikernel (SOSP 2021) uler core共有メモリを通じて情報をやりとりする
to gather control signals from shared memory regions+

17

Joshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on
Operating Systems Design and Implementation (OSDI 20), 281-297.(https://www.usenix.org/conference/osdi20/presentation/fried)

416

TCP/IP スタック設計の再考
Mitigating Interference

Signals スタックを動かす
Actions• パケット I/O フレームワーク上で TCP/IP

スレッドのランキューやパケットキューが• Sandstorm (SIGCOMM 2014)
いっぱいになってきた場合に• mTCP (NSDI 2014){Work Stealing}
DRAM
RevokeDirect• Arrakis (OSDI
2014)
Task 1
Unallocated
DRAM
Bandwidthcores from Task 2
LLC Misses• IX (OSDI 2014) Interference
Bandwidth
antagonist Runtime
Runtime• StackMap (USENIX ATC 2016)
task kschedkschedkschedkschedkschedksched
それらが所属するタスクへ• Atlas (SIGCOMM 2017)
コアを新しくアサインする
Core 1
Core 2
Core 3
Core 4
Core 5
Core 6Hyperthread
RequestRemove{Core Allocation}• ZygOS (SOSP 2017)
Interference
Processing
task onShared Memory• Shenango (NSDI 2019)Times
sibling core
• Shinjuku (NSDI 2019)
Scheduler
DRAM
ioctl()
Controller• TAS (EuroSys
2019)(PCIe)
kschedIndirect LLC and other• Caladan (OSDIinterference,
2020)
Core 0 Add core to
Queueing
victimrelies on a sched• zIO (OSDI 2021)load changes 拡張 FigureDelay
2:Caladan
Caladan’ssystem architecture.
Caladanschedulerと Caladan
ランタイム環境は• Demikernel (SOSP 2021) uler core共有メモリを通じて情報をやりとりする
to gather control signals from shared memory regions+

17

Joshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on
Operating Systems Design and Implementation (OSDI 20), 281-297.(https://www.usenix.org/conference/osdi20/presentation/fried)

417

TCP/IP スタック設計の再考
and GCand GCMemcached• Memcached
パケット I/O フレームワーク上で
TCP/IP スタックを動かす
BetterBetterBetterBetter• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)
Latency• Arrakis (OSDI 2014)
reaches• IX (OSDI 2014)
580 msMemcached
Memcached• StackMap (USENIX ATC
2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
Throttles BE• Shenango (NSDI 2019)
GC TaskGC Task after GC has• Shinjuku (NSDI 2019)
completed• TAS (EuroSys 2019)
拡張• Caladan (OSDI 2020)
Key
Key• Demikernel (SOSP 2021)
Garbage Collection Cycle

MemcachedLow
tail
Latencylatencyreaches(50 μs)

580 msGarbage Collection タスク

Throttles BE
GCaftertask GC
ablehasto completed
utilize allavailable
resourcesJoshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on
Operating Systems Design and Implementation (OSDI 20), 281-297.(https://www.usenix.org/conference/osdi20/presentation/fried)

418

TCP/IP スタック設計の再考
灰⾊の箇所がGarbage Collection が実⾏されている時間
and GCand GCMemcached• Memcached
パケット I/O フレームワーク上で
TCP/IP スタックを動かす
BetterBetterBetterBetter• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)
Latency• Arrakis (OSDI 2014)
reaches• IX (OSDI 2014)
580 msMemcached
Memcached• StackMap (USENIX ATC
2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
Throttles BE• Shenango (NSDI 2019)
GC TaskGC Task after GC has• Shinjuku (NSDI 2019)
completed• TAS (EuroSys 2019)
拡張• Caladan (OSDI 2020)
Key
Key• Demikernel (SOSP 2021)
Garbage Collection Cycle

MemcachedLow
tail
Latencylatencyreaches(50 μs)

580 msGarbage Collection タスク

Throttles BE
GCaftertask GC
ablehasto completed
utilize allavailable
resourcesJoshua Fried, Zhenyuan Ruan, Amy Ousterhout, and Adam Belay. 2020. Caladan: Mitigating Interference at Microsecond Timescales. In 14th USENIX Symposium on
Operating Systems Design and Implementation (OSDI 20), 281-297.(https://www.usenix.org/conference/osdi20/presentation/fried)

419

TCP/IP スタック設計の再考
Garbage Collection にかかわらず低い遅延を達成
and GCand GCMemcached• Memcached
パケット I/O フレームワーク上で
TCP/IP スタックを動かす
BetterBetterBetterBetter• Sandstorm (SIGCOMM 2014)• mTCP (NSDI 2014)
Latency• Arrakis (OSDI 2014)
reaches• IX (OSDI 2014)
580 msMemcached
Memcached• StackMap (USENIX ATC
2016)• Atlas (SIGCOMM 2017)• ZygOS (SOSP 2017)
Throttles BE• Shenango (NSDI 2019)
GC TaskGC Task after GC has• Shinjuku (NSDI 2019)
completed• TAS (EuroSys 2019)
拡張• Caladan (OSDI 2020)
Key
Key• Demikernel (SOSP 2021)
Garbage Collection Cycle

MemcachedLow
tail
Latencylatencyreaches(50 μs)

580 msGarbage Collection タスク

Throttles BE
GCaftertask GC
ablehasto completed
utilize allavailable
resources

420

研究紹介
TCP/IP スタック設計
パケット I/O フレームワークを適⽤する
インターフェース設計

421

Irene Zhang, Amanda Raybuck, Pratyush Patel, Kirk Olynyk, Jacob Nelson, Omar S. Navarro Leija, Ashlie Martinez, Jing Liu, Anna Kornfeld Simpson, Sujay Jayakar,
Pedro Henrique Penna, Max Demoulin, Piali Choudhury, and Anirudh Badam. 2021. The Demikernel Datapath OS Architecture for Microsecond-Scale Datacenter
Systems. In Proceedings of the ACM Sigops 28th Symposium on Operating Systems Principles (SOSP ʼ21), 195-211.(https://doi.org/10.1145/3477132.3483569)

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI2014)
s devices. Demikernel
datapath
OSes run with• Arrakis
2014)
trolplane kernel(e.g., (OSDI
Linux orWindows) and
• IX
(OSDI
2014)
erchangeable
library
OSeswith the same API,
StackMap(USENIX
ATC 2016)
ent features•andarchitecture.
Each library
OS is• Atlasfic: it offloads
to the (SIGCOMM
kernel-bypass2017)device when
ZygOS (SOSP
2017) in a userimplements •remaining
OS management• Shenango(NSDIthe2019)
These libOSes
aim to simplify
development• Shinjuku(NSDI2019) kernelatacenter systems
acrossheterogenous• TAS(EuroSyses with while
minimizing
OS 2019)
overheads.
el follows a• trend
away
from 2020)
kernel-oriented
Caladan(OSDI
ary-oriented• datapath
OSes,(SOSP
motivatedby theDemikernel
2021)

Kernel-Bypass Architectures
Control
PathApp
User-space
SoftwareAd-hoc Datapaths

ArrakislibOSAppCaladanlibrary

Kernel-space OS
Software Kernel

D

Con
Pa

App
eRPC Lib.

User I/O

Buf. Mgmt
User I/O

Net. Trans.
Buf. Mgmt
User I/O

I/O Hardware NIC - SR-IOV

DPDK

RDMA

OS
Kern

N

Figure 1. Example kernel-bypass architectures. U
ernel architecture (right), Arrakis [73], Caladan [23Irene Zhang, Amanda Raybuck, Pratyush Patel, Kirk Olynyk, Jacob Nelson, Omar S. Navarro Leija, Ashlie Martinez, Jing Liu, Anna Kornfeld Simpson, Sujay Jayakar,
Pedro Henrique Penna, Max Demoulin, Piali Choudhury, and Anirudh Badam. 2021. The Demikernel Datapath OS Architecture for Microsecond-Scale Datacenter
Systems. In Proceedings of the ACM Sigops 28th Symposium on Operating Systems Principles (SOSP ʼ21), 195-211.(https://doi.org/10.1145/3477132.3483569)

422

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI2014)
D
s devices. Demikernel
datapath
OSes run withKernel-Bypass Architectures• Arrakis
2014)
Con
Control
trolplane kernel(e.g., (OSDI
Linux orWindows) andAd-hocDatapaths
Pa
Path
•
IX
(OSDI
2014)
erchangeable library OSes with the same API,App•
StackMap(USENIX
ATC
2016)
App
ent features and architecture. Each library OS is
ArrakisUser-spaceApp
CaladanlibOS• AtlaseRPC Lib.
Softwarelibrary
fic: it offloads
to the (SIGCOMM
kernel-bypass2017)device when
ZygOS (SOSP
2017) in a userimplements •remaining
OS management
OS
Kernel-space OS
Kern
Software Kernel• Shenango(NSDIthe2019)
Net. Trans.
These libOSes
aim to simplify
development
Buf. Mgmt
Buf. Mgmt
User I/O
User I/O
User I/O• Shinjuku(NSDI2019) kernelatacenter systems
acrossheterogenous
I/O Hardware NIC - SR-IOV
DPDK
N
RDMA
• TAS
(EuroSyses with while
minimizing
OS 2019)
overheads.
el follows a• trend
away
from 2020)
kernel-oriented 様々なカーネルをバイパスする
Caladan(OSDI
Figure 1. Example kernel-bypass architectures. U
ary-oriented• datapath
OSes,(SOSP
motivatedby the システムが提案されたDemikernel
2021)
ernel architecture (right), Arrakis [73], Caladan [23Irene Zhang, Amanda Raybuck, Pratyush Patel, Kirk Olynyk, Jacob Nelson, Omar S. Navarro Leija, Ashlie Martinez, Jing Liu, Anna Kornfeld Simpson, Sujay Jayakar,
Pedro Henrique Penna, Max Demoulin, Piali Choudhury, and Anirudh Badam. 2021. The Demikernel Datapath OS Architecture for Microsecond-Scale Datacenter
Systems. In Proceedings of the ACM Sigops 28th Symposium on Operating Systems Principles (SOSP ʼ21), 195-211.(https://doi.org/10.1145/3477132.3483569)

423

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす• Sandstorm (SIGCOMM 2014)• mTCP (NSDI2014)
D
s devices. Demikernel
datapath
OSes run withKernel-Bypass Architectures• Arrakis
2014)
Con
Control
trolplane kernel(e.g., (OSDI
Linux orWindows) andAd-hocDatapaths
Pa
Path
•
IX
(OSDI
2014)
erchangeable library OSes with the same API,App•
StackMap(USENIX
ATC
2016)
App
ent features and architecture. Each library OS is
ArrakisUser-spaceApp
CaladanlibOS• AtlaseRPC Lib.
Softwarelibrary
fic: it offloads
to the (SIGCOMM
kernel-bypass2017)device when
ZygOS (SOSP
2017) in a userimplements •remaining
OS management
OS
Kernel-space OS
Kern
Software Kernel• Shenango(NSDIthe2019)
Net. Trans.
These libOSes
aim to simplify
development
Buf. Mgmt
Buf. Mgmt
User I/O
User I/O
User I/O• Shinjuku(NSDI2019) kernelatacenter systems
acrossheterogenous
I/O Hardware NIC - SR-IOV
DPDK
N
RDMA
• TAS
(EuroSyses with while
minimizing
OS 2019)
overheads.
el follows a• trend
away
from 2020)
kernel-oriented 様々なカーネルをバイパスする
Caladan(OSDI
Figure 1. Example kernel-bypass architectures. U
ary-oriented• datapath
OSes,(SOSP
motivatedby the システムが提案されたDemikernel
2021)
ernel architecture (right), Arrakis [73], Caladan [23Irene Zhang, Amanda Raybuck, Pratyush Patel, Kirk Olynyk, Jacob Nelson, Omar S. Navarro Leija, Ashlie Martinez, Jing Liu, Anna Kornfeld Simpson, Sujay Jayakar,
Pedro Henrique Penna, Max Demoulin, Piali Choudhury, and Anirudh Badam. 2021. The Demikernel Datapath OS Architecture for Microsecond-Scale Datacenter
Systems. In Proceedings of the ACM Sigops 28th Symposium on Operating Systems Principles (SOSP ʼ21), 195-211.(https://doi.org/10.1145/3477132.3483569)

424

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす

問題：アプリが利⽤を想定するデバイスに依存• Sandstorm (SIGCOMM 2014)• mTCP (NSDI2014)
D
s devices. Demikernel
datapath
OSes run withKernel-Bypass Architectures• Arrakis
2014)
Con
Control
trolplane kernel(e.g., (OSDI
Linux orWindows) andAd-hocDatapaths
Pa
Path
•
IX
(OSDI
2014)
erchangeable library OSes with the same API,App•
StackMap(USENIX
ATC
2016)
App
ent features and architecture. Each library OS is
ArrakisUser-spaceApp
CaladanlibOS• AtlaseRPC Lib.
Softwarelibrary
fic: it offloads
to the (SIGCOMM
kernel-bypass2017)device when
ZygOS (SOSP
2017) in a userimplements •remaining
OS management
OS
Kernel-space OS
Kern
Software Kernel• Shenango(NSDIthe2019)
Net. Trans.
These libOSes
aim to simplify
development
Buf. Mgmt
Buf. Mgmt
User I/O
User I/O
User I/O• Shinjuku(NSDI2019) kernelatacenter systems
acrossheterogenous
I/O Hardware NIC - SR-IOV
DPDK
N
RDMA
• TAS
(EuroSyses with while
minimizing
OS 2019)
overheads.
el follows a• trend
away
from 2020)
kernel-oriented 様々なカーネルをバイパスする
Caladan(OSDI
Figure 1. Example kernel-bypass architectures. U
ary-oriented• datapath
OSes,(SOSP
motivatedby the システムが提案されたDemikernel
2021)
ernel architecture (right), Arrakis [73], Caladan [23Irene Zhang, Amanda Raybuck, Pratyush Patel, Kirk Olynyk, Jacob Nelson, Omar S. Navarro Leija, Ashlie Martinez, Jing Liu, Anna Kornfeld Simpson, Sujay Jayakar,
Pedro Henrique Penna, Max Demoulin, Piali Choudhury, and Anirudh Badam. 2021. The Demikernel Datapath OS Architecture for Microsecond-Scale Datacenter
Systems. In Proceedings of the ACM Sigops 28th Symposium on Operating Systems Principles (SOSP ʼ21), 195-211.(https://doi.org/10.1145/3477132.3483569)

425

TCP/IP スタック設計の再考• パケット I/O フレームワーク上で TCP/IP スタックを動かす

問題：アプリが利⽤を想定するデバイスに依存• Sandstorm (SIGCOMM 2014)
モチベーション：汎⽤的なインターフェースがあった⽅が良い
•
mTCP
(NSDI
2014)
D
s devices. Demikernel datapath OSes run withKernel-Bypass Architectures• Arrakis
2014)
Con
Control
trolplane kernel(e.g., (OSDI
Linux orWindows) andAd-hocDatapaths
Pa
Path
•
IX
(OSDI
2014)
erchangeable library OSes with the same API,App•
StackMap(USENIX
ATC
2016)
App
ent features and architecture. Each library OS is
ArrakisUser-spaceApp
CaladanlibOS• AtlaseRPC Lib.
Softwarelibrary
fic: it offloads
to the (SIGCOMM
kernel-bypass2017)device when
ZygOS (SOSP
2017) in a userimplements •remaining
OS management
OS
Kernel-space OS
Kern
Software Kernel• Shenango(NSDIthe2019)
Net. Trans.
These libOSes
aim to simplify
development
Buf. Mgmt
Buf. Mgmt
User I/O
User I/O
User I/O• Shinjuku(NSDI2019) kernelatacenter systems
acrossheterogenous
I/O Hardware NIC - SR-IOV
DPDK
N
RDMA
• TAS
(EuroSyses with while
minimizing
OS 2019)
overheads.
el follows a• trend
away
from 2020)
kernel-oriented 様々なカーネルをバイパスする
Caladan(OSDI
Figure 1. Example kernel-bypass architectures. U
ary-oriented• datapath
OSes,(SOSP
motivatedby the システムが提案されたDemikernel
2021)
ernel architecture (right), Arrakis [73], Caladan [23426into a single library for both devices (e.g., RDMAxSPDK).
We implemented the bulk of our library OS code in Rust.
We initially prototyped several libOSes in C++; however,
we found that Rust performs competitively with C++ andachieves ns-scale latencies while offering additional benefits.
First, Rust
enforces スタックを動かす
memory safety through language fea• パケット I/O フレームワーク上で
TCP/IP
tures and its compiler. Though our libOSes use unsafe code
• Sandstorm (SIGCOMM 2014)to bind to C/C++ kernel-bypass libraries and applications,

Irene Zhang, Amanda Raybuck, Pratyush Patel, Kirk Olynyk, Jacob Nelson, Omar S. Navarro Leija, Ashlie Martinez, Jing Liu, Anna Kornfeld Simpson, Sujay Jayakar,
Pedro Henrique Penna, Max Demoulin, Piali Choudhury, and Anirudh Badam. 2021. The Demikernel Datapath OS Architecture for Microsecond-Scale Datacenter
Systems. In Proceedings of the ACM Sigops 28th Symposium on Operating Systems Principles (SOSP ʼ21), 195-211.(https://doi.org/10.1145/3477132.3483569)

TCP/IP スタック設計の再考• mTCP (NSDI 2014)
Control
Demikernel Datapath Architecture• Arrakis (OSDI 2014)
Path
App• IX (OSDI 2014)
User-space
Demikernel PDPIX Datapath API
SoftwarelibPOSIX
libRDMA• StackMap (USENIX ATC 2016)
libDPDKlibSPDK
libFuture???
• Atlas (SIGCOMM 2017)OS
Kernel-space
KernelSoftware• ZygOS (SOSP 2017)• Shenango (NSDI 2019)
DPDK
SPDK
FutureRDMA
I/O Hardware I/O Device• Shinjuku (NSDI 2019)
Figure 3. Demikernel kernel-bypass architecture. Demikernel ac• TAS (EuroSys 2019)
commodates heterogenous kernel-bypass devices, including poten• Caladan (OSDI 2020)
tial future hardware, with a flexible library OS-based datapath ar• Demikernel (SOSP 2021) chitecture.We include a libOS that goes through the OS kernel forNet. Trans.
Buf. Mgmt
User I/O

Buf. Mgmt
User I/O

Buf. Mgmt
User I/O

???

427

into a single library for both devices (e.g., RDMAxSPDK).
We implemented the bulk of our library OS code in Rust.
We initially prototyped several libOSes in C++; however,
we found that Rust performs competitively with C++ andachieves ns-scale latencies while offering additional benefits.
First, Rust
enforces スタックを動かす
memory safety through language fea• パケット I/O フレームワーク上で
TCP/IP
tures and its compiler. Though our libOSes use unsafe code
• Sandstorm (SIGCOMM 2014)to bind to C/C++ kernel-bypass libraries and applications,

Irene Zhang, Amanda Raybuck, Pratyush Patel, Kirk Olynyk, Jacob Nelson, Omar S. Navarro Leija, Ashlie Martinez, Jing Liu, Anna Kornfeld Simpson, Sujay Jayakar,
Pedro Henrique Penna, Max Demoulin, Piali Choudhury, and Anirudh Badam. 2021. The Demikernel Datapath OS Architecture for Microsecond-Scale Datacenter
Systems. In Proceedings of the ACM Sigops 28th Symposium on Operating Systems Principles (SOSP ʼ21), 195-211.(https://doi.org/10.1145/3477132.3483569)

TCP/IP スタック設計の再考• mTCP (NSDI 2014)
Control
Demikernel Datapath Architecture• Arrakis (OSDI 2014)
Path
App• IX (OSDI 2014)
User-space
Demikernel PDPIX Datapath API
SoftwarelibPOSIX
libRDMA• StackMap (USENIX ATC 2016)
libDPDKlibSPDK
libFuture???
• Atlas (SIGCOMM 2017)OS
Kernel-space
KernelSoftware• ZygOS (SOSP 2017)• Shenango (NSDI 2019)
DPDK
SPDK
FutureRDMA
I/O Hardware I/O Device• Shinjuku (NSDI 2019)
Figure 3. Demikernel kernel-bypass architecture. Demikernel ac• TAS (EuroSys 2019)
commodates提案：異なるタイプのデバイスへ
heterogenous kernel-bypass devices, including poten共通のインターフェースからアクセス可能にする• Caladan (OSDI 2020)
tial future hardware, with a flexible library OS-based datapath ar• Demikernel (SOSP 2021) chitecture.We include a libOS that goes through the OS kernel forNet. Trans.
Buf. Mgmt
User I/O

Buf. Mgmt
User I/O

Buf. Mgmt
User I/O

???

428

研究紹介
仮想マシン通信について基本的な仕組みの説明

429
通信関連のシステムソフトウェア
データセンター内のサーバー
サービス利⽤者の端末

通信関連ソフトウェア
サービス提供側
アプリケーション
ユーザー空間
仮想マシン

NIC

カーネル

10 ~ Gbps

TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

インターネット

ホスト

仮想スイッチ
データセンターハードウェア ( NIC ) は速くなったので
⼤量のリクエストが集まってくる NIC デバイスドライバ
ソフトウェアの効率が重要になる
サービス提供側はなるべく短い応答時間でサービスを提供したい

430
仮想マシン環境
ユーザー空間カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

431
仮想マシン環境
ユーザー空間
これまでの話はこの辺りの改善

カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

432
仮想マシン環境
ユーザー空間仮想マシン
カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

ホスト

仮想スイッチ
NIC デバイスドライバ

433
仮想マシン環境
ユーザー空間仮想マシン
仮想マシン環境ではバックエンドも速くないと性能が制限されてしまう

カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

ホスト

仮想スイッチ
NIC デバイスドライバ

434
仮想マシン環境
ユーザー空間仮想マシン
仮想マシン環境ではバックエンドも速くないと性能が制限されてしまう

カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

ホスト
⾼速化ポイント

仮想スイッチ
NIC デバイスドライバ

435
仮想スイッチユーザー空間
仮想マシン
カーネル

なぜ必要？
物理 NIC を複数の仮想マシンで分離を維持しつつ共有するためアプリケーション
TCP/IP スタック
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル

仮想 NIC バックエンド

ホスト

TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

仮想スイッチ
NIC デバイスドライバ

アプリケーション

436
仮想スイッチユーザー空間
仮想マシン
カーネル

なぜ必要？
物理 NIC を複数の仮想マシンで分離を維持しつつ共有するためアプリケーション
TCP/IP スタック
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル

仮想 NIC バックエンド

ホスト

共有

TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

仮想スイッチ
NIC デバイスドライバ

アプリケーション

437
仮想スイッチユーザー空間
仮想マシン
カーネル

なぜ必要？
物理 NIC を複数の仮想マシンで分離を維持しつつ共有するためアプリケーション
TCP/IP スタック
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル

仮想 NIC バックエンド

ホスト

共有

TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

仮想スイッチ
NIC デバイスドライバ

アプリケーション

438
仮想スイッチユーザー空間
仮想マシン
カーネル

A

なぜ必要？
物理 NIC を複数の仮想マシンで分離を維持しつつ共有するためアプリケーション
TCP/IP スタック
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル

仮想 NIC バックエンド

ホスト

共有

TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

仮想スイッチ
NIC デバイスドライバ

アプリケーション

439
仮想スイッチユーザー空間
仮想マシン
カーネル

A

なぜ必要？
物理 NIC を複数の仮想マシンで分離を維持しつつ共有するためアプリケーション
TCP/IP スタック
NIC デバイスドライバ

ユーザー空間
仮想マシン
カーネル

B

仮想 NIC バックエンド

ホスト

共有

TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

仮想スイッチ
NIC デバイスドライバ

アプリケーション

440
仮想スイッチユーザー空間
仮想マシン
カーネル

A

なぜ必要？
物理 NIC を複数の仮想マシンで分離を維持しつつ共有するためアプリケーション
TCP/IP スタック
NIC デバイスドライバ

ユーザー空間
仮想マシン
カーネル

B

仮想 NIC バックエンド

ホスト

アプリケーション
TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

仮想スイッチ
NIC デバイスドライバ
共有

宛先: 仮想マシンA

宛先: 仮想マシンB

新規パケットの到着441
仮想スイッチユーザー空間
仮想マシン
カーネル

A

なぜ必要？
物理 NIC を複数の仮想マシンで分離を維持しつつ共有するためアプリケーション
TCP/IP スタック
NIC デバイスドライバ

ユーザー空間
仮想マシン
カーネル

B

仮想 NIC バックエンド

ホスト

アプリケーション
TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

仮想スイッチ
NIC デバイスドライバ
共有

仮想マシンが共有する NIC には異なる仮想マシンを宛先とするパケットが送られてくる

宛先: 仮想マシンA

宛先: 仮想マシンB

新規パケットの到着442
仮想スイッチユーザー空間
仮想マシン
カーネル

A

なぜ必要？
物理 NIC を複数の仮想マシンで分離を維持しつつ共有するためアプリケーション
TCP/IP スタック
NIC デバイスドライバ

ユーザー空間
仮想マシン
カーネル

B

仮想 NIC バックエンド

ホスト
NIC デバイスドライバ
各仮想マシンは別の仮想マシンを宛先とするパケットへアクセスできるべきでない

アプリケーション
TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

仮想スイッチ

宛先: 仮想マシンA

宛先: 仮想マシンB

新規パケットの到着443
仮想スイッチユーザー空間
仮想マシン
カーネル

A

なぜ必要？
物理 NIC を複数の仮想マシンで分離を維持しつつ共有するためアプリケーション
TCP/IP スタック
NIC デバイスドライバ

ユーザー空間
仮想マシン
カーネル

B

仮想 NIC バックエンド

ホスト
NIC デバイスドライバ
各仮想マシンは別の仮想マシンを宛先とするパケットへアクセスできるべきでない

アプリケーション
TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

仮想スイッチ

宛先: 仮想マシンA

宛先: 仮想マシンB

新規パケットの到着444
仮想スイッチユーザー空間
仮想マシン
カーネル

A

なぜ必要？
物理 NIC を複数の仮想マシンで分離を維持しつつ共有するためアプリケーション
TCP/IP スタック
NIC デバイスドライバ

ユーザー空間
仮想マシン
カーネル

ホスト

宛先: 仮想マシンA

TCP/IP スタックB

仮想 NIC バックエンド

アプリケーション

NIC デバイスドライバ
仮想 NIC バックエンド

仮想スイッチ

宛先: 仮想マシンB

NIC デバイスドライバ
各仮想マシンは別の仮想マシンを
仮想スイッチがパケットの宛先（MAC アドレス）
宛先とするパケットへを元に仮想マシンへパケットをフォワードするようにすることでアクセスできるべきでない
各仮想マシンは⾃分へ宛てられたパケット以外⾒えなくできる445
仮想スイッチユーザー空間
仮想マシン
カーネル

A

なぜ必要？
物理 NIC を複数の仮想マシンで分離を維持しつつ共有するためアプリケーション

ユーザー空間仮想マシン

TCP/IP スタック
NIC デバイスドライバ

カーネル

B

仮想 NIC バックエンド

ホスト

アプリケーション
TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

仮想スイッチ
NIC デバイスドライバ
仮想スイッチの処理は仮想マシン通信において頻繁に実⾏されるため、⾼い性能を発揮するためには効率が重要446（⽐較的⼀般的な）仮想スイッチ利⽤法• ユーザー空間プロセスは tap デバイスを通じてパケットを送受信する

ユーザー空間

カーネル
物理マシン

プロセス

プロセス

アプリケーション

アプリケーション

tap device

tap device

仮想スイッチ（e.g., Linux bridge）

447（⽐較的⼀般的な）仮想スイッチ利⽤法• ユーザー空間プロセスは tap デバイスを通じてパケットを送受信する• QEMU/KVM ベースの仮想マシンの場合は図中のプロセスが実⾏するアプリケーションが QEMU になる
ユーザー空間

カーネル
物理マシン

プロセス

プロセス

QEMU

QEMU

tap device

tap device

仮想スイッチ（e.g., Linux bridge）

448（⽐較的⼀般的な）仮想スイッチ利⽤法• 問題：既存の tap デバイスと仮想スイッチが⾼速にパケットをフォワードできない

ユーザー空間

カーネル
物理マシン

プロセス

プロセス

アプリケーション

アプリケーション

tap device

tap device

仮想スイッチ（e.g., Linux bridge）

449
他の仮想 I/O 機構：SR-IOV
ユーザー空間仮想マシン
カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル* Single Root I/O Virtualization

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ホスト

NIC

仮想 NIC仮想 NICスイッチ

450
他の仮想 I/O 機構：SR-IOV
ユーザー空間
仮想マシン
カーネル

ホスト

NIC

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

ユーザー空間* Single Root I/O Virtualization

アプリケーション

仮想マシン
カーネル

TCP/IP スタック
NIC デバイスドライバ- NIC が仮想インターフェースを提供- ホストを介さなくても複数仮想マシンが1 つの物理 NIC を共有できる

仮想 NIC仮想 NICスイッチ

451
他の仮想 I/O 機構：SR-IOV
ユーザー空間仮想マシン
カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

アプリケーション

仮想マシン
カーネル

TCP/IP スタック
NIC デバイスドライバ- NIC が仮想インターフェースを提供- ホストを介さなくても複数仮想マシンが1 つの物理 NIC を共有できる

ホスト
利点：⾼速

NIC

ユーザー空間* Single Root I/O Virtualization

⽋点：ソフトウェアで細部の制御ができない

仮想 NIC仮想 NIC
スイッチ

452

研究紹介
仮想マシン通信について
仮想スイッチの⾼速化

453
仮想マシン通信の⾼速化• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT 2012)• CuckooSwitch (CoNEXT 2013)• mSwitch (SOSR 2015)
ユーザー空間

カーネル
物理マシン

プロセス

プロセス

アプリケーション

アプリケーション

tap device

tap device

仮想スイッチ（e.g., Linux bridge）

454
仮想マシン通信の⾼速化• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT 2012)• CuckooSwitch (CoNEXT 2013)• mSwitch (SOSR 2015)
tap デバイスの代わりに netmap API 準拠の仮想ポート
ユーザー空間

カーネル
物理マシン

プロセス

プロセス

アプリケーション

アプリケーション

Virtual Port
(netmap API)

Virtual Port
(netmap API)VALE ( netmap モジュールの⼀部 )：仮想スイッチとして機能

455
仮想マシン通信の⾼速化• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT 2012)• CuckooSwitch (CoNEXT 2013)• mSwitch (SOSR 2015)
tap デバイスの代わりに netmap API 準拠の仮想ポート
ユーザー空間プロセス

プロセス

アプリケーション

アプリケーション

Virtual Port
(netmap API)

Virtual Port
(netmap API)

カーネル

VALE ( netmap モジュールの⼀部 )：仮想スイッチとして機能

物理マシン

netmap API 準拠の仮想ポート間で MAC アドレスを元にパケットを転送responding pps rates are between 1/6 and 1/150 of thoshown here.
The traffic received by a bridge should normally go tosingle destination, but there are cases (multicast or unknow
destinations) where the bridge needs to replicate packets t
multiple ports. Hence the number of active ports impac
the throughput of the system.

456

Luigi Rizzo and Giuseppe Lettieri. 2012. VALE, a Switched Ethernet for Virtual Machines. In Proceedings of the 8th International Conference on Emerging Networking
Experiments and Technologies (CoNEXT ʼ12), 61-72.(https://doi.org/10.1145/2413176.2413185)

仮想マシン通信の⾼速化• 仮想スイッチへパケット I/O フレームワークを適⽤
18

VALE, 60 bytes
NIC, 60 bytes
VALE, 1514 bytes
NIC, 1514 bytes
TAP, 60 bytes

16
Forwarding rate (Mpps)• VALE (CoNEXT 2012)• CuckooSwitch (CoNEXT 2013)• mSwitch (SOSR 2015)

14
12
10
8
6
4
2
1

2

3

4
5
Destinations

6

7

8

responding pps rates are between 1/6 and 1/150 of thoshown here.
The traffic received by a bridge should normally go tosingle destination, but there are cases (multicast or unknow
destinations) where the bridge needs to replicate packets t
multiple ports. Hence the number of active ports impac
the throughput of the system.

457

Luigi Rizzo and Giuseppe Lettieri. 2012. VALE, a Switched Ethernet for Virtual Machines. In Proceedings of the 8th International Conference on Emerging Networking
Experiments and Technologies (CoNEXT ʼ12), 61-72.(https://doi.org/10.1145/2413176.2413185)

仮想マシン通信の⾼速化• 仮想スイッチへパケット I/O フレームワークを適⽤• パケットサイズが６０バイトで宛先が１つの場合• VALE: 17.6 Mpps
• tap デバイス: 1 Mpps 以下

18

VALE, 60 bytes
NIC, 60 bytes
VALE, 1514 bytes
NIC, 1514 bytes
TAP, 60 bytes

16
Forwarding rate (Mpps)• VALE (CoNEXT 2012)• CuckooSwitch (CoNEXT 2013)• mSwitch (SOSR 2015)

14
12
10
8
6
4
2
1

2

3

4
5
Destinations

6

7

8

responding pps rates are between 1/6 and 1/150 of thoshown here.
The traffic received by a bridge should normally go tosingle destination, but there are cases (multicast or unknow
destinations) where the bridge needs to replicate packets t
multiple ports. Hence the number of active ports impac
the throughput of the system.

458

Luigi Rizzo and Giuseppe Lettieri. 2012. VALE, a Switched Ethernet for Virtual Machines. In Proceedings of the 8th International Conference on Emerging Networking
Experiments and Technologies (CoNEXT ʼ12), 61-72.(https://doi.org/10.1145/2413176.2413185)

仮想マシン通信の⾼速化• 仮想スイッチへパケット I/O フレームワークを適⽤• パケットサイズが６０バイトで宛先が１つの場合• VALE: 17.6 Mpps
• tap デバイス: 1 Mpps 以下

18

VALE, 60 bytes
NIC, 60 bytes
VALE, 1514 bytes
NIC, 1514 bytes
TAP, 60 bytes

16
Forwarding rate (Mpps)• VALE (CoNEXT 2012)• CuckooSwitch (CoNEXT 2013)• mSwitch (SOSR 2015)

14
12
10
8
6
4
2
1

2

3

4
5
Destinations

6

7

8

responding pps rates are between 1/6 and 1/150 of thoshown here.
The traffic received by a bridge should normally go tosingle destination, but there are cases (multicast or unknow
destinations) where the bridge needs to replicate packets t
multiple ports. Hence the number of active ports impac
the throughput of the system.

459

Luigi Rizzo and Giuseppe Lettieri. 2012. VALE, a Switched Ethernet for Virtual Machines. In Proceedings of the 8th International Conference on Emerging Networking
Experiments and Technologies (CoNEXT ʼ12), 61-72.(https://doi.org/10.1145/2413176.2413185)

仮想マシン通信の⾼速化• 仮想スイッチへパケット I/O フレームワークを適⽤• パケットサイズが６０バイトで宛先が１つの場合• VALE: 17.6 Mpps
• tap デバイス: 1 Mpps 以下
SR-IOV はデータが PCI バスを経由するため
仮想ポート間の通信は VALE より遅くなる

18

VALE, 60 bytes
NIC, 60 bytes
VALE, 1514 bytes
NIC, 1514 bytes
TAP, 60 bytes

16
Forwarding rate (Mpps)• VALE (CoNEXT 2012)• CuckooSwitch (CoNEXT 2013)• mSwitch (SOSR 2015)

14
12
10
8
6
4
2
1

2

3

4
5
Destinations

6

7

8

responding pps rates are between 1/6 and 1/150 of thoshown here.
The traffic received by a bridge should normally go tosingle destination, but there are cases (multicast or unknow
destinations) where the bridge needs to replicate packets t
multiple ports. Hence the number of active ports impac
the throughput of the system.

460

Luigi Rizzo and Giuseppe Lettieri. 2012. VALE, a Switched Ethernet for Virtual Machines. In Proceedings of the 8th International Conference on Emerging Networking
Experiments and Technologies (CoNEXT ʼ12), 61-72.(https://doi.org/10.1145/2413176.2413185)

仮想マシン通信の⾼速化• 仮想スイッチへパケット I/O フレームワークを適⽤• パケットサイズが６０バイトで宛先が１つの場合• VALE: 17.6 Mpps
• tap デバイス: 1 Mpps 以下

18
16
Forwarding rate (Mpps)• VALE (CoNEXT 2012)• CuckooSwitch (CoNEXT 2013)• mSwitch (SOSR 2015)

⼤幅な改善

14
12

VALE, 60 bytes
NIC, 60 bytes
VALE, 1514 bytes
NIC, 1514 bytes
TAP, 60 bytes

10
8
6
4
2
1

2

3

4
5
Destinations

6

7

8

461
仮想マシン通信の⾼速化• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
アプリケーション
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR
2015)
TCP/IP スタック
カーネル
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル

仮想 NIC バックエンド

ホスト

TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

仮想スイッチ
NIC デバイスドライバ

アプリケーション462
仮想マシン通信の⾼速化
VALE を QEMU/KVM へ適⽤して実験• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSRnetmap
2015)
カーネル
e1000 デバイスドライバ

ホスト

ユーザー空間仮想マシン
カーネル

pkt-gennetmape1000 デバイスドライバ

QEMU e1000 emulation

QEMU e1000 emulation

Virtual Port (netmap API)

Virtual Port (netmap API)VALE
NIC デバイスドライバ

463
仮想マシン通信の⾼速化
仮想マシン内では netmap ベースの
VALE を QEMU/KVM へ適⽤して実験
pkt-gen アプリを実⾏• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSRnetmap
2015)
カーネル
e1000 デバイスドライバ

ホスト

ユーザー空間仮想マシン
カーネル

pkt-gennetmape1000 デバイスドライバ

QEMU e1000 emulation

QEMU e1000 emulation

Virtual Port (netmap API)

Virtual Port (netmap API)VALE
NIC デバイスドライバ

464
仮想マシン通信の⾼速化
VALE を QEMU/KVM へ適⽤して実験• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSRnetmap
2015)
カーネル

ユーザー空間仮想マシン

e1000 デバイスドライバ

ホスト

pkt-gen

カーネル

netmape1000 デバイスドライバ

QEMU e1000 emulation

QEMU e1000 emulation

Virtual Port (netmap API)

Virtual Port (netmap API)VALE
NIC デバイスドライバ

Throughput

TX (Mpps)

RX (Mpps)

tap device

0.550

0.550

VALE

3.470

2.550

465
仮想マシン通信の⾼速化• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT 2012)• CuckooSwitch (CoNEXT 2013)• mSwitch (SOSR 2015)
改善- 利⽤可能ポート数がスケールできるようにする- パケット転送ロジックをカーネルモジュールで実装できるようにする

466
仮想マシン通信の⾼速化• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT 2012)• CuckooSwitch (CoNEXT 2013)• mSwitch (SOSR 2015)

DPDK ベース実装

467

研究紹介
仮想マシン通信について
⾼速な仮想スイッチを仮想マシン通信へ適⽤

468
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤• ClickOS (NSDI 2014)• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)• HyperNF (SoCC 2017)• ELISA (ASPLOS 2023)

469
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤• ClickOS (NSDI 2014)• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)• HyperNF (SoCC 2017)• ELISA (ASPLOS 2023)

470
仮想マシン通信の⾼速化• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSRnetmap
2015)
カーネル
e1000 デバイスドライバ

ホスト

ユーザー空間仮想マシン
カーネル

pkt-gennetmape1000 デバイスドライバ

QEMU e1000 emulation

QEMU e1000 emulation

Virtual Port (netmap API)

Virtual Port (netmap API)VALE
NIC デバイスドライバ

471
仮想マシン通信の⾼速化
改善の余地あり• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSRnetmap
2015)
カーネル
e1000 デバイスドライバ

ホスト

ユーザー空間仮想マシン
カーネル

pkt-gennetmape1000 デバイスドライバ

QEMU e1000 emulation

QEMU e1000 emulation

Virtual Port (netmap API)

Virtual Port (netmap API)VALE
NIC デバイスドライバ

472
仮想マシン通信の⾼速化• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSRnetmap
2015)
カーネル

ホスト

ユーザー空間仮想マシン
カーネル

Virtual Port (netmap API)VALE
NIC デバイスドライバ

pkt-gennetmapVirtual Port (netmap API)473
仮想マシン通信の⾼速化
ptnetmap (pt: passthrough)：
ホストが作成した仮想 (netmap) ポートへ、仮想マシン内のアプリが直接アクセスできるようにする• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR 2015)
netmapカーネル

ユーザー空間仮想マシン
カーネル

Virtual Port (netmap API)ptnetmap
バックエンド
VALE

NIC デバイスドライバ

netmapVirtual Port (netmap API)ptnetmap
バックエンドホスト

pkt-gen474

Stefano Garzarella, Giuseppe Lettieri, and Luigi Rizzo. 2015. Virtual Device Passthrough for High Speed Vm Networking. In 2015 ACM/IEEE Symposium on
Architectures for Networking and Communications Systems (ANCS), 99-110.(https://doi.org/10.1109/ANCS.2015.7110124)

仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤

Throughput [Mpps]• ClickOS (NSDI 2014)• NetVM (NSDI 2014)24• ptnetmap (ANCS 2015, LANMAN 2016)20• HyperNF (SoCC 2017)16• ELISA (ASPLOS 2023)
12

8
Guest to Host
Host to Guest
Guest to Guest
Host to Host

4

0
1

2

4

8

16
32
64 128TX Batch [pkts]

256

512 1024

475

Stefano Garzarella, Giuseppe Lettieri, and Luigi Rizzo. 2015. Virtual Device Passthrough for High Speed Vm Networking. In 2015 ACM/IEEE Symposium on
Architectures for Networking and Communications Systems (ANCS), 99-110.(https://doi.org/10.1109/ANCS.2015.7110124)

仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤

24 MppsThroughput [Mpps]• ClickOS (NSDI 2014)• NetVM (NSDI 2014)24• ptnetmap (ANCS 2015, LANMAN 2016)20• HyperNF (SoCC 2017)16• ELISA (ASPLOS 2023)
12

8
Guest to Host
Host to Guest
Guest to Guest
Host to Host

4

0
1

2

4

8

16
32
64 128TX Batch [pkts]

256

512 1024

476

Stefano Garzarella, Giuseppe Lettieri, and Luigi Rizzo. 2015. Virtual Device Passthrough for High Speed Vm Networking. In 2015 ACM/IEEE Symposium on
Architectures for Networking and Communications Systems (ANCS), 99-110.(https://doi.org/10.1109/ANCS.2015.7110124)

仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤

Throughput [Mpps]• ClickOS (NSDI 2014)• NetVM (NSDI 2014)24• ptnetmap (ANCS 2015, LANMAN 2016)20• HyperNF (SoCC 2017)16• ELISA (ASPLOS 2023)

Guest が送信側の時が速い

12

8
Guest to Host
Host to Guest
Guest to Guest
Host to Host

4

0
1

2

4

8

16
32
64 128TX Batch [pkts]

256

512 1024

477
仮想マシン通信の⾼速化
Guest to Guest• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR 2015)
netmapカーネル

ユーザー空間仮想マシン
カーネル

Virtual Port (netmap API)ptnetmap
バックエンド
VALE

NIC デバイスドライバ

netmapVirtual Port (netmap API)ptnetmap
バックエンドホスト

pkt-gen478
仮想マシン通信の⾼速化
Guest to Host

• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR 2015)
netmapカーネル

ホスト・ユーザー空間
プロセス

Virtual Port (netmap API)

pkt-genptnetmap
バックエンドホスト

Virtual Port (netmap API)VALE
NIC デバイスドライバ

479
仮想マシン通信の⾼速化
Guest to Host

• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR 2015)
netmapカーネル

ホスト・ユーザー空間
プロセス

Virtual Port (netmap API)

pkt-genptnetmap
バックエンドホスト

Virtual Port (netmap API)VALE
NIC デバイスドライバ

480
仮想マシン通信の⾼速化
Guest to Host

QEMU/KVM では vCPU は pthread として実装される• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR 2015)
netmapカーネル

ホスト・ユーザー空間
プロセス

Virtual Port (netmap API)

pkt-genptnetmap
バックエンドホスト

Virtual Port (netmap API)VALE
NIC デバイスドライバ

481
仮想マシン通信の⾼速化
Guest to Host

QEMU/KVM では vCPU は pthread として実装される• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR 2015)
netmapカーネル

ptnetmap のバックエンドはホスト内でカーネルスレッドを作成しVALE の処理を実⾏

ホスト・ユーザー空間
プロセス

Virtual Port (netmap API)

pkt-genptnetmap
バックエンドホスト

Virtual Port (netmap API)VALE
NIC デバイスドライバ

482
仮想マシン通信の⾼速化
Guest to Host

QEMU/KVM では vCPU は pthread として実装される• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR 2015)
netmapカーネル

vCPU
ptnetmap のバックエンドは
pthread
ホスト内でカーネルスレッドを作成し（pkt-gen)
VALE の処理を実⾏

ホスト・ユーザー空間
プロセス

Virtual Port (netmap API)

pkt-genptnetmap
バックエンドホスト

Virtual Port (netmap API)VALE
NIC デバイスドライバ
時間483
仮想マシン通信の⾼速化
Guest to Host

QEMU/KVM では vCPU は pthread として実装される• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR 2015)
netmapカーネル

vCPU
ptnetmap のバックエンドは
pthread
ホスト内でカーネルスレッドを作成し（pkt-gen)
VALE の処理を実⾏
パケット送信リクエスト

ホスト・ユーザー空間
pthetmap
プロセス
バックエンドVirtual Port (netmap API)

カーネル
pkt-gen
スレッド
Virtual Port (netmap API)ptnetmap
バックエンドホスト

VALE
NIC デバイスドライバ
時間484
仮想マシン通信の⾼速化
Guest to Host

QEMU/KVM では vCPU は pthread として実装される• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR 2015)
netmapカーネル

vCPU
ptnetmap のバックエンドは
pthread
ホスト内でカーネルスレッドを作成し（pkt-gen)
VALE の処理を実⾏

Virtual Port (netmap API)ptnetmap
バックエンドホスト

vCPU
pthread（pkt-gen)

VALE
NIC デバイスドライバ
時間

ホスト・ユーザー空間
pthetmap
プロセス
バックエンドカーネル
pkt-gen
スレッド
VALE
Virtualを実⾏
Port (netmap API)

485
仮想マシン通信の⾼速化
Guest to Host

QEMU/KVM では vCPU は pthread として実装される• 仮想スイッチへパケット I/O フレームワークを適⽤
バックエンドのスレッドが• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR 2015)
netmap
カーネル

vCPU
転送処理をしている間もptnetmap のバックエンドは
pthreadvCPU（アプリ）スレッドが動けるホスト内でカーネルスレッドを作成し（pkt-gen)
VALE の処理を実⾏

Virtual Port (netmap API)ptnetmap
バックエンドホスト

vCPU
pthread（pkt-gen)

VALE
NIC デバイスドライバ
時間

ホスト・ユーザー空間
pthetmap
プロセス
バックエンドカーネル
pkt-gen
スレッド
VALE
Virtualを実⾏
Port (netmap API)486
仮想マシン通信の⾼速化
Guest to Host

QEMU/KVM では vCPU は pthread として実装される• 仮想スイッチへパケット I/O フレームワークを適⽤
バックエンドのスレッドが• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR 2015)
netmap
カーネル

vCPU
転送処理をしている間もptnetmap のバックエンドは
pthreadvCPU（アプリ）スレッドが動けるホスト内でカーネルスレッドを作成し（pkt-gen)
VALE の処理を実⾏

Virtual Port (netmap API)ptnetmap
バックエンドホスト

vCPU
pthread（pkt-gen)

ホスト・ユーザー空間
pthetmap
プロセス
バックエンドカーネル
pkt-gen
スレッド
VALE
Virtualを実⾏
Port (netmap API)VALE
NIC デバイスドライバ

時間
バックエンドのカーネルスレッドのおかげで pkt-gen のために最⼤２CPUコア同時に動く

487
仮想マシン通信の⾼速化
Guest to Host

• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
pkt-gen
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR 2015)
netmapカーネル

ホスト・ユーザー空間
プロセス

Virtual Port (netmap API)

pkt-genptnetmap
バックエンドホスト

Virtual Port (netmap API)VALE
NIC デバイスドライバ

488
仮想マシン通信の⾼速化

通常の（ホストの）ユーザー空間プロセスがパケットを送信する場合

Guest to Host

• 仮想スイッチへパケット I/O
フレームワークを適⽤
ホスト• VALE (CoNEXT2012) ユーザー
pkt-gen
ユーザー空間空間• CuckooSwitch (CoNEXT 2013)
プロセス
仮想マシン
• mSwitch (SOSR 2015)（pkt-gen)netmap
カーネル

VALE の通常の仮想ポートの場合
バックエンドのスレッドがない

ホスト・ユーザー空間
プロセス

Virtual Port (netmap API)

pkt-genptnetmap
バックエンドホスト

VALE
NIC デバイスドライバ

時間

Virtual Port (netmap API)489
仮想マシン通信の⾼速化

通常の（ホストの）ユーザー空間プロセスがパケットを送信する場合

Guest to Host

• 仮想スイッチへパケット I/O
フレームワークを適⽤
ホスト• VALE (CoNEXT2012) ユーザー
pkt-gen
ユーザー空間空間• CuckooSwitch (CoNEXT 2013)
プロセス
仮想マシン
• mSwitch (SOSR 2015)（pkt-gen)netmapカーネル
システムコール

VALE の通常の仮想ポートの場合
バックエンドのスレッドがない

ホスト・ユーザー空間
プロセス

Virtual Port (netmap API)

pkt-genptnetmap
バックエンドホスト

VALE
NIC デバイスドライバ

時間

Virtual Port (netmap API)

システムコール

490
仮想マシン通信の⾼速化

通常の（ホストの）ユーザー空間プロセスがパケットを送信する場合

Guest to Host

• 仮想スイッチへパケット I/O
フレームワークを適⽤
ホスト• VALE (CoNEXT2012) ユーザー
pkt-gen
ユーザー空間空間• CuckooSwitch (CoNEXT 2013)
プロセス
仮想マシン
• mSwitch (SOSR 2015)（pkt-gen)netmap
カーネル
カーネル

VALE の通常の仮想ポートの場合
バックエンドのスレッドがない

ホスト・ユーザー空間
プロセス

Virtual Port (netmap （システム
API)
コール）
VALEを実⾏

pkt-genptnetmap
バックエンドホスト

VALE
NIC デバイスドライバ

時間

Virtual Port (netmap API)

491
仮想マシン通信の⾼速化

通常の（ホストの）ユーザー空間プロセスがパケットを送信する場合

Guest to Host

• 仮想スイッチへパケット I/O
フレームワークを適⽤
ホスト• VALE (CoNEXT2012) ユーザー
pkt-gen
ユーザー空間空間• CuckooSwitch (CoNEXT 2013)
プロセス
仮想マシン
• mSwitch (SOSR 2015)（pkt-gen)netmap
カーネル
カーネル

VALE の通常の仮想ポートの場合
バックエンドのスレッドがない

ホスト・ユーザー空間
プロセス

Virtual Port (netmap （システム
API)
コール）
VALEを実⾏

pkt-genptnetmap
ホスト
バックエンド

ホスト
時間

ユーザー
空間
プロセス
NIC デバイスドライバ（pkt-gen)

Virtual Port (netmap API)

VALE
ユーザー空間へリターン492
仮想マシン通信の⾼速化

通常の（ホストの）ユーザー空間プロセスがパケットを送信する場合

Guest to Host

• 仮想スイッチへパケット I/O
フレームワークを適⽤
ホスト• VALE (CoNEXT2012) ユーザー
pkt-gen
ユーザー空間空間• CuckooSwitch (CoNEXT 2013)
プロセス
仮想マシン
• mSwitch (SOSR 2015)（pkt-gen)netmap
カーネル
カーネル

VALE の通常の仮想ポートの場合
バックエンドのスレッドがない

ホスト・ユーザー空間
プロセス

Virtual Port (netmap （システム
API)
コール）
VALEを実⾏

pkt-genptnetmap
ホスト
バックエンド

ホスト

ユーザー
空間
プロセス
NIC デバイスドライバ（pkt-gen)時間
pkt-gen と VALE が同じ CPU コアで実⾏される

Virtual Port (netmap API)

VALE
ユーザー空間へリターン493
仮想マシン通信の⾼速化

通常の（ホストの）ユーザー空間プロセスがパケットを送信する場合

Guest to Host

• 仮想スイッチへパケット I/O
フレームワークを適⽤
ホスト• VALE (CoNEXT2012) ユーザー
pkt-gen
ユーザー空間空間• CuckooSwitch (CoNEXT 2013)
プロセス
仮想マシン
• mSwitch (SOSR 2015)（pkt-gen)netmap
カーネル
カーネル

VALE の通常の仮想ポートの場合
バックエンドのスレッドがない

ホスト・ユーザー空間
プロセス

Virtual Port (netmap （システム
API)
コール）
VALEを実⾏

pkt-genptnetmap
ホスト
バックエンド

ホスト

ユーザー
空間
プロセス
NIC デバイスドライバ（pkt-gen)

Virtual Port (netmap API)

VALE
ユーザー空間へリターン時間
pkt-gen と VALE が同じ CPU コアで実⾏される：pkt-gen のために最⼤１CPUコアが同時に動く494
ptnetmap の場合

仮想マシン通信の⾼速化
Guest to Host

• 仮想スイッチへパケット I/O
フレームワークを適⽤
ホスト

vCPU (CoNEXT• VALE
2012) ユーザー
pkt-gen
ユーザー空間pthread空間•（pkt-gen)
CuckooSwitch (CoNEXT 2013)
プロセス
仮想マシン
• mSwitch (SOSR 2015)（pkt-gen)netmapカーネル
カーネル

pthetmap
VirtualPort (netmap （システムAPI)
バックエンド
コール）
vCPU
カーネル
VALEを実⾏
pthreadスレッド ptnetmap（pkt-gen)
ホスト
バックエンド
ユーザー
ホスト
空間
プロセス
NIC デバイスドライバ（pkt-gen)
時間

VALE の通常の仮想ポートの場合
バックエンドのスレッドがない

ホスト・ユーザー空間
プロセス
pkt-gen
Virtual Port (netmap API)

VALE

495
ptnetmap の場合

仮想マシン通信の⾼速化
Guest to Host

• 仮想スイッチへパケット I/O
フレームワークを適⽤
ホスト

vCPU (CoNEXT• VALE
2012) ユーザー
pkt-gen
ユーザー空間pthread空間•（pkt-gen)
CuckooSwitch (CoNEXT 2013)
プロセス
仮想マシン
• mSwitch (SOSR 2015)（pkt-gen)netmapカーネル
カーネル

pthetmap
VirtualPort (netmap （システムAPI)
最⼤２CPUコアを
バックエンドコール）
vCPU
同時に利⽤できるから速い
カーネル
VALEを実⾏
pthreadスレッド ptnetmap（pkt-gen)
ホスト
バックエンド
ユーザー
ホスト
空間
プロセス
NIC デバイスドライバ（pkt-gen)
時間

VALE の通常の仮想ポートの場合
バックエンドのスレッドがない

ホスト・ユーザー空間
プロセス
pkt-gen
Virtual Port (netmap API)

VALE

Stefano Garzarella, Giuseppe Lettieri, and Luigi Rizzo. 2015. Virtual Device Passthrough for High Speed Vm Networking. In 2015 ACM/IEEE Symposium on
Architectures for Networking and Communications Systems (ANCS), 99-110.(https://doi.org/10.1109/ANCS.2015.7110124)

496

ptnetmap の場合

仮想マシン通信の⾼速化
Guest to Host

• 仮想スイッチへパケット I/O
フレームワークを適⽤
ホスト
24

20
Throughput [Mpps]

vCPU (CoNEXT• VALE
2012) ユーザー
pkt-gen
ユーザー空間pthread空間•（pkt-gen)
CuckooSwitch (CoNEXT 2013)
プロセス
仮想マシン
• mSwitch (SOSR 2015)（pkt-gen)netmap
カーネル
カーネル

VALE の通常の仮想ポートの場合
バックエンドのスレッドがない

16

ホスト・ユーザー空間

12
pthetmap
VirtualPort (netmap （システム
API)
プロセス
バックエンド
コール）
8
vCPU
カーネル
pkt-gen
VALEを実⾏
pthreadスレッド ptnetmap
Guest to Host
4
（pkt-gen)
Host to Guest
ホスト
Virtual Port (netmap
API)
Guest to Guest
バックエンドHost to Host
ユーザー
0
ホスト
VALE1 2 4 8 16 32 64 128 256 512 1024
空間
TX Batch [pkts]
プロセス
NIC デバイスドライバ（pkt-gen)
時間
Figure 6: Throughput across a VALE switch, w

di↵erent placements of the source and sink, and

497

研究紹介
仮想マシン通信について
仮想 I/O 実⾏⽅式の改善

498
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤
Xen に netmap/VALE を適⽤• ClickOS (NSDI 2014)
QEMU/KVM に DPDK を適⽤• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)• ELISA (ASPLOS 2023)

499
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤
Xen に netmap/VALE を適⽤• ClickOS (NSDI 2014)
QEMU/KVM に DPDK を適⽤• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
実⾏のモデルを改善• ELISA (ASPLOS 2023)

500
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤
vCPU
Xen に netmap/VALE を適⽤• ClickOS (NSDI
thread 2014)
パケット送信QEMU/KVM に DPDK を適⽤• NetVM (NSDIリクエスト2014)• ptnetmap (ANCS 2015, LANMAN 2016)
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
バックエンドカーネル
実⾏のモデルを改善• ELISA (ASPLOS
2023)
vCPU
スレッド
thread時間

501
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤
vCPU
Xen に netmap/VALE を適⽤• ClickOS (NSDI
thread 2014)
パケット送信QEMU/KVM に DPDK を適⽤• NetVM (NSDIリクエスト2014)• ptnetmap (ANCS 2015, LANMAN 2016)
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
バックエンドカーネル
実⾏のモデルを改善• ELISA (ASPLOS
2023)
vCPU
スレッド
thread

主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い
時間502
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤
Xen に netmap/VALE を適⽤• ClickOS (NSDI 2014)
QEMU/KVM に DPDK を適⽤• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
実⾏のモデルを改善• ELISA (ASPLOS 2023)

主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い503
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤
Xen に netmap/VALE を適⽤• CPU
ClickOSCPU 時間時間 (NSDI 2014)
100 %100 % (NSDI 2014)
QEMU/KVM に DPDK を適⽤• NetVM• ptnetmap (ANCS 2015, LANMAN 2016)
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
実⾏のモデルを改善• ELISA (ASPLOS 2023)

主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い504
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤
Xen に netmap/VALE を適⽤• ClickOS (NSDI 2014)
QEMU/KVM に DPDK を適⽤• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
実⾏のモデルを改善• ELISA (ASPLOS 2023)

主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い505

理想的には性能のために CPU は最⼤限利⽤できるべき仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤
理想
Xen に netmap/VALE を適⽤• ClickOS(NSDI 2014)
カーネル
vCPU
スレッド
thread (NSDI 2014)
QEMU/KVM に DPDK を適⽤• NetVM• ptnetmap (ANCS 2015, LANMAN 2016)
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
実⾏のモデルを改善• ELISA (ASPLOS 2023)

主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い実際は、vCPU かバックエンドのスレッドどちらかが常にボトルネックになる（ワークロード依存）506

仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤
実際
Xen に netmap/VALE を適⽤• ClickOS(NSDI 2014)
vCPU
thread (NSDI 2014)
QEMU/KVM に DPDK を適⽤• NetVM• ptnetmap (ANCS 2015, LANMAN 2016)
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
カーネル
実⾏のモデルを改善• ELISA (ASPLOS 2023)
スレッド

主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い

vCPU スレッドがボトルネック

実際は、vCPU かバックエンドのスレッドどちらかが常にボトルネックになる（ワークロード依存）507

仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシ
利⽤されないン通信基盤へ適⽤
CPU 時間実際
Xen に netmap/VALE を適⽤• ClickOS(NSDI 2014)
vCPU
thread (NSDI 2014)
QEMU/KVM に DPDK を適⽤• NetVM• ptnetmap (ANCS 2015, LANMAN 2016)
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
カーネル
実⾏のモデルを改善• ELISA (ASPLOS 2023)
スレッド

主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い

vCPU スレッドがボトルネック

実際は、vCPU かバックエンドのスレッドどちらかが常にボトルネックになる（ワークロード依存）508

仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシ
利⽤されないン通信基盤へ適⽤
CPU 時間実際
Xen に netmap/VALE を適⽤• ClickOS (NSDI 2014)
カーネル
スレッド
QEMU/KVM に DPDK を適⽤• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)vCPU
実⾏のモデルを改善• ELISA(ASPLOS 2023)
thread

主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い

バックエンドのカーネルスレッドがボトルネック

解決策：vCPU とバックエンドのカーネルスレッドは同じ CPU コアの上で動かす

509

仮想マシン通信の⾼速化
vCPU• パケットthreadvCPU I/O フレームワークを使った仮想スイッチを仮想マシ
threadン通信基盤へ適⽤
Xen に netmap/VALE を適⽤• ClickOS (NSDI 2014)
QEMU/KVM に DPDK を適⽤• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)
カーネル
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
スレッド
カーネル
実⾏のモデルを改善• スレッドELISA (ASPLOS 2023)

主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い解決策：vCPU とバックエンドのカーネルスレッドは同じ CPU コアの上で動かす
利点：ワークロードが変化しても、CPU の vCPU とバックエンドへの割り当てが常に理想的

510

仮想マシン通信の⾼速化

vCPU• パケットthreadvCPU I/O フレームワークを使った仮想スイッチを仮想マシ
threadン通信基盤へ適⽤
Xen に netmap/VALE を適⽤• ClickOS (NSDI 2014)
QEMU/KVM に DPDK を適⽤• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)
カーネル
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
スレッド
カーネル
実⾏のモデルを改善• スレッドELISA (ASPLOS 2023)

主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い解決策：vCPU とバックエンドのカーネルスレッドは同じ CPU コアの上で動かす
利点：ワークロードが変化しても、CPU の vCPU とバックエンドへの割り当てが常に理想的

511

仮想マシン通信の⾼速化

vCPU• パケットthreadvCPU I/O フレームワークを使った仮想スイッチを仮想マシ
threadン通信基盤へ適⽤
Xen に netmap/VALE を適⽤• ClickOS (NSDI 2014)
QEMU/KVM に DPDK を適⽤• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)
カーネル
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
スレッド
カーネル
実⾏のモデルを改善• スレッドELISA (ASPLOS 2023)

主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い

計算が多く、I/O が少ない場合

解決策：vCPU とバックエンドのカーネルスレッドは同じ CPU コアの上で動かす
利点：ワークロードが変化しても、CPU の vCPU とバックエンドへの割り当てが常に理想的

512

仮想マシン通信の⾼速化

vCPU• パケット I/O フレームワークを使った仮想スイッチを仮想マシ
threadン通信基盤へ適⽤
vCPU

Xen に netmap/VALE を適⽤• ClickOS(NSDI 2014)
threadQEMU/KVM に DPDK を適⽤• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)
カーネル
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
スレッド
実⾏のモデルを改善• ELISA (ASPLOS 2023)
カーネル
スレッド
主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い

計算が少なく、I/O が多い場合：バックエンドに利⽤されない CPU 時間を vCPU が使える

解決策：vCPU とバックエンドのカーネルスレッドは同じ CPU コアの上で動かす
利点：ワークロードが変化しても、CPU の vCPU とバックエンドへの割り当てが常に理想的

513

仮想マシン通信の⾼速化
vCPU
threadvCPU• パケット I/O フレームワークを使った仮想スイッチを仮想マシ
threadン通信基盤へ適⽤

Xen に netmap/VALE を適⽤• ClickOS (NSDI 2014)
QEMU/KVM に DPDK を適⽤• NetVM (NSDI 2014)• カーネルptnetmap (ANCS 2015, LANMAN 2016)
カーネル
Xen に netmap/VALE を適⽤• スレッドHyperNF (SoCC 2017)
スレッド
実⾏のモデルを改善• ELISA (ASPLOS 2023)

主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い

計算が多く、I/O が少ない場合：vCPU に利⽤されない CPU 時間をバックエンドが使える解決策：vCPU とバックエンドのカーネルスレッドは同じ CPU コアの上で動かす
この解決策の課題
利点：ワークロードが変化しても、CPU の vCPU とバックエンドへの割り当てが常に理想的

514

仮想マシン通信の⾼速化
vCPU
threadvCPU• パケット I/O フレームワークを使った仮想スイッチを仮想マシ
threadvCPU
vCPU
ン通信基盤へ適⽤
threadXen に netmap/VALE を適⽤thread• ClickOS (NSDI 2014)
バックエンドQEMU/KVMに DPDK を適⽤• NetVM (NSDI 2014)
バックエンドカーネル
カーネル• カーネルptnetmap (ANCS 2015, LANMAN 2016)
スレッド
スレッド
カーネル
Xen に netmap/VALE を適⽤• スレッドHyperNF (SoCC 2017)
スレッド
vCPU
実⾏のモデルを改善• ELISA (ASPLOS 2023)
vCPU
threadthreadバックエンドバックエンド
主張：vCPUカーネル
スレッドと仮想スイッチを実⾏する
カーネル
スレッド
バックエンドのスレッドを分けない⽅が良い
スレッド
時間
計算が多く、I/O が少ない場合：vCPU に利⽤されない CPU 時間をバックエンドが使える解決策：vCPU とバックエンドのカーネルスレッドは同じ CPU コアの上で動かす
この解決策の課題
利点：ワークロードが変化しても、CPU の vCPU とバックエンドへの割り当てが常に理想的

515

仮想マシン通信の⾼速化
vCPU
threadvCPU• パケット I/O フレームワークを使った仮想スイッチを仮想マシ
threadvCPU
vCPU
ン通信基盤へ適⽤
threadthreadXenにnetmap/VALE
を適⽤
schedule• ClickOS (NSDI 2014)
schedule
バックエンドQEMU/KVMに DPDK を適⽤• NetVM (NSDI 2014)
バックエンドカーネル
カーネル• カーネルptnetmap (ANCS 2015, LANMAN 2016)
スレッド
スレッド
schedule
カーネル
Xen に netmap/VALE
を適⽤• スレッドHyperNF (SoCC 2017)
schedule
スレッド
vCPU
実⾏のモデルを改善vCPU• ELISA (ASPLOS 2023)
threadthreadscheduleschedule
バックエンドバックエンド
主張：vCPUカーネル
スレッドと仮想スイッチを実⾏する
カーネル
スレッド
バックエンドのスレッドを分けない⽅が良い
スレッド
時間 スレッド切り替えのためのスケジューリングコスト
計算が多く、I/O が少ない場合：vCPU に利⽤されない CPU 時間をバックエンドが使える解決策：vCPU とバックエンドのカーネルスレッドは同じ CPU コアの上で動かす
提案⼿法
利点：ワークロードが変化しても、CPU の vCPU とバックエンドへの割り当てが常に理想的
I/O をハイパーコール内で実⾏

516

仮想マシン通信の⾼速化
vCPU
threadvCPU• パケット I/O フレームワークを使った仮想スイッチを仮想マシ
threadvCPU
vCPU
ン通信基盤へ適⽤
ThreadThreadXen に netmap/VALE を適⽤• ClickOS (NSDI 2014)
QEMU/KVMに DPDK を適⽤
ハイパー
ハイパー
• NetVM (NSDI 2014)コール
コール• カーネルptnetmap (ANCS 2015, LANMAN 2016)
(I/O)
(I/O)
カーネル
Xen に netmap/VALE を適⽤• スレッドHyperNF (SoCC 2017)
スレッド
実⾏のモデルを改善• ELISA (ASPLOS 2023)
ハイパー
コール
ハイパー
(I/O)
コール
(I/O)
主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い
時間
計算が多く、I/O が少ない場合：vCPU に利⽤されない CPU 時間をバックエンドが使える解決策：vCPU とバックエンドのカーネルスレッドは同じ CPU コアの上で動かす
提案⼿法
利点：ワークロードが変化しても、CPU の vCPU とバックエンドへの割り当てが常に理想的
I/O をハイパーコール内で実⾏

517

仮想マシン通信の⾼速化
vCPU
threadvCPU• パケット I/O フレームワークを使った仮想スイッチを仮想マシ
threadvCPU
vCPU
ン通信基盤へ適⽤
ThreadThreadXen に netmap/VALE を適⽤• ClickOS (NSDI 2014)
QEMU/KVMに DPDK を適⽤
ハイパー
ハイパー
• NetVM (NSDI 2014)コール
コール• カーネルptnetmap (ANCS 2015, LANMAN 2016)
(I/O)
(I/O)
カーネル
Xen に netmap/VALE を適⽤• スレッドHyperNF (SoCC 2017)
スレッド
実⾏のモデルを改善• ELISA (ASPLOS 2023)
ハイパー
コール
ハイパー
(I/O)
コール
(I/O)
主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い
時間 スケジューリングコスト
をなくすことができる計算が多く、I/O が少ない場合：vCPU に利⽤されない CPU 時間をバックエンドが使える

518

３パターン
Split

Merge

仮想マシン通信の⾼速化

提案⼿法• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤
vCPU
vCPU
vCPU
vCPU
Xen に netmap/VALE
を適⽤• ClickOS (NSDI 2014) thread
ThreadvCPU
threadthreadQEMU/KVM に DPDK を適⽤• NetVM (NSDI 2014)
バックエンドハイパー• ptnetmap (ANCS 2015,カーネル
LANMAN バックエンド
2016)
コール
カーネル
スレッド
Xen
に
netmap/VALE
を適⽤• HyperNF (SoCC 2017)
(I/O)
スレッド
バックエンド
実⾏のモデルを改善• ELISA (ASPLOS
2023)
カーネル
vCPU
vCPU
vCPU
スレッド
threadthreadthreadハイパー
コール
バックエンド(I/O)
バックエンド
カーネル
カーネル
スレッド
スレッド

Thread
ハイパー
コール
(I/O)
ハイパー
コール
(I/O)

３パターン 実験の設定：Split は 2 CPU で動作するため、vCPU に割り当てる CPU 時間を半分に設定
その他は１ CPU のみ利⽤
Merge
Split
提案⼿法

仮想マシン通信の⾼速化
５０％
５０％• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤
vCPU
vCPU
Xen に netmap/VALE
を適⽤• ClickOS (NSDI 2014) thread
ThreadvCPU
threadQEMU/KVM に DPDK を適⽤• NetVM (NSDI 2014)
バックエンドハイパー• ptnetmap (ANCS 2015,カーネル
LANMAN 2016)
コール
スレッド
Xen
に
netmap/VALE
を適⽤• HyperNF (SoCC 2017)(I/O)
バックエンド
実⾏のモデルを改善• ELISA (ASPLOS
2023)
カーネル
vCPU
vCPU
スレッド
threadthreadハイパー
コール
バックエンド
(I/O)
カーネル
スレッド

519

Kenichi Yasukata, Felipe Huici, Vincenzo Maffione, Giuseppe Lettieri, and Michio Honda. 2017. HyperNF: Building a High Performance, High Utilization and Fair NFV
Platform. In Proceedings of the 2017 Symposium on Cloud Computing (SoCC ʼ17), 157-169.(https://doi.org/10.1145/3127479.3127489)

Split

Merge

提案⼿法

vCPU
threadvCPU
Thread520

仮想マシン通信の⾼速化
５０％
５０％

バックエンド
カーネル
スレッド
vCPU
threadバックエンドカーネル
スレッド

VM 間の転送速度
ハイパー
コール
(I/O)

vCPU
threadバックエンド
カーネル
スレッド

SoCC ’17, September 24–27, 2017, San

ハイパー
コール
(I/O)

Throughput [Mpps]

vCPU
thread

16
14
12
10
8
6
4
2
0

Split
Merge
HyperNF

64 512 1024 1472
Packet Size [#](a) No NF - virtual ports.

Kenichi Yasukata, Felipe Huici, Vincenzo Maffione, Giuseppe Lettieri, and Michio Honda. 2017. HyperNF: Building a High Performance, High Utilization and Fair NFV
Platform. In Proceedings of the 2017 Symposium on Cloud Computing (SoCC ʼ17), 157-169.(https://doi.org/10.1145/3127479.3127489)

Split

Merge

提案⼿法

仮想マシン通信の⾼速化
５０％
５０％

521

vCPU とバックエンドに必要なCPU 時間が同じくらいだと
スケジュールのコストが⼩さい
Split の⽅が Merge より速い

vCPU
threadvCPU
threadバックエンドカーネル
スレッド

schedule
バックエンドカーネル
スレッド
schedule
vCPU
threadschedule
バックエンド
カーネル
スレッド

vCPU
ThreadSoCC ’17, September 24–27, 2017, San
VM 間の転送速度

ハイパー
コール
(I/O)

ハイパー
コール
(I/O)

Throughput [Mpps]

vCPU
thread

16
14
12
10
8
6
4
2
0

Split
Merge
HyperNF

64 512 1024 1472
Packet Size [#](a) No NF - virtual ports.

Kenichi Yasukata, Felipe Huici, Vincenzo Maffione, Giuseppe Lettieri, and Michio Honda. 2017. HyperNF: Building a High Performance, High Utilization and Fair NFV
Platform. In Proceedings of the 2017 Symposium on Cloud Computing (SoCC ʼ17), 157-169.(https://doi.org/10.1145/3127479.3127489)

Split

Merge

提案⼿法

仮想マシン通信の⾼速化
５０％
５０％

522

vCPU とバックエンドに必要なCPU 時間に偏りがあるとスケジュールのコストがあってもMerge の⽅が Split より速い

スレッド(a) No NF - virtual ports.

(b) Bridge NF - virtual ports.

K. Yasukata, F. Huici, V. Ma
ファイアウォールアプリ性能
5
Throughput [Mpps]

vCPU
vCPU
threadSanta Clara, CA,USA
ThreadvCPU SoCC ’17, September 24–27, 2017,
threadschedule
バックエンド
ハイパー
カーネル
コール
スレッド
(I/O)
schedule
バックエンド
カーネル
vCPU
vCPU
スレッド
threadthreadハイパー
schedule
コール
バックエンド
(I/O)
カーネル

4
3
2
1
0

64 512 1024 1472
Packet Size [#](c) Firewall NF - virtual ports.

(

Kenichi Yasukata, Felipe Huici, Vincenzo Maffione, Giuseppe Lettieri, and Michio Honda. 2017. HyperNF: Building a High Performance, High Utilization and Fair NFV
Platform. In Proceedings of the 2017 Symposium on Cloud Computing (SoCC ʼ17), 157-169.(https://doi.org/10.1145/3127479.3127489)

提案⼿法

仮想マシン通信の⾼速化
５０％
５０％
vCPU
threadvCPU
threadvCPU
thread提案⼿法は Merge からスケジュールのコストを削ることで⾼速化
SoCC ’17, September 24–27, 2017, Santa

vCPU
Threadschedule
バックエンド
ハイパー
カーネル
SoCC ’17, September
24–27, 2017, Santaコール
Clara, CA, USA
スレッド
(I/O)
schedule
バックエンド
カーネル
vCPU
スレッド
threadハイパー
schedule
コール
バックエンド
(I/O)
カーネル
スレッド

VM 間の転送速度
Throughput [Mpps]

Merge

16
14
12
10
8
6
4
2
0

Split
Merge
HyperNF

64 512 1024 1472
Packet Size F.
[#]Huici, V. Ma�
K. Yasukata,(a) No NF - virtual ports.
ファイアウォールアプリ性能
5
Throughput [Mpps]

Split

523

4
3
2
1
0

64 512 1024 1472
Packet Size [#]

(b

524
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤
Xen に netmap/VALE を適⽤• ClickOS (NSDI 2014)
QEMU/KVM に DPDK を適⽤• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
実⾏のモデルを改善• ELISA (ASPLOS 2023)

525
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤
Xen に netmap/VALE を適⽤• ClickOS (NSDI 2014)
QEMU/KVM に DPDK を適⽤• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
実⾏のモデルを改善• ELISA (ASPLOS 2023)
パイプラインのような処理の場合は、スレッドを分けない⽅が CPU 利⽤効率が良い

526

研究紹介
仮想マシン通信について
仮想 I/O リクエストに伴う vCPU コンテキストからの exit 削減527
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤• ClickOS (NSDI 2014)• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)• HyperNF (SoCC 2017)
改善• ELISA (ASPLOS 2023)

528
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤• ClickOS (NSDI 2014)• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)• HyperNF (SoCC 2017)
改善• ELISA (ASPLOS 2023)

vCPU
Thread
ハイパー
コール
(I/O)
ハイパー
コール
(I/O)

529
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤• ClickOS (NSDI 2014)• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)• HyperNF (SoCC 2017)
改善• ELISA (ASPLOS 2023)
問題：ハイパーコールの呼び出しのたびに
vCPU からハイパーバイザーのコンテキストへ exit する必要がある

vCPU
Thread
ハイパー
コール
(I/O)
ハイパー
コール
(I/O)

VMEXITVMEXIT

530
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤• ClickOS (NSDI 2014)• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)• HyperNF (SoCC 2017)
改善• ELISA (ASPLOS 2023)
問題：ハイパーコールの呼び出しのたびに
vCPU からハイパーバイザーのコンテキストへ exit する必要がある
モチベーション：vCPU から exit しないで I/O を実⾏できるようにしたい

vCPU
Thread
ハイパー
コール
(I/O)
ハイパー
コール
(I/O)

VMEXITVMEXIT531
仮想マシン通信
⽐較的⼀般的な構成• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
アプリケーション
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR
2015)
TCP/IP スタック
カーネル
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル

仮想 NIC バックエンド

ホスト

TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

仮想スイッチ
NIC デバイスドライバ

アプリケーション532
仮想マシン通信
⽐較的⼀般的な構成• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
アプリケーション
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR
2015)
TCP/IP スタック
カーネル
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

転送リクエスト仮想 NIC バックエンド

ホスト

仮想 NIC バックエンド
仮想スイッチ

NIC デバイスドライバ

533
仮想マシン通信
⽐較的⼀般的な構成• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
アプリケーション
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR
2015)
TCP/IP スタック
カーネル
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

転送リクエストVMEXIT

仮想 NIC バックエンド

ホスト

仮想 NIC バックエンド
仮想スイッチ

NIC デバイスドライバ

534
仮想マシン通信
⽐較的⼀般的な構成• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
アプリケーション
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR
2015)
TCP/IP スタック
カーネル
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル

仮想 NIC バックエンド

ホスト

TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

仮想スイッチ
NIC デバイスドライバ

アプリケーション

535
仮想マシン通信

提案⼿法：仮想マシンに新しいコンテキストを追加• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
アプリケーション
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR
2015)
TCP/IP スタック
カーネル
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル

仮想 NIC バックエンド

ホスト

TCP/IP スタック
NIC デバイスドライバ
仮想 NIC バックエンド

仮想スイッチ
NIC デバイスドライバ

アプリケーション536
仮想マシン通信

提案⼿法：仮想マシンに新しいコンテキストを追加• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
アプリケーション
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR
2015)
TCP/IP スタック
カーネル
NIC デバイスドライバ

NIC デバイスドライバ

仮想 NIC バックエンド

ホスト

ユーザー空間仮想マシン
カーネル

NIC レジスタ

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

仮想スイッチ

537
仮想マシン通信

提案⼿法：仮想マシンに新しいコンテキストを追加- これらは仮想マシンコンテキストの⼀部- ホストと同じく信頼されているドメインとして想定• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
アプリケーション
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR
2015)
TCP/IP スタック
カーネル
NIC デバイスドライバ

信頼されている

NIC デバイスドライバ

仮想 NIC バックエンド

ホスト

ユーザー空間アプリケーション

仮想マシン

TCP/IP スタック

カーネル

NIC デバイスドライバ
信頼されている

NIC レジスタ

仮想スイッチ

538
仮想マシン通信

提案⼿法：仮想マシンに新しいコンテキストを追加- これらは仮想マシンコンテキストの⼀部- ホストと同じく信頼されているドメインとして想定• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
アプリケーション
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR
2015)
TCP/IP スタック
カーネル
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

仮想 NIC バックエンド

仮想 NIC バックエンド

NIC デバイスドライバ

NIC デバイスドライバ

NIC デバイスドライバ

仮想 NIC バックエンド

ホスト

NIC レジスタ

仮想スイッチ

539
仮想マシン通信

提案⼿法：仮想マシンに新しいコンテキストを追加- これらは仮想マシンコンテキストの⼀部- ホストと同じく信頼されているドメインとして想定• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
アプリケーション
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR
2015)
TCP/IP スタック
カーネル
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

仮想 NIC バックエンド

仮想 NIC バックエンド

NIC デバイスドライバ

NIC デバイスドライバ
デバイスドライバやバックエンドのプログラムをロード

NIC デバイスドライバ

仮想 NIC バックエンド

NIC レジスタ

管理⽤仮想マシン（信頼されている）

仮想スイッチ540
仮想マシン通信

提案⼿法：仮想マシンに新しいコンテキストを追加- これらは仮想マシンコンテキストの⼀部- ホストと同じく信頼されているドメインとして想定

仮想マシン間で共有される NIC レジスタや仮想スイッチ関連オブジェクトをマップ• 仮想スイッチへパケット I/O フレームワークを適⽤• VALE (CoNEXT
2012)
アプリケーション
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR
2015)
TCP/IP スタック
カーネル
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

仮想 NIC バックエンド

NIC レジスタ

仮想 NIC バックエンド

NIC レジスタ

NIC デバイスドライバ

仮想スイッチ

NIC デバイスドライバ

仮想スイッチ

NIC デバイスドライバ

仮想 NIC バックエンド

NIC レジスタ

管理⽤仮想マシン（信頼されている）

仮想スイッチ

541
仮想マシン通信

提案⼿法：仮想マシンに新しいコンテキストを追加- これらは仮想マシンコンテキストの⼀部- ホストと同じく信頼されているドメインとして想定
ポイント：コンテキストの移⾏には VMFUNC という CPU 命令を利⽤• 仮想スイッチへパケット I/O フレームワークを適⽤

VMFUNC• VALE (CoNEXT
2012)
アプリケーション
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR
2015)
TCP/IP スタック
カーネル
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

仮想 NIC バックエンド

NIC レジスタ

仮想 NIC バックエンド

NIC レジスタ

NIC デバイスドライバ

仮想スイッチ

NIC デバイスドライバ

仮想スイッチ

NIC デバイスドライバ

仮想 NIC バックエンド

NIC レジスタ

管理⽤仮想マシン（信頼されている）

仮想スイッチ

542
仮想マシン通信

提案⼿法：仮想マシンに新しいコンテキストを追加- これらは仮想マシンコンテキストの⼀部- ホストと同じく信頼されているドメインとして想定
ポイント：コンテキストの移⾏には VMFUNC という CPU 命令を利⽤
VMFUNCは vCPU からの exit を発⽣させない：結果、切り替えが速い• 仮想スイッチへパケット
I/O フレームワークを適⽤

VMFUNC• VALE (CoNEXT
2012)
アプリケーション
ユーザー空間• CuckooSwitch (CoNEXT 2013)
仮想マシン• mSwitch (SOSR
2015)
TCP/IP スタック
カーネル
NIC デバイスドライバ

ユーザー空間仮想マシン
カーネル

アプリケーション
TCP/IP スタック
NIC デバイスドライバ

仮想 NIC バックエンド

NIC レジスタ

仮想 NIC バックエンド

NIC レジスタ

NIC デバイスドライバ

仮想スイッチ

NIC デバイスドライバ

仮想スイッチ

NIC デバイスドライバ

仮想 NIC バックエンド

NIC レジスタ

管理⽤仮想マシン（信頼されている）

仮想スイッチ

543
仮想マシン通信

提案⼿法：仮想マシンに新しいコンテキストを追加- これらは仮想マシンコンテキストの⼀部- ホストと同じく信頼されているドメインとして想定
ポイント：コンテキストの移⾏には VMFUNC という CPU 命令を利⽤
VMFUNCは vCPU からの exit を発⽣させない：結果、切り替えが速い• 仮想スイッチへパケット
I/O フレームワークを適⽤

VMFUNC• VALE (CoNEXT
2012)
アプリケーション
アプリケーション
ユーザー空間
ユーザー空間• CuckooSwitch(CoNEXT
2013)＊仮想マシンは
VMFUNC を通して以外は追加されたコンテキストにアクセスできない
仮想マシン
仮想マシン
• mSwitch (SOSR
2015)
TCP/IP スタック
TCP/IP スタック
カーネル
カーネル
NIC デバイスドライバ

NIC デバイスドライバ

仮想 NIC バックエンド

NIC レジスタ

仮想 NIC バックエンド

NIC レジスタ

NIC デバイスドライバ

仮想スイッチ

NIC デバイスドライバ

仮想スイッチ

NIC デバイスドライバ

仮想 NIC バックエンド

NIC レジスタ

管理⽤仮想マシン（信頼されている）

仮想スイッチ

544
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤• ClickOS (NSDI 2014)• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)• HyperNF (SoCC 2017)
改善• ELISA (ASPLOS 2023)

545
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤
10
Throughput [Mpps]• ClickOS (NSDI 2014)• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)• HyperNF (SoCC 2017)
改善• ELISA (ASPLOS 2023)

VM 間通信速度

既存⼿法

提案⼿法

8
6
4
2
0
64

128

256

512 1024 1472

パケットサイズ546
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤

VMEXIT をなくすことによる改善

10
Throughput [Mpps]• ClickOS (NSDI 2014)• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)• HyperNF (SoCC 2017)
改善• ELISA (ASPLOS 2023)

VM 間通信速度

既存⼿法

提案⼿法

8
6
4
2
0
64

128

256

512 1024 1472

パケットサイズ547
仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシン通信基盤へ適⽤
10
Throughput [Mpps]• ClickOS (NSDI 2014)• NetVM (NSDI 2014)• ptnetmap (ANCS 2015, LANMAN 2016)• HyperNF (SoCC 2017)
改善• ELISA (ASPLOS 2023)

VM 間通信速度

既存⼿法

提案⼿法

8
6
4
2

Linux vhost-net はこれくらい
0
64

128

256

512 1024 1472

パケットサイズ548

最近の取り組み549
最近の取り組み：TCP/IP スタック⾃作• モチベーション• 他のシステムと統合しやすく• マルチコア環境で利⽤できる実装がほしい• + 性能のボトルネックがどこから来るかに興味がある• まだ実装途中ですがよろしければお試しください• ソースコード：https://github.com/yasukata/iip

550
モチベーション
• 既存の多くの TCP/IP 実装は込み⼊ったことをしようと思うと取り回しが良くない場合がある

551
モチベーション
• 具体的に、既存の多くの TCP/IP スタック実装は
1. 特定の OS、ライブラリやネットワーク I/O 機能に依存
2. それら機能が TCP/IP スタック外部から隠蔽されている
3. TCP/IP スタック⾃体にプロトコル処理を⾏うスレッドが含まれる• 結果として、
1. 他のシステムとの統合・コンパイル⾃体が難しい場合がある
2. 機能の隠蔽によって、最適化がしにくくなる場合がある
3. プロトコル処理を⾏うスレッドの実⾏形式が限定される

552
１. 統合・コンパイルが難しい• 例えば、Shenango や Caladan のように独⾃のユーザー空間ス
レッドでプロトコル処理を実⾏しようとすると、既存のpthread や pthread を想定したロックに依存した TCP/IP ス
タック実装は組み合わせるのが難しい• 新しく設計・実装された OS 等の既存の標準ライブラリ等との互換が⼗分でないシステムに適⽤するのが難しい553
２. 機能隠蔽により最適化しにくくなる• 例えば、sendfile システムコールのようにディスクと NIC 間のデータの受け渡しのメモリコピーを削減したいと思った時
既存の TCP/IP スタックが想定する利⽤法

ディスクから読み出したデータ

既存の DPDK を使った
TCP/IP スタック実装
API

TCP/IP

メモリコピーDPDK ⽤パケットバッファ
DPDK
ディスク

554
２. 機能隠蔽により最適化しにくくなる• 例えば、sendfile システムコールのようにディスクと NIC 間のデータの受け渡しのメモリコピーを削減したいと思った時
本当はディスクのデータを
DPDK ⽤パケットバッファへ読み出したい

既存の DPDK を使った
TCP/IP スタック実装
TCP/IP

ディスク

DPDK ⽤パケットバッファ
DPDK

555
２. 機能隠蔽により最適化しにくくなる• 例えば、sendfile システムコールのようにディスクと NIC 間のデータの受け渡しのメモリコピーを削減したいと思った時
本当はディスクのデータを
DPDK ⽤パケットバッファへ読み出したい

既存の DPDK を使った
TCP/IP スタック実装
TCP/IP

ディスク

DPDK ⽤パケットバッファ
DPDK

多くの実装で、DPDK とそのパケットバッファは
TCP/IP スタック実装内部に隠蔽されディスクの直接的なデータ読み込み先として指定できない

556
３. スレッドの実⾏形式が制限される• 既存の実装の多くは⾃前でプロトコル処理を⾏うスレッドを含んでいる
既存の DPDK を使った
TCP/IP スタック実装

while (1) {TCP/IPDPDK ⽤パケットバッファ
DPDK

}

557
３. スレッドの実⾏形式が制限される• 既存の実装の多くは⾃前でプロトコル処理を⾏うスレッドを含
TCP/IP スタック実装利⽤者は以下のような感じでアプリを実装する
んでいる
既存の DPDK を使った
TCP/IP スタック実装

TCP/IP スタック実装利⽤者が実装するアプリwhile (1) {receive_data
process_data
send_data
}

送受信
キュー

while (1) {API

TCP/IPDPDK ⽤パケットバッファ
DPDK

}

558
３. スレッドの実⾏形式が制限される• 既存の実装の多くは⾃前でプロトコル処理を⾏うスレッドを含
TCP/IP スタック実装利⽤者は以下のような感じでアプリを実装する
んでいる
典型的な設定ではアプリと TCP/IP スタック実装のスレッドは別の CPU コアで実⾏する
既存の DPDK を使った
TCP/IP スタック実装

TCP/IP スタック実装利⽤者が実装するアプリwhile (1) {receive_data
process_data
send_data
}

送受信
キュー

while (1) {API

TCP/IPDPDK ⽤パケットバッファ
DPDK}実際は、vCPU かバックエンドのスレッドどちらかが常にボトルネックになる（ワークロード依存）559

仮想マシン通信の⾼速化• パケット I/O フレームワークを使った仮想スイッチを仮想マシ
利⽤されないン通信基盤へ適⽤
CPU 時間実際
Xen に netmap/VALE を適⽤• ClickOS(NSDI 2014)
vCPU
thread (NSDI 2014)
QEMU/KVM に DPDK を適⽤• NetVM• ptnetmap (ANCS 2015, LANMAN 2016)
Xen に netmap/VALE を適⽤• HyperNF (SoCC 2017)
カーネル
実⾏のモデルを改善• ELISA (ASPLOS 2023)
スレッド

主張：vCPU スレッドと仮想スイッチを実⾏する
バックエンドのスレッドを分けない⽅が良い

vCPU スレッドがボトルネック

560
３. スレッドの実⾏形式が制限される• 既存の実装の多くは⾃前でプロトコル処理を⾏うスレッドを含
TCP/IP スタック実装利⽤者は以下のような感じでアプリを実装する
んでいる
典型的な設定ではアプリと TCP/IP スタック実装のスレッドは別の CPU コアで実⾏する
既存の DPDK を使った
TCP/IP スタック実装

TCP/IP スタック実装利⽤者が実装するアプリwhile (1) {receive_data
process_data
send_data
}

送受信
キュー

while (1) {API

TCP/IPDPDK ⽤パケットバッファ
DPDK

}

561
３. スレッドの実⾏形式が制限される• 既存の実装の多くは⾃前でプロトコル処理を⾏うスレッドを含
TCP/IP スタック実装利⽤者は以下のような感じでアプリを実装する
んでいる
典型的な設定ではアプリと TCP/IP スタック実装のスレッドは別の CPU コアで実⾏する

アプリ
スレッド

TCP/IPスレッド

562
３. スレッドの実⾏形式が制限される• 既存の実装の多くは⾃前でプロトコル処理を⾏うスレッドを含
TCP/IP スタック実装利⽤者は以下のような感じでアプリを実装する
んでいる
典型的な設定ではアプリと TCP/IP スタック実装のスレッドは別の CPU コアで実⾏する

アプリ
スレッド

常に空きの CPU 時間ができる
TCP/IPスレッド

563
３. スレッドの実⾏形式が制限される• 既存の実装の多くは⾃前でプロトコル処理を⾏うスレッドを含
TCP/IP スタック実装利⽤者は以下のような感じでアプリを実装する
んでいる
典型的な設定ではアプリと TCP/IP スタック実装のスレッドは別の CPU コアで実⾏する

常に空きの CPU 時間ができる
アプリ
スレッド

TCP/IPスレッド

564
３. スレッドの実⾏形式が制限される• 理想的には• NIC からデータを受け取る• TCP/IP スタック受信処理• アプリ固有処理• TCP/IP スタック送信処理• NIC からデータを送信する• 上記を⼀つのスレッドで実⾏できた⽅が嬉しい

565
lwIP
• ⼩さい組み込みデバイスを想定したポータブルな TCP/IP 実装• （個⼈的に）⾮常に利⽤しやすい上に性能も⾼い• ⼀⽅、• NIC のオフローディング機能に対応していない• NIC とアプリの間でコピーを削除しきれない• 複数スレッドで同時に lwIP を実⾏できるように作られていない

566
モチベーション
• 以下のような特性を持つ TCP/IP 実装が欲しい
1. プロトコル処理の実装が特定の CPU、NIC、OS、ライブラリ、コン
パイラ機能に依存しない
2. 外部の実装に対して、隠蔽する機構が最⼩限
3. TCP/IP スタックがプロトコル処理を実⾏するスレッドを持たない
4. NIC のオフローディング機能を使える
5. NIC とアプリの間でコピーをなくすことができる
6. 複数スレッドで実⾏可能でマルチコア環境で性能がスケールする

567
実装ポイント多くの既存の実装の構成

TCP/IP スタック利⽤者（アプリ開発者）が提供

アプリ
TCP/IP

TCP/IP スタック実装者が提供

パケットバッファ
ネットワーク I/O 機能

568
実装ポイント
今回の実装の構成

TCP/IP スタック利⽤者（アプリ開発者）が提供

アプリ
TCP/IP

TCP/IP スタック実装者が提供

パケットバッファ
ネットワーク I/O 機能

569
実装ポイント
今回の実装の構成

TCP/IP スタック利⽤者（アプリ開発者）が提供

アプリ
TCP/IP

TCP/IP スタック実装者が提供

CALLBACK
パケットバッファ

CALLBACK
利⽤者が実装するコールバック
パケットバッファ確保・解放
NIC からのパケット転送
NIC のオフロード機能通知

ネットワーク I/O 機能

570
実装ポイント
今回の実装の構成
アプリはパケットバッファへ直接送信したいデータを書き込める
TCP/IP スタック利⽤者（アプリ開発者）が提供

アプリ
TCP/IP

TCP/IP スタック実装者が提供

CALLBACK
パケットバッファ

CALLBACK
利⽤者が実装するコールバック
パケットバッファ確保・解放
NIC からのパケット転送
NIC のオフロード機能通知

ネットワーク I/O 機能

571
実装ポイント
今回の実装の構成
アプリはパケットバッファへ直接送信したいデータを書き込める
送信⽤ API には、パケットバッファへのポインタを渡す
TCP/IP スタック利⽤者（アプリ開発者）が提供

アプリ

API
TCP/IP スタック実装者が提供

TCP/IPCALLBACK
パケットバッファ

CALLBACK
利⽤者が実装するコールバック
パケットバッファ確保・解放
NIC からのパケット転送
NIC のオフロード機能通知

ネットワーク I/O 機能

572
実装ポイント
今回の実装の構成
アプリはパケットバッファへ直接送信したいデータを書き込める
送信⽤ API には、パケットバッファへのポインタを渡す
TCP/IP スタック利⽤者（アプリ開発者）が提供

アプリ

API
TCP/IP スタック実装者が提供

TCP/IPCALLBACK
パケットバッファ

CALLBACK
利⽤者が実装するコールバック
パケットバッファ確保・解放
NIC からのパケット転送
NIC のオフロード機能通知

ネットワーク I/O 機能
TCP/IP スタックは利⽤者が実装したコールバックを使ってヘッダを配置するためのパケットバッファを確保＋ヘッダを⽤意

573
実装ポイント
今回の実装の構成
アプリはパケットバッファへ直接送信したいデータを書き込める
送信⽤ API には、パケットバッファへのポインタを渡す
TCP/IP スタック利⽤者（アプリ開発者）が提供

アプリ

API
TCP/IP スタック実装者が提供

TCP/IPCALLBACK
パケットバッファ

CALLBACK
利⽤者が実装するコールバック
パケットバッファ確保・解放
NIC からのパケット転送
NIC のオフロード機能通知

ネットワーク I/O 機能
TCP/IP スタックは利⽤者が実装したコールバックを使ってNIC の Scatter Gather 機能でペイロードにヘッダを結合してパケットを送信：ペイロードのメモリコピーはなし

574
実装ポイント
今回の実装の構成
アプリはパケットバッファへ直接送信したいデータを書き込める
送信⽤ API には、パケットバッファへのポインタを渡す
TCP/IP スタック利⽤者（アプリ開発者）が提供

アプリ

API
TCP/IP スタック実装者が提供

TCP/IPCALLBACK
パケットバッファ

CALLBACK
利⽤者が実装するコールバック
パケットバッファ確保・解放
NIC からのパケット転送
NIC のオフロード機能通知

ネットワーク I/O 機能
TCP/IP スタックは利⽤者が実装したコールバックを使って確保したパケットバッファを解放575
実装ポイント
今回の実装の構成
アプリはパケットバッファへ直接送信したいデータを書き込める
送信⽤ API には、パケットバッファへのポインタを渡す
TCP/IP スタック利⽤者（アプリ開発者）が提供

アプリ

API
TCP/IP スタック実装者が提供

TCP/IPCALLBACK
パケットバッファ

CALLBACK
利⽤者が実装するコールバック
パケットバッファ確保・解放
NIC からのパケット転送
NIC のオフロード機能通知

ネットワーク I/O 機能
ここで利⽤者がアプリで書き込んだパケットバッファを解放しなければ、同じパケットバッファ上のデータを別の宛先へ送ることもできます576
実装ポイント
利⽤者にこのような⾃由度を残せるところが TCP/IP スタック実装が機能の隠蔽を⾏わない利点
今回の実装の構成
アプリはパケットバッファへ直接送信したいデータを書き込める
送信⽤ API には、パケットバッファへのポインタを渡す
TCP/IP スタック利⽤者（アプリ開発者）が提供

アプリ

API
TCP/IP スタック実装者が提供

TCP/IPCALLBACK
パケットバッファ

CALLBACK
利⽤者が実装するコールバック
パケットバッファ確保・解放
NIC からのパケット転送
NIC のオフロード機能通知

ネットワーク I/O 機能
ここで利⽤者がアプリで書き込んだパケットバッファを解放しなければ、同じパケットバッファ上のデータを別の宛先へ送ることもできます577

実験環境（同じ設定のマシン２台）

性能

CPU: 2 x 16-core Intel Xeon Gold 6326 CPU @ 2.90GHz (合計 32 コア)
NIC: Mellanox ConnectX-5 100 Gbps NIC （マシン間はケーブルを直繋ぎして接続）
OS: Linux 6.2• ベンチマークThroughput [ million requests / sec ]- TCP ペイロードは 4 ~ 64 バイト- サーバーが各 CPU コアが 16 TCP 接続へ
応答するようクライアントは接続数を調整- TCP 接続は確⽴後切断しない- なるべく⾼速にメッセージの交換を⾏うLinux TCP/IP

this work

20
18
16
14
12
10
8
6
4
2
0
1

2

4
8
CPU cores [#]

16

32

578

実験環境

性能

CPU: 2 x 16-core Intel Xeon Gold 6326 CPU @ 2.90GHz (合計 32 コア)
NIC: Mellanox ConnectX-5 100 Gbps NIC （マシン間はケーブルを直繋ぎして接続）
OS: Linux 6.2• ベンチマーク16 CPU コア以降、コア数を増やしてもあまり速くならなかった
何故？

Throughput [ million requests / sec ]- TCP ペイロードは 4 ~ 64 バイト- サーバーが各 CPU コアが 16 TCP 接続へ
応答するようクライアントは接続数を調整- TCP 接続は確⽴後切断しない- なるべく⾼速にメッセージの交換を⾏うLinux TCP/IP

this work

20
18
16
14
12
10
8
6
4
2
0
1

2

4
8
CPU cores [#]

16

32

579
簡単な調査
• pqos コマンドでメモリに関する情報を取得• Instruction Per Cycle (IPC)• Cache Miss
• Last-Level Cache occupancy• Memory Bandwidth
https://github.com/intel/intel-cmt-cat/wiki/PQoS-monitoring-metrics-definition

580• 利⽤している CPU コア
全ての IPC の合計

16 CPU コア以降、コア数を増やしてもIPC があまり増えていない

Total Instruction Per Cycle (IPC)

Instruction Per Cycle (IPC)
35
30
25
20
15
10
5
0
1

2

4
8
CPU cores [#]

16

32

581
• 利⽤している CPU コアで観測されたキャッシュミス
回数の合計

16 CPU コア以降、８コアまでの時と⽐べてキャッシュミス回数が⼤幅に増加

Total Cache Misses [ million ]キャッシュミス回数
300
250
200
150
100
50
0
1

2

4
8
CPU cores [#]

16

32

582
メモリ帯域使⽤状況

キャッシュミス増加に合わせて
メモリ帯域の利⽤が増加

35Total Memory Bandwidth
Local + Remote [ GB/s ]• 利⽤している CPU コアで観測されたメモリ帯域
使⽤の合計

30
25
20
15
10
5
0
1

2

4
8
CPU cores [#]

16

32

583
• 利⽤している CPU コアの占有しているキャッシュサイズの合計

コアを増やしてもデータがキャッシュに乗らなくなって性能が制限されているかも？

Total Last Level Cache Occupancy[ MB ]

キャッシュ占有状況50

今回のマシンの CPU は１つあたり24 MB のキャッシュを持っており、
２CPU 構成のため 48 MB が限界と思われる

40
30
20
10
0
1

2

4
8
CPU cores [#]

16

32

584
利⽤する CPU の数を１つにしてみる• 先ほどまでは２つの CPU のコアを同数利⽤していたので、今
度は全てのスレッドを同じ CPU で動かしてみる
⻘が先ほどまでのグラフです

2 CPU (32-core)

1 CPU (16-core)

20
18
16
14
12
10
8
6
4
2
0

Total Last Level Cache Occupancy[ MB ]

Throughput [ million requests / sec ]2 CPU (32-core)

使えるキャッシュサイズが前の実験と⽐べて半分になる

1

2

4
8
CPU cores [#]16

32

1 CPU (16-core)

50
45
40
35
30
25
20
15
10
5
0
1

2

4
8
CPU cores [#]

16

32

585
利⽤する CPU の数を１つにしてみる• 先ほどまでは２つの CPU のコアを同数利⽤していたので、今
度は全てのスレッドを同じ CPU で動かしてみる
⻘が先ほどまでのグラフです

2 CPU (32-core)

1 CPU (16-core)

20
18
16
14
12
10
8
6
4
2
0

Total Last Level Cache Occupancy[ MB ]

Throughput [ million requests / sec ]2 CPU (32-core)

使えるキャッシュサイズが前の実験と⽐べて半分になる

1

2

4
8
CPU cores [#]16

32

１CPUの時の⽅が同じ CPU コア数でも性能が下がった

1 CPU (16-core)

50
45
40
35
30
25
20
15
10
5
0
1

2

4
8
CPU cores [#]

16

32

586
利⽤する CPU の数を１つにしてみる• 先ほどまでは２つの CPU のコアを同数利⽤していたので、今
度は全てのスレッドを同じ CPU で動かしてみる
⻘が先ほどまでのグラフです

2 CPU (32-core)

1 CPU (16-core)

20
18
16
14
12
10
8
6
4
2
0

Total Last Level Cache Occupancy[ MB ]

Throughput [ million requests / sec ]2 CPU (32-core)

使えるキャッシュサイズが前の実験と⽐べて半分になる

1

2

4
8
CPU cores [#]16

32

１CPUの時の⽅が同じ CPU コア数でも性能が下がった

1 CPU (16-core)

50
45
40
35
30
25
20
15
10
5
0
1

2

4
8
CPU cores [#]16

32

使えるキャッシュサイズは性能に影響がありそう

587

まとめ

588
まとめ
• NIC の⾼速化による性能の伸び代を活かす研究についてご紹介しました• 引⽤等は技術レポート「Internet Infrastructure Review (IIR) Vol. 60」
をご参照ください• HTML / PDF 版：https://www.iij.ad.jp/dev/report/iir/060.html• TCP/IP スタックを⾃作してみて、⽐較的最近のハードウェア
での性能の限界がどこから来るか簡単に調査してみました• よろしければお試しください：https://github.com/yasukata/iip