> [!abstract] 概要(Abstract 日本語訳) > 近年、プログラマブルNICの発展と普及に伴い、エンドホストはロードバランシング、輻輳制御、アプリケーション固有のネットワークオフロードといったコアなネットワーク機能の実施点としての役割を増している。しかし、プログラマブルNIC上にカスタム設計を実装することは容易ではない。多くの潜在的なボトルネックが性能に影響を与えうるからだ。 > 本論文は、現代のサーバにおけるデファクトのI/O相互接続であるPCIeが、ホストアーキテクチャおよびデバイスドライバと相互作用する際に及ぼす性能への影響に焦点を当てる。我々はPCIeの理論モデルと、開発者がPCIe基盤について正確かつ深い理解を得られるオープンソースのスイートである pcie-bench を提示する。pcie-bench を用いて、我々は現代のサーバにおけるPCIeサブシステムを特性評価する。我々はPCIe実装間の驚くべき差異を明らかにし、IOMMUのようなPCIe機能がもたらす望ましくない影響を評価し、40Gb/s以上で動作する一般的なネットワークカードにとっての実用上の限界を示す。さらに、pcie-bench を通じて我々は、商用・研究向けの双方のネットワークカードおよびDMAエンジンについて、ソフトウェアおよび将来のハードウェアアーキテクチャを導く洞察を得た。 ## 論文情報 - タイトル: Understanding PCIe performance for end host networking - 著者: Rolf Neugebauer(Independent Researcher)、Gianni Antichi(Queen Mary, University of London)、José Fernando Zazo(Naudit HPCN)、Yury Audzevich(University of Cambridge)、Sergio López-Buedo(Universidad Autónoma de Madrid)、Andrew W. Moore(University of Cambridge) - 媒体・発表年: ACM SIGCOMM 2018(2018年8月20〜25日、ブダペスト)、pp. 327-341 - DOI: https://doi.org/10.1145/3230543.3230560 - コードURL: https://www.pcie-bench.org(pcie-bench オープンソーススイート) - キーワード: PCIe, reconfigurable hardware, Operating System ## 概要 本論文は、40Gb/s以上のネットワークアダプタが一般化する中で、PCIeの物理・データリンク・トランザクション各層のオーバーヘッドとホストアーキテクチャ(NUMA、DDIO、IOMMU)との相互作用が、エンドホストのネットワーキング性能のボトルネックになりつつあると論じる。理論モデルとマイクロベンチマーク一式 pcie-bench を構築し、Netronome NFPとNetFPGAという二つの独立実装で複数世代のIntel Xeonサーバを比較・特性評価した。 ## 問題設定 PCIeは長らく広く研究対象とされてこなかったI/O相互接続だが、40Gb/s以上のデュアルポートNICのようにPCIeの能力に迫る、あるいは超えるI/Oデバイスが登場したことで、ハードウェア・ソフトウェア協調設計の必要性が急速に高まった(§2)。著者らは、PCIe単体のプロトコルオーバーヘッドに加え、ホスト側の(1) NUMAによる不均一メモリアクセス、(2) Intel Data Direct I/O(DDIO)によるキャッシュ統合、(3) IOMMUによるアドレス変換、という3つの近年のPCIeルートコンプレックス側の技術進化が、プログラマブルNICや高性能アクセラレータカードの設計に与える影響を横断的に定量化する必要があると位置づける。 **PCIeがスループットに与える影響**: 40Gb/s NICで一般的なPCIe Gen 3 x8インターフェースは物理層で62.96Gb/sの帯域を持つが、PCIeプロトコルオーバーヘッドにより実効帯域は約50Gb/s、アクセスパターン次第ではそれ以下まで低下する。 **Figure 1: PCIe Gen 3 x8リンクの理論モデル帯域とNIC実装ごとの実効スループット** ![[_attachments/p327-neugebauer/fig01-effective-bw-model.png]] (Figure 1. モデル化されたPCIe Gen 3 x8リンクの双方向帯域(Effective PCIe BW、黒実線)、40G Ethernetの要求帯域(青点線)、単純なNIC実装(Simple NIC、緑破線)、典型的なカーネルドライバを使う現代的NIC(Modern NIC (kernel driver)、灰破線)、DPDKドライバを使う現代的NIC(Modern NIC (DPDK driver)、赤一点鎖線)の転送サイズごとの実効帯域。ノコギリ歯状のパターンはPCIeのパケット化構造(データがMPSごとのPCIeパケットに分割され、それぞれにヘッダが付与される)に起因する。単純なNIC実装では、512Bを超えるEthernetフレームでしか40Gb/sのライン速度を達成できない。Source: Figure 1.) パケットデータ自体の転送に加え、NICはTX/フリーリストディスクリプタの読み出し、RX(場合によってはTX)ディスクリプタの書き戻し、割り込みの生成を行い、デバイスドライバもキューポインタの読み書きを行う。これらすべてがPCIe帯域を消費する追加トランザクションとなる。 **PCIeがレイテンシに与える影響**: 著者らはExaNIC(カーネルバイパスNIC)を用いてループバックテストを実施し、末端ホストのネットワークアプリケーションレイテンシに対するPCIeの寄与を測定した。ExaNICファームウェアを改造してPCIe寄与分のみを分離計測している。 **Figure 2: ExaNICでのNIC PCIeレイテンシ計測** ![[_attachments/p327-neugebauer/fig02-nic-pcie-latency.png]] (Figure 2. 128Bペイロードの往復レイテンシは約1000nsで、そのうち約900nsがPCIeに起因する。パケットサイズを増やすほどPCIeの寄与率は下がるが、1500Bでも77.2%、小パケットでは90.6%を占める。40Gb/sイーサネットのライン速度で128Bパケットを扱うには29.6nsごとに新しいパケットを送受信する必要があり、レイテンシが対称だと仮定すると、NICは各方向で少なくとも30個の同時DMAをハンドルする必要があることを示す。Source: Figure 2.) **PCIeルートコンプレックスの進化**: 近年のx86サーバでは、PCIeルートコンプレックスがメモリコントローラとともにCPUコアに緊密統合され、Intel DDIOのようにPCIeデバイスとCPUキャッシュの結合が進んだ。マルチソケットシステムではこれがPCIeデバイスのNUMA性を生み、加えて多くの現代システムはIOMMUをデータパスに介在させ、アドレス変換とTLBミスによるページテーブルウォークの遅延を生む可能性がある。これらの技術はレイテンシ・帯域だけでなく、キャッシュやIOMMU TLBの一時状態に依存する変動(分散)ももたらす。さらにARM64・Powerアーキテクチャの実装詳細は非公開であることが多く、研究者による横断的な特性評価を困難にしている。 ## 提案手法 ### PCIeの理論モデル(§3) PCIeは物理層・データリンク層(DLL)・トランザクション層の3層からなるポイントツーポイントのシリアル相互接続である。DLLは誤り訂正・フロー制御・確認応答を担い、トランザクション層はアプリケーションデータをトランザクション層パケット(TLP: Transaction Layer Packet)に変換する。 典型的な40Gb/s NICはPCIe Gen 3 x8(8レーン、各8GT/s、128b/130bエンコーディング)を持ち、物理層で `8 × 7.87 Gb/s = 62.96 Gb/s` を実現する。DLLがフロー制御・確認応答のために約8〜10%のオーバーヘッドを追加し、TLP層で利用可能な帯域は約57.88Gb/sまで下がる。各トランザクションには物理層の2Bフレーミングと6BのDLLヘッダが付与される。 関連する主要TLPタイプは、Memory Read(MRd)、Memory Write(MWr)、Completion with Data(CplD)である。共通ヘッダは4B、MWr/MRdのヘッダは(64bitアドレッシング時)12B、CplDのヘッダは8Bである。1つのTLPが運べる最大データ量(Maximum Payload Size, MPS)はピア間で合意され、典型値は256Bまたは512B。 PCIeメモリ書き込み(MWr)はポステッドトランザクションで、サイズ `sz` のDMA書き込みの転送バイト数は: $B_{tx} = \lceil sz / \text{MPS} \rceil \times \text{MWr\_Hdr} + sz \quad (1)$ ここで `MWr_Hdr` は24B(2Bフレーミング + 6B DLLヘッダ + 4B TLPヘッダ + 12B MWrヘッダ)。一方PCIeメモリ読み出し(MRd)はMRd TLPとCplD TLPの2種類を要し、MRdリクエストが要求できる最大データ量(Maximum Read Request Size, MRRS。典型値512B)によって制約され、返送データはMPSで制約される: $B_{tx} = \lceil sz / \text{MRRS} \rceil \times \text{MRd\_Hdr} + sz \quad (2)$ $B_{rx} = \lceil sz / \text{MPS} \rceil \times \text{CplD\_Hdr} + sz \quad (3)$ ここで `MRd_Hdr` は24B、`CplD_Hdr` は20B。この式によりPCIe Gen 3 x8デバイス(MPS=256B、MRRS=512B、64bitアドレッシング)の実効帯域を計算したものがFigure 1の Effective PCIe BW である。モデルはTLP/DLLのオーバーヘッドを正確に計算する一方、フロー制御メッセージのオーバーヘッドは推定にとどまり、若干過大評価する傾向がある。また非アライメントなDMA読み出しに関するオーバーヘッド(Read Completion Boundary, RCB=典型64Bへのアライメント要求による追加TLP)はモデル化されていない。 モデルは単純なNIC(パケットごとにディスクリプタをDMAし、ドライバがパケットごとにキューポインタを読み書きする)だけでなく、Intel NianticのようなバッチDMA(最大40 TX ディスクリプタをバッチでDMA、最大8ディスクリプタをバッチで書き戻し)を行う最適化NICや、割り込みを使わずホストメモリ上のディスクリプタをポーリングするDPDKドライバの構成もモデル化できる。デバイスドライバやデータシートから入手できる詳細さえあれば任意のPCIeデバイスをプログラム的にモデル化できる。 ### pcie-bench 方法論(§4) pcie-bench は lmbench や hbench:OS の思想を踏まえ、ホストメモリ上のバッファに対してデバイスから個々のPCIe操作を実行し、性能に影響しうるパラメータを慎重に制御するマイクロベンチマーク群である。 **Figure 3: ホストバッファのレイアウトとアクセスパラメータ** ![[_attachments/p327-neugebauer/fig03-host-buffer-layout.png]] (Figure 3. LLC(Last Level Cache)より十分大きい論理的に連続したホストバッファを確保し、キャッシュ効果を測定するためにその一部(ウィンドウサイズ)だけを繰り返しアクセスする。各リクエストはオフセット(offset)から転送サイズ(transfer size)分アクセスし、ユニットサイズ(offset+transfer sizeをキャッシュライン境界に切り上げたもの)ごとにウィンドウを分割することで、各DMAが触れるキャッシュライン数を一定に保つ。アクセスパターンは順次または乱数を選択できる(本論文の大半の実験は乱数アクセス)。Source: Figure 3.) キャッシュ状態は、既定で毎ベンチマーク前にスラッシュしてコールドキャッシュにするか、任意でホストからウィンドウに書き込む(host warm)か、デバイスから書き込みDMAを発行する(device warm)ことでウォームアップできる。ホストバッファのロケーリティ(PCIeデバイスが接続されたノードにローカル配置するか、別ノードにリモート配置するか)もSMPシステムで制御対象になる。 **レイテンシベンチマーク(§4.1)**: PCIe Memory Read(MRd)のレイテンシは、DMA読み出し発行前後のタイムスタンプ差分で直接測定できる(`LAT_RD`)。一方PCIe Memory Write(MWr)はポステッドトランザクションで確認応答を伴わないため、同一アドレスへのDMA書き込みに続けてDMA読み出しを発行し、PCIeの順序保証(Writeの後にReadが処理される)を利用して間接的に測定する(`LAT_WRRD`)。各トランザクションのレイテンシを記録し、平均・中央値・最小・最大・95/99パーセンタイルを算出する。 **帯域ベンチマーク(§4.2)**: 開始・終了のタイムスタンプと転送データ量から帯域を算出する。DMA Read帯域(`BW_RD`)、DMA Write帯域(`BW_WR`)に加え、Read/Writeを交互発行してMRd TLPとMWr TLPをルートコンプレックス帯域を巡って競合させる`BW_RDWR`も測定する。64Bの転送でPCIeリンクを飽和させる場合、各方向で毎秒約6950万トランザクション(ルートコンプレックスが5nsごとに1トランザクションを処理)が発生し、帯域ベンチマークがPCIeルートコンプレックスの実装限界とデバイスのDMAエンジン実装の両方を露呈させる。 ### 実装(§5) pcie-bench 方法論はプログラム可能かつきめ細かなDMAエンジン制御を要するため、商用のNetronome NFPボードと研究向けのNetFPGAボードの2種類で独立実装した。両者は異なるホストアーキテクチャに対する性能測定の相互検証と、2つの異なるPCIe実装への直接的な洞察を提供する。 - **Netronome NFP実装(§5.1)**: NFP-6000/NFP-4000ベースのプログラマブルNIC上で、FPC(Flow Processing Core)のファームウェアとして実装。コマンドインタフェース(小さな読み書きを直接レジスタから発行、128Bまでの転送向け)とバルクDMAインタフェース(大きな転送のディスクリプタをエンキュー)の2系統を利用する。タイムスタンプカウンタは16クロックごとに増加し、1.2GHzのNFPで19.2nsの分解能を持つ。ファームウェアはMicro-C(NFP固有のC拡張)で約1500行、コアは約500行。 - **NetFPGA実装(§5.2)**: NetFPGA-SUME(Xilinx Virtex-7、100Gb/s対応)上にpcie-benchをDMAエンジンに直接統合し、Verilog/System Verilogで約1200行。ホストからのメモリリクエストをFIFOでバッファせず、クロックサイクルごとに新規リクエストを生成できる設計。250MHzのPCIeコアクロックで4nsの分解能を持つ。 - **カーネルドライバ(§5.3)**: NFPは標準NFPカーネルドライバ(約400行の拡張)を用い、最大4MBの物理連続チャンクを確保する。NetFPGAドライバ(約800行)はhugetlbfs(1GBページ、既定)または標準4KBページからメモリを確保し、双方ともNUMAノード指定とキャッシュウォーム制御のインタフェースを提供する。 - **制御プログラム(§5.4)**: NFP側はPython(約1600行)+ Cユーティリティ(約120行)、NetFPGA側はC(約600行)で実装。NFPの完全なテストスイートは約4時間で約2500個の個別テストを実行する。 - **他デバイスへの実装可能性(§5.5)**: Intel Xeon Phi コプロセッサやMellanox Programmable ConnectX-3 Proのような、プログラム可能なDMAエンジンを持つ他のPCIeデバイスにも同程度の労力で実装できるとしている。ループバックモードで非プログラマブルな市販NICの一部の側面を測定することも可能だが、ディスクリプタ転送のオーバーヘッドが常に含まれるため精度は劣る。 ## 新規性 過去の研究(Kalia+ [24]のRDMA、Li+ [32]のDDIOとKVS、Lim+ [34]・Han+ [17]のNUMAとDMA)は、特定のアプリケーション文脈でPCIeの影響の一部に触れているにとどまる。これに対し本論文は、特定アプリケーションに依存しない体系的なPCIe特性評価手法(pcie-bench)を確立し、理論モデルと実測を対応づけることで、アプリケーション性能の背後にあるPCIeの挙動を汎用的に説明可能にした点が新規性である。加えて、商用(Netronome)と研究(NetFPGA)という異なるアーキテクチャの独立2実装によって測定を相互検証している点、複数世代のIntel Xeonサーバを横断してPCIeルートコンプレックス実装の進化を追跡した初の公開データである点も新規性として挙げられる。 ## 実験設定 Table 1に示す6システム構成で評価している。いずれもIntel Xeon E5系(Broadwell・Haswell・Ivy Bridge・Sandy Bridge)を中心に、比較対象としてXeon E3系を1台含む。全システムのPCIe構成はGen 3 x8(現代NICの既定)。 **Table 1: システム構成** | Name | CPU | NUMA | Architecture | Memory | OS/Kernel | Network Adapter | |---|---|---|---|---|---|---| | NFP6000-BDW | Intel Xeon E5-2630v4 2.2GHz | 2-way | Broadwell | 128GB | Ubuntu 3.19.0-69 | NFP6000 1.2GHz | | NetFPGA-HSW | Intel Xeon E5-2637v3 3.5GHz | no | Haswell | 64GB | Ubuntu 3.19.0-43 | NetFPGA-SUME | | NFP6000-HSW | Intel Xeon E5-2637v3 3.5GHz | no | Haswell | 64GB | Ubuntu 3.19.0-43 | NFP6000 1.2GHz | | NFP6000-HSW-E3 | Intel Xeon E3-1226v3 3.3GHz | no | Haswell | 16GB | Ubuntu 4.4.0-31 | NFP6000 1.2GHz | | NFP6000-IB | Intel Xeon E5-2620v2 2.1GHz | 2-way | Ivy Bridge | 32GB | Ubuntu 3.19.0-30 | NFP6000 1.2GHz | | NFP6000-SNB | Intel Xeon E5-2630 2.3GHz | no | Sandy Bridge | 16GB | Ubuntu 3.19.0-30 | NFP6000 1.2GHz | (Table 1. 全システムのLLCは15MBだが、NFP6000-BDWのみ25MB。Source: Table 1.) 各実験は64Bから2048Bまでの転送サイズを2の冪でおおまかに変化させ、キャッシュラインやTLPサイズ境界の前後では±1Bの追加測定も行う。DMA開始アドレスは全てキャッシュラインアラインされ、同一のXeon E5 2637v3システム上で全テストを実施しシステム構成差を排除している。 ## 実験結果 ### ベースライン帯域とレイテンシ(§6.1) **Figure 4: NFP6000-HSWとNetFPGA-HSWのウォームキャッシュ時ベースラインPCIe DMA帯域** ![[_attachments/p327-neugebauer/fig04-baseline-bandwidth.png]] (Figure 4. (a)PCIe読み出し、(b)PCIe書き込み、(c)PCIe読み書き交互のいずれにおいても、NetFPGA実装は本論文のモデル帯域(Model BW)にほぼ追従する。書き込みではNetFPGAがモデルよりわずかに高いスループットを示すが、これはモデルが単方向トラフィックには影響しないフロー制御メッセージの固定オーバーヘッドを仮定しているため。NFP実装はNetFPGAよりわずかに低いスループットとなる(それでも40Gb/sイーサネットレートを満たすには十分)。理由はNFP内部でホスト-SRAM間、SRAM-NFP内部メモリ間という追加のデータ転送段が必要なため。いずれの実装も小さいパケットサイズでは40Gb/sイーサネットのライン速度に必要な読み出しスループットを達成できない。Source: Figure 4.) **Figure 5: NFP-6000とNetFPGAの中央値DMAレイテンシ** ![[_attachments/p327-neugebauer/fig05-median-dma-latency.png]] (Figure 5. 転送サイズを変化させたときの中央値レイテンシ(最小値・95パーセンタイルをエラーバーで表示)。NFP-6000とNetFPGAは同オーダーのレイテンシを示し、大部分のレイテンシが一般的なPCIe・ホストオーバーヘッドに起因することを示唆する。NFP-6000のレイテンシは小さい転送では約100nsの固定オフセットが上乗せされ、転送サイズが増えるほどギャップが拡大する。固定オフセットはDMAディスクリプタのエンキューオーバーヘッド、ギャップ拡大はNFP内部でのホスト-内部SRAM間・SRAM-内部メモリ間の追加転送に起因する。NFPの直接PCIeコマンドインタフェースを使うとNetFPGAと同等のレイテンシを達成でき、大部分がホストシステム側の要因であることを裏付ける。Source: Figure 5.) ### アーキテクチャ間比較(§6.2) Figure 5より、Xeon E5システムの最小値・95パーセンタイルは中央値に近く、レイテンシの分散が小さいことが分かる。 **Figure 6: Xeon E5とE3における64B DMA読み出しのレイテンシ分布(CDF)** ![[_attachments/p327-neugebauer/fig06-latency-distribution-cdf.png]] (Figure 6. NFP6000-HSW(Xeon E5)は99.9%のトランザクションが最小520ns・中央値547nsを起点とする狭い80nsの範囲に収まり、200万トランザクション中の最大レイテンシは947ns。一方、同世代のNFP6000-HSW-E3(Xeon E3)は最小レイテンシこそ493nsと低いが中央値は1213nsと2倍以上に達し、約63パーセンタイルから急激にレイテンシが増加、90パーセンタイルは中央値の2倍、99パーセンタイルは5707ns、99.9パーセンタイル(11987ns)は中央値の一桁上、最大レイテンシは5.8msに達する。Source: Figure 6.) DMA書き込みではXeon E3システムはどの転送サイズでも40Gb/sイーサネットに必要なスループットを達成できない。著者らはIntelがXeon E5系とXeon E3系で全く異なるPCIeルートコンプレックス実装を持つ可能性が高いと推測しつつ、E3の長いレイテンシの規則性は見出せず、隠れた省電力モードとの関連を疑っているが、E3システムでBIOSの省電力モードを無効化しても分布は有意に変化しなかったと報告している(あくまで推測であり未確定)。 ### キャッシュとDDIO(§6.3) **Figure 7: キャッシュがレイテンシと帯域に与える影響(NFP6000-SNB)** ![[_attachments/p327-neugebauer/fig07-cache-effects.png]] (Figure 7. (a)コールドキャッシュのPCIe読み出し(LAT_RD)はウィンドウサイズを変えてもレイテンシが変化せず、全読み出しがメモリから処理されていることを示す。ウォームキャッシュのPCIe読み出しはウィンドウサイズがLLCサイズを超えるまで約70ns低いレイテンシを示す(=LLCから読み出されている)。コールドキャッシュでのPCIe書き込み→読み出し(LAT_WRRD)は、DDIOに割り当てられたLLCの10%を超えるウィンドウサイズになるとダーティキャッシュラインのフラッシュが必要になり、ほとんどの書き込みで約70nsの遅延が生じる。(b)64B DMA読み出し帯域(BW_RD)ではデータがLLCに常駐している方が有意に有利だが、512B以上の読み出しやDMA書き込み(BW_WR)ではキャッシュ常駐の有無による有意差は見られない。DDIOは無効化できず専用性能カウンタも存在しないため、DMA書き込みが常にLLCまたはDDIO領域にヒットしているという仮説は検証不能。Source: Figure 7.) ### NUMAの影響(§6.4) **Figure 8: ローカル/リモートDMA読み出しの帯域差(NFP6000-BDW)** ![[_attachments/p327-neugebauer/fig08-numa-local-remote.png]] (Figure 8. ウォームキャッシュ下で、64B DMA読み出しはローカルメモリに比べリモートメモリで約20%のスループット低下(約32Gb/sから約25Gb/s)を示す。ローカルキャッシュから供給されなくなるとその差は約10%に縮小する。128B・256Bでは5〜7%程度(128Bで約44Gb/sから約41Gb/s)、512B以上では有意差なし。コールドキャッシュのDMA読み出しでは、リモート64B読み出しが常に約10%(128B・256Bでは約5%)のペナルティを受ける。DMA書き込みのスループットはホストバッファのロケーリティにもバッファサイズにも影響されない(Intel仕様とは対照的に、全てのDMA書き込みはローカルDDIOキャッシュで最初に処理されると考えられる)。ローカルの場合と比べレイテンシに大きな差はないが、リモートアクセスは常に約100nsのレイテンシを追加する。2つの2ソケットシステム(NFP6000-BDWとNFP6000-IB)で結果は同一であり、両世代間でのNUMA挙動に大きな変化はない。Source: Figure 8.) ### IOMMUの影響(§6.5) **Figure 9: 異なる転送サイズのDMA読み出しに対するIOMMUの影響(NFP6000-BDW)** ![[_attachments/p327-neugebauer/fig09-iommu-effect.png]] (Figure 9. `intel_iommu=on` かつスーパーページ無効化(`sp_off`、4KBページテーブルエントリを強制)でIOMMUを有効化した際の、IOMMU無効時との比較でのスループット変化率。小さいウィンドウサイズでは転送サイズによらず有意差がないが、ウィンドウサイズが256KBを超えると急激に低下する。64B DMA読み出しは最大約70%、256B DMA読み出しでも約30%低下する一方、512B以上では変化がない。DMA書き込みでも低下は見られるが読み出しほど劇的ではない(64B書き込みで約55%)。この結果からIO-TLBのエントリ数は64(256KB/4KB)と推定される(Intelは公表していない)。64B読み出しのレイテンシは約430nsから760nsに増加し、IO-TLBミスとページテーブルウォークのコストは約330nsと推定される。転送サイズが小さいほどこのペナルティはデータ転送時間に対して相対的に大きく、スループットへの影響も大きくなる。この結果は測定した4世代のIntelマイクロアーキテクチャ全てで驚くほど一貫しており、NetFPGA実装でも同じ効果が観測されたことから、著者らはIntelのIOMMUが初期実装以降ほとんど発展していないと結論づけている。Source: Figure 9.) ## 考察 **Table 2: 本論文で得られた主要な知見(pcie-benchによる実験的導出)** | Area | Observation | Evaluation-directed recommendation | |---|---|---| | IOMMU(§6.5) | ワーキングセットサイズの増加に伴いスループットが顕著に低下する | I/Oバッファをスーパーページに配置する | | DDIO(§6.3) | データがキャッシュに常駐している場合、小さいトランザクションが高速化する | DDIOはディスクリプタリングへのアクセスと小パケット受信性能を改善する | | NUMA(§6.4、小トランザクション) | ローカルキャッシュに比べリモートメモリからのDMA読み出しはコストが高い | ディスクリプタリングをローカルノードに配置する | | NUMA(§6.4、大トランザクション) | リモート/ローカルのキャッシュ性能に有意差はない | 処理が行われるノードにパケットバッファを配置する | (Table 2. Source: Table 2.) IOMMUのデータに基づき、著者らはスーパーページの使用と、DMAに使うI/Oバッファをできるだけ少数のスーパーページに集約することを強く推奨する。ただしマルチテナントVM環境でPCIeデバイスをアサインする場合、現状のIntel IOMMUではVM間のIO性能分離を十分に行えないと指摘する。NUMAについては、小さいDMA読み出しはリモートキャッシュからの読み出しが有意に高コスト(+約100nsのレイテンシ)である一方、大きいパケットサイズではバッファのロケーリティは重要でなく、処理が行われるノードにデータを配置すべきとする。DDIOについては小転送でキャッシュ常駐データへのアクセスが約70ns高速であることを確認し、ディスクリプタリングアクセスの低レイテンシ化と、キャッシュライン境界に一致しないパケットサイズ(例: FCS除去後64Bイーサネットフレーム)の小パケット受信性能向上に有用としている。 これらの知見は、Netronomeボードのレイテンシ理解が複数のファームウェア実装の設計(オフロード種別の選択)に大きく影響したこと、レイテンシデータがインフライトDMA数・I/O構造体(リング等)のサイズ・Flow Processing Coreとスレッド数の決定に直結すること、NFP6000-HSWで128Bデータ転送に560〜666ns要する例から40Gb/sライン速度には少なくとも30個の同時トランザクションが必要になる計算など、firmware/DMAエンジン設計に直接応用されたと報告する。IOMMU有効時はさらに約330nsのTLBミスによるレイテンシ増を見込む必要がある。pcie-benchの方法論はNetFPGAのDMAエンジン設計の反復評価や、Netronomeにおけるチップ立ち上げ時のバリデーション・将来シリコンのアーキテクチャ決定にも実際に使われたとしている。 ## 強み / 弱点・課題 **Strengths**: - 理論モデルとマイクロベンチマークの両輪で、PCIe自体のプロトコルオーバーヘッドとホスト側実装(NUMA・DDIO・IOMMU)の影響を分離して定量化できる方法論を確立した。 - 商用(Netronome)と研究向け(NetFPGA)の独立2実装により、測定結果をアーキテクチャ横断で相互検証している。 - pcie-benchをオープンソース化し(https://www.pcie-bench.org)、再現性と他アーキテクチャへの適用可能性を担保している。 - 複数世代のIntel Xeonサーバにまたがる公開データが希少であり、同一世代内でもXeon E5とE3で全く異なる挙動(レイテンシ分布・分散)を示すという驚くべき知見を提示した。 **Weaknesses/Limitations**（論文が明示的に述べる限界と、そこから読み取れる課題）: - モデルはフロー制御メッセージのオーバーヘッドを推定にとどめており実際よりやや過大評価する。また非アライメントDMA読み出しのオーバーヘッド(RCB由来の追加TLP)はモデル化されていない。 - 評価はIntel Xeon E5(および一部E3)アーキテクチャに集中しており、AMD・ARM64・Powerベースのサーバは今後の課題として明示的に残されている。 - 単一サーバ内に複数の高性能PCIeデバイスを搭載する構成(データセンターで一般的)の影響は未評価であり、IOMMUのIO-TLBエントリがデバイス間で共有されるかなど、さらなるボトルネックが未解明のまま残る。 - Xeon E3システムで観測された大きなレイテンシ分散の原因は特定に至らず、「隠れた省電力モードに関連する可能性がある」という推測にとどまっている(BIOS設定変更でも改善せず未解決)。