Skip to content

Performance

Jump to bottom Edit New page
Yohei Kuga edited this page May 6, 2013 · 10 revisions
Wiki ▸ Performance

概要

現在のハードウェア設計だとPCIe回路がslave mode,かつsplit transactionを使わない非常に単純な実装のため，PCIeがボトルネックになって理論値でも10Mbps (64 byte) 程度しか出せない。 ハードウェア側の実装改善は8月のワークショップまでに、FPGAカードをPCIeのBus Master化することで1GE wire-rate出せるものに作り変える予定。

camera readyは今月末なので実機を使ったパフォーマンス測定は間に合わないが、reviewerから性能についての心配をされているのでパフォーマンスに関する考察をしないといけない。

必要な議論は3つある．

  1. HWのパフォーマンス
  2. Kernel Driverのパフォーマンス
  3. Userland, UNIX Pipe, grep (正規表現)のパフォーマンス

1についてはHW側は対応するHWであるべき回路を作れれば性能が出ることがわかっている（なぜならNICができているから）ので，さらりと流してしまって大丈夫だと思う。

2も1と同様に大丈夫．ドライバの重い処理はほぼcopy_from_user (write)とcopy_to_user (read)のはず．もし議論するならCPU Cycle数とかで議論できると思う．

3が，reviewerに心配された部分だとおもう．

そこで、SWだけ切り話した仮想デバドラを作って、潜在的なパフォーマンスを測定する (dummy driver)。 dummy driverは，単にdevice driverのフリをするだけでなく，本番同様に実際にPCメモリにread/writeすることで，SW側のパフォーマンスを測定する．

Dummy driverを使ったコマンドラインモードの性能測定

SWパフォーマンスに関する計測内容は2つ

  1. キャラクタデバイス型IOのポテンシャル
  2. アプリケーション章で挙げたコマンドの性能

#### 1. キャラクタデバイス型IOのポテンシャル

今回の論文にはいらないかもしれないけど性能限界を知っておくのは重要． 計測シナリオは以下の3つ

  • read, dd if=/dev/ethpipe of=/dev/null
  • write, dd if=/dev/zero of=/dev/ethpipe
  • read and write, dd if=/dev/ethpipe of=/dev/ethpipe

上記のシナリオに加えて，ddのバッファサイズ(block size)を変更しながら計測する必要がある

  • x軸: dd block size
  • y軸: Throughput

でグラフを作る． Frame sizeは64 byteに加えて，1518 byteもやったほうがよさそう． block size変更によるpar packet処理の遅延に関する議論も必要．

#### 2. アプリケーション章で挙げたコマンドの性能

表: 列1:command名, 列2: Throughput (64 byte), 列3: Throughput (1518 byte)

Kernel driverの実装

https://github.com/sora/ethpipe/blob/master/software/dummy_driver/ethpipe.c

実際に使っているdriverで擬似的に64 byteのフレーム (ascii化してあるので，実際のデータサイズは169 byte)のデータを生成する． その際DEST MAC addressを001111111111から009999999999とFFFFFFFFFFFFでラウンドロビンで変更するして出力

該当コード

for ( i = 0; i < (MAX_TEMP_BUF-4096); ) {
	memcpy( phy0_rx_ptr+i, "FFFFFFFFFFFF 0022CF63967B 8899 23 1E 0A CF E5 3A DF 00 22 CF 63 96 7B 00 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20\n", 169);
	switch ( num % 10 ) {
		case 0:  memcpy ( phy0_rx_ptr+i, "001111111111", 12); break;
		case 1:  memcpy ( phy0_rx_ptr+i, "002222222222", 12); break;
		case 2:  memcpy ( phy0_rx_ptr+i, "003333333333", 12); break;
		case 3:  memcpy ( phy0_rx_ptr+i, "004444444444", 12); break;
		case 4:  memcpy ( phy0_rx_ptr+i, "005555555555", 12); break;
		case 5:  memcpy ( phy0_rx_ptr+i, "006666666666", 12); break;
		case 6:  memcpy ( phy0_rx_ptr+i, "007777777777", 12); break;
		case 7:  memcpy ( phy0_rx_ptr+i, "008888888888", 12); break;
		case 8:  memcpy ( phy0_rx_ptr+i, "009999999999", 12); break;
		default: break;
	}
	i += 169;
	++num;
}

計測スクリプト

以下のtest_scriptが計測スクリプト

https://github.com/sora/ethpipe/blob/master/software/dummy_driver/test_script

テスト内容

1. readの性能
2. read and writeの性能
3. grepの性能
   - grepパターン => grep '"001111111111\|002222222222\|003333333333\|004444444444\|FFFFFFFFFFFF"
   - MB/s 計算式 => 行数 / 実行秒数(5秒) * grepの条件(半数のフレームにマッチするので実際のフレーム数は2倍) * フレームサイズ (169byte) / 1024 /1024
   - PPS 計算式 => wc -l

テスト方法

0. Linuxマシンを用意
1. HDDがボトルネックにならないようにramdisk (tmpfs) を作成
   - ramdisk の作成方法
   - $ mkdir ~/ramdisk
   - $ chmod 777 ramdisk
   - $ sudo mount -t tmpfs -o size=3g /dev/shm ramdisk
2. dummy driverをlinuxでコンパイル (make)
3. insmod ./ethpipe.ko
4. /dev/ethpipe が作成されているはず
5. lsmod でloadできているか確認
6. cd ramdisk
7. test_scriptを実行

結果

  1. sora desktop (Intel Core i5 760)
$ sudo ./test_script
[sudo] password for sora:
Measuring the /dev/ethpipe receive throughput.
0+1024 records in
0+1024 records out
1073639424 bytes (1.1 GB) copied, 0.0765995 s, 14.0 GB/s
Measuring the /dev/ethpipe receive and transmitte throughput(forwarding).
0+1024 records in
0+1024 records out
1073639424 bytes (1.1 GB) copied, 0.150653 s, 7.1 GB/s
Measuring the GREP throughput.
grep "001111111111\|002222222222\|003333333333\|004444444444\|FFFFFFFFFFFF" < /dev/ethpipe > output.txt
./test_script: line 9:  9098 終了しました      grep
"001111111111\|002222222222\|003333333333\|004444444444\|FFFFFFFFFFFF" < /dev/ethpipe > output.txt
421 MB/s
2616630 pps

結果

  • packet capture (readだけ) なら112 Gbps を超える性能なので，ボトルネックにならない
  • bridgeで 56.8Gbps．これも大丈夫そう
  • shortestフレーム+grepでも421 MB/s (3,368 Mbps)でているので，1Gならば問題なくwire-rateで動作可能

考察

  • キャラクタデバイスのread/writeはとてもはやい．ペイロードまでみても問題ないだろう
  • ボトルネックはrewrite部分．1G処理ならUNIX Commandでいける．10G処理にはマルチコアやGPUなどのオフローディングを利用した専用コマンドが必要だろう．それでも，UNIX Pipeでそれらのコマンドに入出力できるコマンドを作るだけで良い

Todo

  • もう少しtestシナリオを色々増やしてみる
    • parallel grep
    • 正規表現ぽいパターン (アスタリスクなど)
Add a custom footer
Add a custom sidebar
Clone this wiki locally