衛星アンテナ

ホワイトペーパー

PCIeデータキャプチャ

概要

高解像度センサーは、その出力をホストコンピュータが取り込んで処理できるものにまで減らすために、FPGAの前処理を必要とするデータレートを生成します。FPGA後のデータレートが約40Gb/秒を超える場合、そのデータをホストに取り込むには特別なソリューションが必要です。

BittWare は、お客様のIPのニーズに柔軟に対応し、コスト削減を実現するアーキテクチャーのコンセプトを持っています。

このホワイトペーパーでは、BittWareの高速データキャプチャとレコーダのコンセプトのうち、データキャプチャコンポーネントを取り上げています。PCIeバス上のホストDDR4への100Gb/sの持続的なキャプチャを達成するために使用されたテクニックのいくつかを説明します。

PCIeデータキャプチャのアーキテクチャ上の目標

このコンセプトの目標は、FPGAからマザーボードに100Gb/sを実現し、顧客が多くのCPUコアを使用してそのデータを処理できるようにすることです。FPGAカードからPCIeを経由し、CPUからホストのDDR4へデータを移動します。オプションで、永続的なメモリに記録するコンポーネント(このタスクには専用のCPUが必要)や、2つのCPUを使用してDDR4に200Gb/sをキャプチャするための2番目のPCIeを追加することができます。

データ・キャプチャー・コンセプトは、AMD および Intel FPGA ベースの製品をお持ちのお客様向けに、BittWare Developer ウェブサイトでご覧いただけます。AMD VirtexUltraScale+ VU9P FPGAの12%を消費します。このプロジェクトを別のBittWare Agilex またはUltraScale+ カードに適合させることは、お客様自身で比較的簡単に行うことができます。 

データキャプチャ図解
アプリのサムネイル
データキャプチャアプリノートのサンプルページ

アプリノートを請求する

このホワイトペーパーに記載されている以上の詳細が必要ですか?データキャプチャーのコンセプトに関するドキュメントを提供するApp Noteをご請求ください。ここをクリック >>

100Gb/sのPCIeデータキャプチャを実現した理由

PCIeの理論 vs. 実践

理論的には、PCIe Gen 3 はレーンあたり 985 MB/s の転送が可能です。16 倍速の場合、各方向で 15.760 GB/s (126 Gb/s) となり、100 Gb/s の目標を大きく上回ることになります。しかし、経路上にはプロトコルとバッファ管理のレイヤーが存在します。この点については、Rolf Neugebauer 氏によるUnderstanding PCIe performance for end host networking」という優れた学術論文があります。

実際には、BittWare's PCIe Data Captureは、FPGAからホストDRAMに12.8GB/s(102Gb/s)を押し込むことができました。これは、PCIeの理論上の最大転送速度の80%強に相当する。

実際の PCIe 転送はもっと低く、システムを最適化するために使用する特定のアプローチに大きく影響されます。100Gb/sを達成することは、実はPCIにストレスを与える良い方法です。非常に大きなパケットサイズの場合、100Gbイーサネット(GbE)は12.5GB/sに近づき、メタデータ用に300MB/sのヘッドルームを残しています。しかし、飽和状態の100GbEがすべて小さなパケットで構成されている場合、全体のデータレートは大幅に低下しますが、PCIeバスのトランザクション数は増加するため、PCIeには別の方法でストレスを与えることができます。

私たちは、BittWare のお客様が一般的に使用している独自のセンサーの代わりにイーサネットを使用しています。私たちのソリューションは、大きなパケットも小さなパケットも、いずれも落とすことなく通過させることができます。次に、私たちがどのようにそれを行ったかを説明します。

実装編その1.ホストの最適化

PCIeで広帯域のデータをプッシュする場合、実はFPGA内部ではなく、ホストのソフトウェア側で1つの最適化を行うことができる。CPUの内部アーキテクチャに注目してみてください。

性能目標を達成するためには、チップのPCIeインターフェイスとDRAMインターフェイスの間に位置する すべてのCPUコアが、他の作業をしていなくても、フルクロックで動作しなければならない(省電力モードはない)。別の言い方をすれば、各CPUコアはC-StateゼロとP-Stateゼロである必要がある。Linuxでは、「tuned-adm」コマンドで「latency-performance」オプションを選択することでこれを実現できる。

CPUアーキテクチャ図

実装編その2:PCIeの最適化

コンソリデーションによるPCIeトランザクションの最適化

FPGA 側で最も重要なことは、バス上でデータを移動するために必要なPCIe トランザクションの数を最小限に抑えることです。これは、すべてのPCIeトランザクションがシステムで取り決められた「最大ペイロード」サイズ(最近のIntelベースのシステムでは通常256バイト)を達成できるように設計されたバッファ管理スキームで、複数のパケットを統合することを意味します。

そこで、BittWare'の提供するサービスの主な機能は、この統合機能を実行することです。パケットをMBUFと呼ぶ固定サイズのバッファに統合するのです。

MBUF サイズは FPGA の初期化時に変更することができます。前述のとおり、MBUF は PCIe の最大ペイロードサイズの固定倍数である必要があります。後述する理由により、4k バイトを使用することを推奨します。

FPGAの処理では、制御の別スレッドで処理するためにパケットをグループ化することが非常に一般的です。このようなグループ化を「キュー」と呼びますが、各キューはホスト側の異なる処理コアに流す必要があります。したがって、パケットの統合はキュー単位で行う必要があります。

私たちのコンソリデーション機能はHLSで書かれており、次に説明するキュー管理機能の上で実行されます。

パケット連結図

ホストキュー

我々のIPは、MBUFのストリームをホストDRAMに送る。このようなことをする他の人たちと同じように、我々はDRAMのサーキュラー・キューを使用している。しかし、AMDでは、QDMAキューを使わず、QDMAのブリッジング機能の上に独自の代替機能を作っている。

AMD QDMAキューはRDMAデータ構造に基づいている。RDMAは必要以上に動的な環境です。我々のバージョンにはディスクリプタ・リングがあるが、ホスト・ドライバはFPGAの初期化時にディスクリプタをロードし、我々はそれを再利用する。このようにすることで、実行時にPCIe経由でディスクリプタを送信することを避けることができる。加えて、さらに大きな逸脱として、完了キューは持っていません。その代わり、ディスクリプタを再利用し、FPGAがホストが処理できる速度よりも速くデータを移動しているかどうかをホスト・ソフトウェアに判断させるだけです。別の言い方をすれば、FPGAでデータをドロップする代わりに、ホストでデータをドロップする。RDMAの用語では、ホスト・ドライバがFPGAにCIDXアップデートを送信することはありません。

私たちのキューの実装では、割り込みの代わりにホスト側でポーリングを使用しています。これは、どちらの方法でもFPGAがPIDXの更新をホストに送信する必要があるため、割り込みがより多くのPCIe帯域を消費するためです。実験によると、最新のCPUでは、PIDXの更新は合計4kバイトのMBUFのシーケンスを転送した後に行われる必要があることがわかりました。そのため、1つのMBUFを4kバイトにすることを推奨しています。

ホスト側では、キューディスクリプタが巨大なページを指すようにします。こうすることで、CPUのTLBミスを最小限に抑えることができます。また、FPGAカードの位置に応じて、特定のホストNUMAゾーンに巨大ページを割り当てることで、特定のNUMA領域にロックされたホスト処理スレッドに対するFPGA DMA転送の経路を制御することができます。

データ・キャプチャーの最初のリリースは、AMD XDMAの上にレイヤー化されています。2番目のリリースでは、AMD QDMAのブリッジング・モードの上にレイヤー化された独自のDMAトランスポートに移行する予定です。

ホストコントロール

当社のPCIe Data Captureコンセプトは、標準的なLinux VFIOドライバを使用しています。これにより、CPUの仮想化ハードウェアがプロセス保護とセキュリティを提供することができます。カードを制御するためにPython APIを提供します。Pythonプログラムを使用して、FPGAに記述子をロードし、DRAMキューをセットアップし、アプリケーションコードをキックオフします。BittWare's Toolkitは現在、ドライバとしてVFIOをサポートしていませんが、将来的にサポートが予定されています。

アプリケーションの処理

BittWareのホスト側の処理フレームワークは、DPDK(Data Plane Development Kit)をモデルにしています。ホスト側では1つのターゲットキューを使用します。専用コアが受信したMBUFを解析し、MBUFのポインタをワーカースレッドのコレクションに送ります。専用コアは、どのようなMBUFサイズでもこのタスクを実行することができます。

今後、内部データ構造をPCAPng形式に再フォーマットするワーカープログラムのサンプルを公開する予定です。パケットサイズに関わらず、100GbEの回線速度に対応するためには、ワーカーコアが4個程度必要です。

PCIeデータキャプチャの追加オプション 建築コンセプト

このコンセプトには2つのオプションコンポーネントがあり、1つはSSDに記録要素を追加するもの、もう1つはXUP-P3Rの能力を利用して2番目のPCIeインターフェースを持ち、最大200Gb/sのキャプチャを可能にするものです。

100Gb/sの記録

2ソケットのマザーボードで、100GbEパケットストリームを記録することが可能です。BittWare IPは、ソケットの1つに接続されたホストDRAMにパケットをキャプチャします。 その後、アプリケーションソフトウェアが、プロセッサーソケット間のQPIリンクを介してMBUFを、もう一方のCPUソケットのPCIeに接続されたRAID 0 NVMeに移動させます。この方法については、今後のホワイトペーパーで説明する予定です。まとめると、皆さんが思っているよりも多くのNVMeドライブが必要です。それは、一般的なTLC SSDのNVMeドライブのデータシートが、疑似SLCキャッシュへの書き込み性能を指定する傾向があるためです。このキャッシュをオーバーフローさせると、書き込み性能が極端に低下します。最新のQLC SSDは、長時間のエンドレスなストリーミング書き込みにおいて、旧来のディスク技術よりも実際に遅くなることがあります!

データ・キャプチャ・シングル・レコード・ブロック図

デュアルPCIeで200Gb/s

2CPU搭載のTeraBoxに3rdスロットのアドオンカードを追加することで、XUP-P3RはGen3 x16のPCIeインターフェース2本で200Gb/sを実現する!

デュアルPCIeデータキャプチャ

100Gb/s以上のキャプチャを必要とするお客様には、XUP-P3RのSEP to PCIeアドオンカードをご利用いただくことも可能です。これにより、ホストメモリーへの接続は最大で約200Gb/sを実現できます。2つ目の接続は、隣接するPCIeスロットに接続します。このオプションでは、永続的なメモリにラインレートで記録するオプションがないため、2つ目のCPUが消費されることに注意してください。

また、2つ以上のCPUを搭載したマザーボードに2枚のFPGAカードを使用することも可能です。

デュアルCPUに拡張カードを接続したXUP-P3Rのイメージ図

結論

今日のセンサーはより高速になっており、CPUには2つの課題があります。1つ目はI/OをCPUに取り込むこと、2つ目はセンサデータを実用的な情報に変換することです。FPGAは、ハードウェアによる前処理でこのギャップを埋めるためによく使われますが、データ量を減らしても、多くの場合、CPUにストレスを与えるには十分です。

今回のホワイトペーパーでは、PCIeの帯域を最大化して100Gb/sまでキャプチャする方法について、DRAMへのCPUキャプチャを含めて検討しました。それでもCPUにストレスを与える可能性が残るので、次回のホワイトペーパーではCPUを完全にバイパスしてNVMeに直接記録する方法を紹介します。

BittWare は、お客様がデータを CPU に取り込むのを支援してきた長年の経験を活かし、これらの問題を解決するためのアーキテ クチャ・コンセプトを作成しました。また、BittWareの FPGA カードと統合サーバーの幅広いポートフォリオを活用することで、大規模な展開が可能となり、特定のユースケースに対応したデータキャプチャとレコーダーのアプライアンスを容易に構築することができます。BittWareのソーシャルメディア・チャンネルをフォローして、最新の出版物を入手しましょう。

もっと読みたいものがある:データキャプチャーのアプリを入手する 注

PDFダウンロードを希望する

このページで紹介するのは、BittWare's Data Captureの紹介です。詳細については、App Noteの全文に記載されています!PDF版アプリノートへのアクセスは、フォームに記入してください。

アプリのサムネイル
データキャプチャアプリノートのサンプルページ

"*"は必須項目

名称*
PDFはこのアドレスを使って送信されますので、これが有効なメールであることを確認してください。
住所・都市名*