SmartNic

# Low Latency Custom FPGA Accelerate

個別アプリケーション、ネットワーク運用に特化したFPGAアクセラレーション

# はじめに
一部クラウドとネットワークを接続するために、GREトンネルを運用していますが、このGREトンネルはアプライアンスSwitchで接続しています。
例えばクラウドで仮想マシンを追加した場合、同様に双方向のトンネリングSwitchに対してGREトンネルのコンフィグレーション追加が必要なため管理が煩雑になっているという課題がありました。
このトンネリングネットワークはセキュリティ面で問題のない場所に配置されているので、GREトンネルDecap側をFPGAで置き換え、GREパケットであれば無条件にDecapする処理に変更することができます。そうすることで仮想マシンを追加してもネットワーク スウィッチに追加コンフィグレーションが不要となり、コンフィグ管理の煩雑さを軽減することができます。
このようなネットワークの効率的な管理のためにFPGAアクセラレートを検証・評価しました。
この資料では、特定ケースにおけるネットワーク設計・運用における効率的・実用的なFPGAアクセラレーションソリューションについて説明します。

<img width="747" alt="ned_00.png" src="https://qiita-image-store.s3.amazonaws.com/0/165490/b527e180-c338-e213-0279-a0c5a5fb3ff4.png">


# Timing Chart - Decap
今回評価対象としたFPGAインタフェイスは、１cycleで、256bit(32Byte)パケットを受信できます。１列目は入力パケットを示します。GREパケットはL3トンネルなので２パケットまで受信すれば、decap処理を開始することができます。
Logic Analyzerを追加して確認したところ、GREトンネルの最小サイズ(ethフレーム(64) + 外側ipv4(20) + gre(4) Byte = 88 Byte)ケースで5〜7 cycleで１フレームを受信できます。またDecap 処理で2cycle分の受信データをバッファリングして 3 cycle遅延でパイプライン実装設計することができました。

<img width="714" alt="net_002.png" src="https://qiita-image-store.s3.amazonaws.com/0/165490/834ac82c-54b7-0b10-f0e5-ae53330e1f66.png">


# State Machine
前記のDecap処理を行うために、今回は以下のようなステートマシンにて実装しています。初期状態(INIT)から、受信したパケットが処理対象であるGREであるか否かを判断して状態遷移し、valid信号の有無で待機状態とペイロード部処理状態を行き来します(WAIT↔PAYLOAD)。最後に、EndOfPacketを示すEOP状態へ遷移し、初期状態へ戻ります。

### 状態遷移図

<img width="755" alt="ned_003.png" src="https://qiita-image-store.s3.amazonaws.com/0/165490/e1fd8fa2-5fa3-0f70-1f89-245a2ec391ad.png">



# プラットフォーム比較
GRE - Decap処理をFPGAアクセラレートし、パフォーマンス（レイテンシ、スループット）をFPGA アクセラレート、DPDK[1]、および　アプライアンスSwitch[2]間で比較します。評価トポロジを次図に示します

<img width="703" alt="ned_004.png" src="https://qiita-image-store.s3.amazonaws.com/0/165490/6db69dc8-7614-c30d-d5b8-3fe80c23571c.png">


# プラットフォーム比較結果
それぞれ1パケットでのレイテンシは次表のようになりました。DPDKはユーザランドソフトウェア処理であり、プールモード+バッチ処理によって高速パケットプロセッシングを実現するプラットフォームですので１パケットでレイテンシが高いのは想定通りです。そして電力消費においても、DPDK実装では、CPUをBusyLoopで占有しますのでFPGAと比較すると大幅に高くなります。


<img width="809" alt="ned_009.png" src="https://qiita-image-store.s3.amazonaws.com/0/165490/9c7db8f0-bbde-2d7f-f8f5-a35c169cd7be.png">



decap rateは、decap処理によるpass through(TCP)処理からのパフォーマンス悪化率((GRE - TCP)/TCP = decap rate)


# プラットフォーム比較考察
消費電力、パフォーマンスの両面からFPGAによるDecap処理がもっとも効率が良いと言えます。また、DPDKによるDecap処理は消費電力さえ考えなければ、非常にコストパフォーマンスが良いと言えます。とはいえ、ソリューションには、常にメリットとデメリットの両面があり、自社チームの状況に応じたソリューションを選択することがもっとも重要だと思います。

<img width="621" alt="ned_005.png" src="https://qiita-image-store.s3.amazonaws.com/0/165490/94b702ea-f4f2-c352-991a-5ba01dc4c185.png">


## Switch
　・メリット　：安定性と人的リソースの配置しやすさ
　・デメリット：コンフィグ管理が煩雑（このケースでは）
## FPGA
　・メリット　：消費電力、パフォーマンス効率
　・デメリット：人的リソース配置難、開発環境等
## DPDK
　・メリット　：人的リソース配置しやすい
　・デメリット：開発環境の追随、消費電力、レイテンシ

## Switchモジュール論理構成
<img width="636" alt="ned_006.png" src="https://qiita-image-store.s3.amazonaws.com/0/165490/e2b4754e-dfa2-544f-f1f2-f1340b714ec5.png">



## FPGAモジュール論理構成
<img width="597" alt="ned_007.png" src="https://qiita-image-store.s3.amazonaws.com/0/165490/b26f81d9-01e8-49bb-fbbf-d290ffd1e792.png">


## DPDKモジュール論理構成

<img width="582" alt="ned_008.png" src="https://qiita-image-store.s3.amazonaws.com/0/165490/c646417b-5ce2-31e3-4a8c-a5e8760b2399.png">


# まとめ
昨今サービスのクラウド化・集中化に、ネットワーク機器の拡張は追いついていないと言われており、そこにはSDNやNFV[4]のソリューションがあります。しかし本ケースでアプライアンスSwitch、FPGA、DPDKを比較検証し示した通り、狭義のSDNやNFV[4]では最適なソリューションとならないケースがあることを説明しました。
別々のネットワーク機器が必要だった多様なネットワーク機能の一部をFPGAや、DPDKアプリケーションによってアクセラレートすることができます、本ケースのように自社ネットワーク要件によっては、独自にFPGAで一部のネットワーク機能を代替する方が効率が良いケースもあります、このようなケースでFPGA(プログラマブル)が選択肢になるのは、広義のSDNとNFVだとも言えます。

# 参考資料
[1] https://www.dpdk.org/
[2] https://www.juniper.net/jp/jp/products-services/switching/qfx-series/qfx5100/
[3] https://www.altera.co.jp/solutions/acceleration-hub/overview.html
[4] https://www.nic.ad.jp/ja/newsletter/No58/0800.html