受信→判断→送信までの処理の流れ

ソフトウェア処理とハードウェア処理の遅延に関して考察を加えるために、イーサネッ トケーブルから届いた受信信号に対してアプリケーションプログラムが判断を行い、ケー ブルに送信信号を送出するまでの流れを本研究の環境（

1

ギガビットイーサネット

, PYNQ-Z1, Linux, QuickFIX)

を前提にまとめた。以下の経路は基本的に最短の場合で、プロセス やバッファの状態によってはすぐに先に進めず

Wait

状態になり更に遅延が生ずるケース もある。

1

Linux

マシンのスペックは

CPU:Corei7-3770 3.4GHz, Ethernet Controller: RealTek 8169, OS: Fedora 20 64bit, Kernel: 3.11.10

。

Windows

マシンのスペックは

CPU:Corei7-2600 3.4GHz, Ethernet Controller: RealTek 8168, OS: Windows7 Ultimate SP1 64bit

。

2ソフトウェア実行において

PYNQ-Z1

の遅延が

Fedora

マシンの倍近い数値になっているのは主に

CPU

の動作周波数の差異（PYNQ-Z1(CortexA9): 650MHz, Fedoraマシン

(Corei7-3770):3.4GHz）によると考えら

れる。また、Windows7の遅延値が際立って高いが、必ずしも

WindowsOS

自体の性質ではなく、QuickFIX

の

Windows

版実装固有の現象と考えられる。実際に

Windows7

マシンで別の通信アプリケーションプログ

ラムの遅延を計測したところ

1

ミリ秒以下であった。

5.3.1 ソフトウェア処理の場合

ハードの受信処理

1. LAN

ケーブルから送られてきた電気信号が

RJ-45

コネクタ（

LAN

ポート）に到達

し、信号が

PHY

チップに送られる。

2. PHY

は受信した信号を復号し、誤り訂正を施す。得られたフレームを

RGMII

で

Zynq

の

PS

部に送る。

3. Zynq

の

PS

部に

GMII to RGMII

アダプタが存在し、

RGMII

の信号を

GMII

に変換 し、イーサネットコントローラに渡す。

4.

イーサネットコントローラは

FCS

の確認後、受信したフレームを

PS

部の

DRAM

コ ントローラ経由で

DRAM

（システムメモリ領域）の受信バッファに

DMA

転送する。

5.

イーサネットコントローラは

DMA

転送後に受信完了割り込みを生成し、割り込み コントローラ（GIC)に通知する。

6.

割り込みコントローラは

CPU

の

2

つのコアから割り込みをかけるコアを選択し、割 り込み禁止状態になければプロセッサに割り込みを通知する。

7.

割り込み信号を受け取ったプロセッサはハードウェア割り込みハンドラを起動させる。

Linux

カーネルの受信処理

1.

ハードウェア割り込みハンドラが

Ethernet

ドライバの

xemacps rx

関数を呼び出す。

この関数内でシステムメモリ内の受信バッファからカーネルのソケットバッファに フレームをコピーする。

2.

ハードウェア割り込みハンドラはパケットをキューに格納し、ソフト割り込みを発 生させ、処理を終了する。

3.

ソフト割り込みハンドラが起動し、キューからパケットを呼び出し

IP

層の処理に 移る。

4. IP

層ではヘッダのチェックサムを確認し、パケットが断片化されていない場合は

TCP

層の処理に移る。

5. TCP

層でも種々の確認・処理を行い、最終的にアプリケーション領域のバッファに

フレームを書き込む。

アプリケーションの処理

1. FIX

エンジンが受信用のスレッドを用意し、その受信用スレッドはアプリケーショ

ン用バッファ領域をポーリングで読み続ける。バッファにソケット情報が書き込ま れた時に

FIX

エンジンは処理を開始し、

FIX

アプリケーションプログラムの受信イ ベント

(fromApp)

を発生させる。

2. FIX

アプリケーションのユーザロジックが

FIX

メッセージを処理し、発注判断を行

い、発注する場合は

FIX

エンジンで定義されている送信関数

(sendToTarget)

を呼び 出す。

3. FIX

エンジンが

send

システムコールを発行する。

Linux

カーネルの送信処理

1. send

システムコールが呼び出されカーネルモードに移行する。

TCP

層の

sendmsg

関 数を呼び出し、ソケットバッファを作成し、メッセージをコピーする。

2. TCP

層は

tcp transmit skb

関数にソケットバッファを渡し、

TCP

ヘッダを作成し、

IP

層の

ip queue xmit

関数を呼び出す。

3. IP

層は

IP

ヘッダを作成し、

ARP

解決を行い、データリンク層の

dev queue xmit

関 数を呼び出す。

4.

データリンク層はパケットをデバイスの送信キューに入れ、

qdisc run

関数を実行 する。

5.

キューからパケットを取り出し、ネットデバイスの

hard start xmit

メソッドを呼び 出す。この結果

Ethernet

ドライバの

xemacps start xmit

関数が呼ばれる。

6. xemacps start xmit

関数内でイーサネットコントローラ内のネットワークコントロー ルレジスタの

start tx

（送信開始）ビットを立てる。

ハードの送信処理

1.

イーサネットコントローラは

APB

バス経由でドライバの命令を受け取り、

start tx

ビットが

ON

になると、

DRAM

内の送信バッファから

DRAM

コントローラ経由で フレームを取得し、コントローラ内の

TX

パケットバッファに格納する。

2.

イーサネットコントローラ内の

MAC

トランスミッタがフレームに

FCS

とプリアン ブルを付加して

GMII

バスに送信する。

3. PS

部の

GMII to RGMII

アダプタで

RGMII

の信号に変換され、フレームが

PHY

に 送られる。

4. PHY

はフレームを

1000BASE-T

で伝送するために

8B1Q4

符号化方式により符号化 し、１バイトを

5

値データに変換する。この

5

値データを

4D-PAM5

多値変換方式 で

4

対のツイストペアケーブルに乗せて

125Mbaud

でベースバンド伝送する。

5.3.2 ハードウェア処理の場合

ハードの受信処理

（

4

以外はソフトウェア処理と同じ。）

4’.

イーサネットコントローラは

FCS

の確認後、受信したフレームを

PL

部の

BRAM

内 の受信バッファに

DMA

転送する。

Linux

カーネル受信処理→

FPGA

→

Linux

カーネル送信処理

1.

ハードウェア割り込みハンドラが

Ethernet

ドライバの

xemacps rx

関数を呼び出す。

この関数内で

PL

部の受信フレーム到達フラグを

0xFF

にし、

FIX

プロセッシングユ ニットの処理が開始される。

2. FIX

プロセッシングユニットは

BRAM

からフレームを読み、発注判断を行い、発注

する場合は

BRAM

の送信バッファにフレームを書き込み、フレーム処理完了フラグ を

0xFF

にする。

3. xemacps rx

関数に処理が戻り、イーサネットコントローラ内のネットワークコント

ロールレジスタの

start tx

（送信開始）ビットを立てる。

ハードの送信処理

（

1

以外はソフトウェア処理と同じ。）

1’.

イーサネットコントローラは

APB

バス経由でドライバの命令を受け取り、

start tx

ビットが

ON

になると、

PL

部の

BRAM

内の送信バッファからフレームを取得し、コント ローラ内の

TX

パケットバッファに格納する。

ドキュメント内 JAIST Repository: 金融商品取引アルゴリズムのハードウェアアクセラレーションに関する研究 [課題研究報告書] (ページ 55-58)