I/O ÃÌ µw IoT = îqb ¹ÑÄ¢£ ExpEther w

情報処理学会研究報告IPSJ SIG Technical Report

I/OデバイスのIoT化を実現するソフトウェアExpEtherの提案

鈴木順1,a) 辻聡1,†1,b) 林佑樹1,c) 竹中崇1,†2,d)

概要：IoT(Internet of Things)では，IoTデバイスをネットワークに接続したホストから制御する機会が

多い．各 IoT デバイスは制御ホストと通信を行うため，CPU，メモリ，I/O デバイスを備える小型コン

ピュータと合わせて実装される．小型コンピュータはソフトウェアネットワークスタックを用いて制御ホ

ストと通信する．本稿では，IoTデバイスが小型コンピュータではなく I/Oデバイスだけと実装されるこ

れまでより細粒度の IoTを議論する．I/Oデバイスは遠隔制御ホストのローカルデバイスとして仮想化さ

れ，IoT デバイスは I/O デバイスを介したデータ通信によって制御される．このような IoT システムに

より IoTデバイスノードの構成が単純化され，実装コストの低減が実現される．しかし，従来手法では制

御ホストと IoTデバイスと合わせて実装される遠隔 I/Oデバイスの接続に特殊なハードウェアインター

フェースが必要だった．そこで本稿では制御ホストとネットワークに分散された I/O デバイスを接続す

る新しいソフトウェア仮想化手法，ソフトウェア ExpEtherを提案する．提案手法により，制御ホストの

NIC(Network Interface Card)を介してのみ通信できる遠隔の I/Oデバイスが，ホストの I/Oデバイスツ

リーに属するローカル I/Oデバイスとして仮想化される．これにより，携帯型からラックマウント型に及

ぶあらゆるコンピュータが提案ソフトウェアのインストールにより遠隔の IoTデバイスを制御できる．ま

た仮想化は PCI Express(PCIe)層で行うため，提案手法は PCIeに準拠する I/Oデバイスをデバイスドラ

イバの改造なく遠隔ホストに接続できる．本稿では提案手法のソフトウェア ExpEtherを実装し，NIC及

びストレージコントローラに対し評価を行うことでその実現性を実証する．

IoT of I/O Devices with Software ExpEther

Suzuki Jun1,a) Tsuji Satoshi1,†1,b) Hayashi Yuki1,c) Takenaka Takashi1,†2,d)

1. はじめに

IoT(Internet of Things)の普及によりセンサ，乗り物，

生産機械等の多くのデバイスがネットワークに接続され

るようになった．通常，これらの IoT デバイスは遠隔の

制御ホストから制御される．図 1(a)に示すように，個々

の IoT デバイスは制御ホストと通信を行うために小型の

コンピュータと合わせて実装される．小型のコンピュータ

1 NEC システムプラットフォーム研究所神奈川県川崎市中原区下沼部 1753

†1 現在，NEC IoT デバイス研究所†2 現在，NEC サービス・テクノロジー本部a) [email protected]) [email protected]) [email protected]) [email protected]

は CPU，メモリ，I/Oデバイスを含む．そして，OSやア

プリケーションを動作させ，ソフトウェアネットワークス

タックを用いて制御ホストと通信する．

本稿では，図 1(b)に示すように，IoTデバイスが小型

コンピュータではなく I/Oデバイスだけと実装されるよ

り細粒度の IoTを議論する．I/Oデバイスは遠隔の制御ホ

ストのローカルデバイスとして仮想化され，IoTデバイス

は I/Oデバイスを介した制御ホストとのデータ通信によっ

て制御される．このような IoTシステムの実現を本稿では

I/Oデバイスの IoT化と呼ぶ．IoT化される I/Oデバイス

の例は USB(universal-serial-bus)コントローラ，ストレー

ジコントローラ，シリアルインターフェースである．また

IoT化された I/Oデバイスに制御される IoTデバイスの

ⓒ 2017 Information Processing Society of Japan 1

Vol.2017-OS-140 No.62017/5/16


図 1 ネットワークに接続した IoT デバイスの構成．(a) 小型コン

ピュータと合わせて実装された IoTデバイス．(b)I/Oデバイ

スのみと実装された IoT デバイス．

例は，USBやシリアルインターフェースからのコマンド

で制御されるセンサやアクチュエータである．これにより

IoTデバイスに個別に小型コンピュータを実装する場合と

比較して単純でコストが低減された IoTシステムを実現で

きる．また，小型コンピュータのソフトウェアアップデー

トやセキュリティ問題も解消される．

従来，I/Oデバイスのネットワークを構築するには，特

殊なハードウェアブリッジを用いていた [1], [2]．これらの

ブリッジは制御ホストと I/Oデバイスをネットワークに接

続するために用いられる．そして通常のコンピュータの内

部の I/Oバスで送受信される I/Oパケットを，制御ホス

トと I/Oデバイスを接続するネットワーク上でトンネリン

グする．しかし，これらの技術の普及は特殊なハードウェ

アインターフェースを必要とするため制限があった．制御

ホストにはブリッジチップを実装した NICを I/Oスロッ

トに挿入するか，ホストのマザーボードにブリッジチップ

を実装する必要があった．この要件は実装コストを増加

させるだけでなく，I/Oスロットの予備がない小型のコン

ピュータや，既にサービスに導入されているホストへの適

用の障害になっていた．

本稿ではイーサネットで接続された I/Oデバイスと遠

隔ホストを接続するための新しいソフトウェア仮想化技術

を提案する．提案手法をソフトウェア ExpEtherと呼ぶ．

ソフトウェア ExpEtherは導入の容易さとあらゆる I/Oデ

バイスへの広い適用性を同時に実現する．導入容易とは制

御ホストに従来の特殊なハードウェアを必要としないとい

うことである．一方 I/Oデバイスのイーサネットへの接

続には我々が [1]で提案している従来手法のハードウェア

ブリッジを用いる．ソフトウェア ExpEtherをホストにイ

ンストールすることにより，携帯からラックマウント型に

及ぶあらゆるホストが遠隔の I/Oデバイスを制御できる．

また広い適用性はソフトウェア ExpEtherがホストと遠隔

I/Oデバイスを PCIeレイヤで接続することにより実現す

る．これにより PCIeに準拠するデバイスであればデバイ

スドライバを変更することなくイーサネットで接続可能に

なる．

ソフトウェアExpEtherは，イーサネットで接続した遠隔

の I/Oデバイスをホストの I/Oデバイスツリーに属するよ

うに仮想化する．ホストと遠隔 I/Oデバイスはホストの標

準 NICを介してのみ通信できる．ソフトウェア ExpEther

は接続したホストと遠隔 I/Oデバイスの間で PCIeトラン

ザクションをソフトウェアで実現する．提案手法の実装は

仮想マシン (VM)のパススルーモードを拡張することによ

り行った．パススルーモードでは PCIeレイヤにおいてホ

ストの I/OデバイスをVMに割り当てる仮想化機能が実現

されており，拡張して提案手法を実装することが容易だっ

た．ソフトウェア ExpEther は遠隔 I/O デバイスのコン

フィグレーション，アドレス領域の割り当て，I/Oパケッ

トの作成とイーサネットフレームへのカプセル化、VMと

遠隔 I/Oデバイスのアドレス空間のマッピング等の機能を

提供する．またこれらの主要な機能はホスト OSのアプリ

ケーションソフトウェアとして実装される．

本稿ではソフトウェア ExpEtherを実装しNICおよびス

トレージコントローラに対し評価を行うことで実現性を実

証する．また性能オーバヘッドに対する考察を行う．

以下本稿では 2節で遠隔 I/Oデバイスの仮想化技術への

要求，3節でソフトウェア ExpEtherのアーキテクチャ，4

節で VMへの実装，5節でプロトタイプを用いた評価結果

を述べ，最後に 6節でまとめる．

2. システム要求

本節では遠隔 I/Oデバイスの仮想化技術に対するシステ

ム要求を議論する．イーサネットで接続された I/Oデバイ

スはホストの I/Oデバイスツリーに属するように仮想化

される．本節で議論する要求は次節以降で提案するソフト

ウェア ExpEtherのアーキテクチャに反映されている．

導入容易性: I/Oデバイスの IoT化のために特殊なハード

ウェアインターフェースが必要であれば，システム導入の

障壁となる．従って新たな仮想化技術はソフトウェアで実

現されることが望ましい．特殊なハードウェアは導入コス

トを増加させるだけでなく，実装空間が制限された組込み

コンピュータでも課題となる．さらに既にサービスで稼働

しているシステムに特殊なハードウェアを導入することも

困難である．

スケーラビリティ: I/Oデバイスが IoT化されるシステム

では制御ホストに多数の遠隔 I/Oデバイスが割り当てられ

る．例えば工場において数百の生産機械やセンサを制御す

ることが想定される．従って新たな仮想化技術は接続する

I/Oデバイス数に関してスケーラビリティを提供する必要

がある．またホストと I/Oデバイスを接続するネットワー

クには複数のホストと I/Oデバイスの組が同時に接続でき

ることが望まれる．

システム再構成: ネットワークに分散した I/Oデバイスの

制御ホストへの割り当ては変更できることが望ましい．こ


Vol.2017-OS-140 No.62017/5/16


図 2 ソフトウェア ExpEtherを含むシステム全体のアーキテクチャ

れらの変更はシステム管理者からの要求により直ちに，ま

た容易に行われるべきである．また，制御ホストのリブー

トを伴わずに行われるべきである．

互換性: 新たな仮想化技術は現在用いられているシステム

との互換性を保持することが望ましい．理想は現在のハー

ドウェアとソフトウェアを変更することなく導入できるこ

とである．従って，新たな仮想化技術では関連する部位へ

の変更を最小限に留めるべきである．今回の手法で関連す

る部位はホストと I/Oデバイスを接続するネットワークス

イッチ，ネットワークを用いて接続する I/Oデバイスとそ

のドライバ，ホストのOSである．またそれに加え，様々な

I/Oデバイスに同一の手法で対応できることが望ましい．

性能: 一般にハードウェア資源を仮想化する場合，仮想化

オーバヘッドが不可避である．今回仮想化する資源は遠隔

I/Oデバイスである．そこで遠隔 I/Oデバイスの性能に関

してデバイスをホストの I/Oスロットに直接設置する場

合と近い性能を実現することが望ましい．また仮想化に必

要な CPUの負荷を低減することで，ホストの他のアプリ

ケーションに影響を与えないことが重要である．

3. ソフトウェアExpEtherのアーキテクチャ

3.1 概要

図 2 にソフトウェア ExpEther を含むシステム全体の

アーキテクチャを示す．ホストと遠隔 I/Oデバイスはイー

サネットにより接続される．イーサネットにはホストへの

I/Oデバイスの割り当てを管理するシステムマネージャも

接続する．ホストに割り当てられた I/Oデバイスはホスト

の I/Oデバイスツリーに属するように仮想化される．ホ

ストは割り当てられた I/Oデバイスを従来の I/Oスロッ

トに挿入された I/Oデバイスと同様に使用できる．ホス

トと I/Oデバイスの間では PCIeの I/Oパケット (TLP:

Transaction Layer Packet)がイーサネットにカプセル化さ

れ，トンネリングにより伝送される．

ソフトウェア ExpEther はシステムソフトウェアに位

置付けられる．アクセス検出，DMA(Direct Memory Ac-

cess)，TLP作成とカプセル化，高信頼低遅延通信，アド

レスマップ，デバイス管理の機能を有する．アクセス検出

機能はホストが遠隔 I/Oデバイスに行ったアクセスを検出

し，その内容を抽出する．DMA機能は遠隔の I/Oデバイ

スから要求された DMAを行う．TLP作成とカプセル化

機能は抽出した I/Oデバイスへのアクセス情報を用いて

TLPを作成し，イーサネットフレームにカプセル化する．

高信頼低遅延通信機能はホストと遠隔 I/Oデバイスとの間

の通信機能を提供する．アドレスマップ機能は遠隔 I/Oデ

バイスに割り当てらるアドレス空間を管理し，TLP作成機

能にアドレス変換テーブルを提供する．デバイス管理機能

は割り当てられた遠隔 I/Oデバイスのコンフィグレーショ

ンを行う．

一方遠隔 I/Oデバイスは著者らが [1]で提案したハード

ウェアの ExpEtherブリッジを用いてイーサネットに接続

する．ExpEther ブリッジは TLP のカプセル化，デカプ

セル化を行う．CPUやメモリを保持せず，接続されたホ

ストには PCI-PCIブリッジとして認識される．ExpEther

ブリッジはイーサネット及び PCIeインターフェースを保

持する FPGA(Field-Programmable Gate Array)，または

ASIC(Application Specific Integrated Circuit)として実装

することができる．ブリッジチップは遠隔 I/Oデバイスを

収容する I/O資源ボックスのマザーボードに実装される．

これにより I/O資源ボックスはハードウェア ExpEtherブ

リッジと I/Oデバイスだけの単純な構成となる．

システムマネージャはイーサネットに接続したホストと

I/Oデバイスの管理を行う．それらの障害を検出し，シス

テムマネージャのユーザインターフェースに表示する．ま

た，I/Oデバイスのホストへの割り当てもシステムマネー

ジャのコマンドを用いて変更する．システムマネージャが

行った変更はソフトウェア ExpEtherブリッジで検出され，

割り当てられた I/Oデバイスが更新される．

ホストへの I/O デバイスの割り当てには MAC(Media

Access Control)アドレスをキーに用いる．ソフトウェア

ExpEtherは割り当てられた I/Oデバイスが接続するハー

ドウェア ExpEtherブリッジの MACアドレスを記憶し，

記憶したアドレスを用いて TLPを作成する．

これらのアーキテクチャは 2節で述べたシステム要求を

満たすものである．ソフトウェア ExpEtherはホスト側に

イーサネット上の I/Oデバイスに接続するための特殊は

ハードウェアブリッジを必要とせず，技術の導入障壁を解

消する．また 1つのホストに接続可能な I/Oデバイスは

32Kまでスケールする．これはデバイスに用いる ID番号

の bit長の制限である．ホストへの I/Oデバイスの割り当

ても再構成可能である．また遠隔 I/Oデバイスとの接続が

PCIeレイヤで仮想化されるため，PCIeに準拠するあらゆ

る I/Oデバイスが接続可能である．さらにソフトウェア


Vol.2017-OS-140 No.62017/5/16


ExpEtherは I/Oデバイス，デバイスドライバ，ドライバ

を動作させる OS，イーサネットスイッチへの変更を必要

としない．高信頼低遅延通信機能はイーサネットにおける

輻輳を抑制し TLPを低遅延で伝送する．これにより遠隔

I/Oデバイスの仮想化オーバヘッドを抑制する．

3.2 遠隔 I/Oデバイスの仮想化

本節ではイーサネットで接続され，ホストの I/Oデバイ

スの NIC(Network Interface Card)を介してのみ通信可能

な遠隔 I/Oデバイスをローカルデバイスとして仮想化する

アーキテクチャについて述べる．ソフトウェア ExpEther

はソフトウェアの仮想化レイヤで PCIeアクセスを提供す

ることにより本機能を実現する．

ホストが起動されると，デバイス管理機能は遠隔 I/Oデ

バイスのアドレスを予約する．予約されるアドレスはPCIe

で使用するアドレス空間，I/Oポート空間，バス/デバイ

ス/ファンクション (BDF)番号の組である．そしてアクセ

ス検出機能が予約したアドレスに対応する遠隔 I/Oデバイ

スに発行されたアクセスを検出する．TLP作成とカプセ

ル化機能は検出した I/Oデバイスへのアクセスからアクセ

ス内容を抽出し，TLPを作成する．ここで TLPのあて先

アドレスはホストが指定した値から遠隔 I/Oデバイスに予

約されたアドレスに変換される．アドレス変換は次節で述

べるソフトウェア ExpEtherの Linux KVM(Kernel-based

Virtual Machine)への実装に必要となる．VM内にカプセ

ル化されたホストのアドレス空間と，ホスト OS上で動作

するソフトウェア ExpEtherが管理するアドレス空間が異

なるからである．TLP作成のためのアドレス変換テーブ

ルはアドレスマップ機能により提供される．また I/Oデバ

イスから受信する TLPは，DMA以外は TLPの内容を抽

出しホストに渡す．一方 TLPがDMAの場合，DMA機能

がホストのあて先アドレスに DMAを実行する．ここでも

DMAのあて先アドレスはアドレス変換が行われる．

3.3 高信頼低遅延通信

PCIe標準は TLPが通信途中で欠落しないことを想定し

ている．それに加え，ホストと遠隔 I/Oデバイスの通信遅

延は I/Oデバイスの性能に大きく影響する．通常の PCIe

I/Oバスではこれらの要求を I/Oバス毎の Ackと，クレ

ジットによる帯域制御で実現している．一方ソフトウェ

ア ExpEtherでは，到達 Ackはソフトウェア ExpEtherと

ハードウェア ExpEther ブリッジの間でイーサネットの

エンド間で送信する．通信で欠落した TLPは Go-Back-N

ARQ(Automatic Repeat-Request)により再送される．ま

た遅延は，ソフトウェア ExpEtherが遅延に基づく輻輳制

御を採用し,TCPのようなパケットロスに基づく制御より

低遅延の通信機能を提供する．採用した輻輳制御アルゴリ

ズムの詳細は [3]で提案している．

図 3 PEB レイヤの実装．

図 4 遠隔 I/O デバイスに割り当てられた仮想アドレス資源．I/O

ポートアドレスの図示は省略．

4. 実装

ソフトウェア ExpEther の実装は KVM のパススルー

モードを拡張して行った．パススルーモードは PCIeレイ

ヤでホストの I/Oデバイスを VMに割り当てる仮想化機

能が実現されており，提案手法の実装に適していた．ソ

フトウェア ExpEther 機能の大部分はホスト OS のアプ

リケーションプログラムとして実装したが，VM による

遠隔 I/O デバイスへのアクセスの検出のために QEMU-

KVM(Quick Emulator KVM)の一部は改造した．ソフト

ウェア ExpEtherは PCIe-to-Ethernetブリッジ (PEB)レ

イヤ及びイーサネット転送レイヤから構成される．前者は

3節で述べた高信頼低遅延通信以外の機能を提供し，後者

は高信頼低遅延通信機能を提供する．それぞれのレイヤの

機能について以下に述べる．またイーサネットで接続され

た遠隔 I/Oデバイスはホスト上のいずれかの一つの VM

に割り当てられ，同時に複数の VMから共有されない前提

とした．

4.1 PCIe-to-Ethernetブリッジ (PEB)レイヤ

図 3 に PEB レイヤの構成を示す．ソフトウェア Ex-

pEther初期化部は遠隔デバイスのコンフィグレーションを

行うため，デバイス構成部を呼び出す．ホストに割り当て

られた全ての I/OデバイスはVMに割り当てられる前にコ

ンフィグレーションが行われる．コンフィグレーションは


Vol.2017-OS-140 No.62017/5/16


PCIeの手順に準拠して行われ，メモリマップアドレス，I/O

ポートアドレス，BDF番号が割り当てられる．以下ではソ

フトウェア ExpEtherにより割り当てられた BDF番号を

VBDF番号と呼ぶ．同一ホストに割り当てられた I/Oデバ

イスに割り振られるアドレス空間と VBDF番号はユニー

クな値である．従来のコンピュータでは I/Oデバイスに

対するコンフィグレーションはBIOS(Basic Input/Output

System)が行っている．

図 3に示す PEBレイヤの左側は TLP作成及びカプセル

化を行う．改造した QEMU-KVMが VMの遠隔 I/Oデバ

イスへのアクセスを検出し，アクセス情報を抽出しソケッ

ト通信により要求アービトレーション部に送る．TLP作成

部はその情報を用いてTLPを作成する．一方，逆方向のト

ラフィックでは，イーサネットからイーサネット転送レイ

ヤを介して受信した TLPをデカプセル化し，TLPが保持

する情報を抽出する．続いてそれらの情報をQEMU-KVM

を介して I/Oデバイスが割り当てられた VMに渡す．こ

こで VMへの要求が DMAだった場合，QEMU-KVMが

VMがマップされた DMAのあて先メモリに対し指定され

た DMAを行う．

制御フレーム処理部は制御フレームを用いて割り当てら

れた遠隔 I/Oデバイスとのコネクション管理を行う．また

システムマネージャに状態監視のための状態通知も行う．

次に TLPの作成及び受信 TLPの情報抽出を行う際に

用いるアドレステーブルの構成と，それらが保持するデー

タの使用方法について述べる．アドレステーブルはメモ

リマップテーブルと BDF MACテーブルから成る．メモ

リマップテーブルは遠隔 I/Oデバイスがマップされたメ

モリ及び I/Oポート空間の情報を保持する．メモリマッ

プテーブルは VBDF番号をサーチキーとして検索を行う

構成となっている．BDF MACテーブルは VBDF番号と

I/Oデバイスが接続するハードウェア ExpEtherブリッジ

のMACアドレスの対応を保持する．

ソフトウェア ExpEtherが起動されたとき，ホストに割

り当てられた I/Oデバイスを探索し，それらにアドレス空

間とVBDF番号を割り当てる．このとき割り当てるアドレ

ス空間と VBDF番号は，図 4に示すように，ホストOSが

ローカル I/Oデバイスに用いているアドレス空間や BDF

番号と干渉しないようにする．VMによる遠隔 I/Oデバ

イスへのアクセス検出では，QEMU-KVMのパススルー

モードを再利用することが望ましい．そこでソフトウェア

ExpEtherでは，ホスト OSのデバイスエントリであるデ

バイスファイルを作成する．そして VMを起動する際に割

り当てられた I/Oデバイスのエントリを QEMU-KVMに

通知する．これにより QEMU-KVMは遠隔 I/Oデバイス

に割り当てられたアドレス空間とVBDFを識別し，パスス

ルーモードに関するコードが改造された箇所で VMによる

遠隔 I/Oデバイスへのアクセスを抽出することができる．

図 5 イーサネット転送レイヤの実装．

QEMU-KVMが遠隔 I/Oデバイスへのアクセスを検出

すると，遠隔 I/Oデバイスに割り当てられた VBDF番号

が探索され，その番号が PEBレイヤに通知される．遠隔

I/Oデバイスへのアクセスが VBDFでルーティングされ

る場合，TLP作成部はその値を用いて TLPを作成する．

一方ルーティングがメモリや I/Oポートアドレスで行われ

る場合，VBDFを探索キーとしてメモリマップテーブルの

エントリを探索する．作成する TLPのあて先アドレスは，

QEMU-KVMから通知されたオフセット値を，メモリマッ

プテーブルが保持する遠隔 I/Oデバイスがマップされたメ

モリや I/Oポート空間のベースアドレスに加算することに

より求められる．

また逆方向のトラフィックでは，遠隔 I/Oデバイスから

受信した TLPが VBDF番号でルーティングされていた場

合，TLPはDMA命令ではない．このとき，QEMU-KVM

によりあて先のVMが TLPに記載されたVBDFから探索

され，VMに受信したデータが渡される．一方 TLPがメ

モリアドレスでルーティングされていた場合，トラフィッ

クはあて先 VMのメモリ空間に対する DMAである．こ

のとき受信した TLPに記載されたアドレス値は，VM内

のデバイスドライバによる I/Oコマンドから指定された値

であり，VM内のアドレス空間における物理アドレスであ

る．ここで QEMU-KVMは内部の VMの物理アドレスと

アプリケーションプログラムとしての VMの論理アドレス

のマッピング情報を保持している．QEMU-KVMはこの

情報を用いて VMの物理アドレスを VMの論理アドレス

に変換する．これにより QEMU-KVMは遠隔 I/Oデバイ

スから指定された VMのメモリにアクセスし，DMAを行

う．データ読み込みの DMAでは，読み込んだデータを含

む応答 TLPを作成し遠隔 I/Oデバイスに返送する．

4.2 イーサネット転送レイヤ

イーサネット転送レイヤはTLPをカプセル化したイーサ

ネットフレームに対し高信頼低遅延通信を提供する．イー

サネット転送レイヤの構成を図 5に示す．PEBレイヤが送


Vol.2017-OS-140 No.62017/5/16


表 1 実装及び評価に用いたプラットフォーム．CPU Intel(R) Xeon(R) CPU E3-1225 V2 (4 core)

Host Memory 16 GB

OS CentOS 7

CPU QEMU Virtual CPU Version 1.5.3 (1 core)

Guest Memory 2 GB

OS CentOS 7

Test I/O NIC Intel 82579LM Gigabit Network Connection

Device SATA Silicon Image, SiI 3132 SATA Raid II Cont.

信したイーサネットフレームは再送バッファ部に記憶され

る．それらのフレームは送信スケジューラ部により送信タ

イミングのスケジューリングが行われる．一方遠隔 I/Oデ

バイスから受信したフレームはイーサネットフレームアー

ビトレーション部から PEBレイヤに渡される．

再送バッファで送信待ちのイーサネットフレームは，あ

て先MACアドレス毎のキューに記憶される．それぞれの

キューからの送信は，トークンバケットを用いたラウンド

ロビンスケジューリングにより制御される．トークンを加

算するレートはレート計算部によりそれぞれのキュー毎の

値が計算される．トークンバケットを採用する理由は I/O

デバイスのトラフィックが 256 バイト程度の短パケット

で，かつトラフィックがバースト的だからである．

レート計算部はホストと I/Oデバイスの接続毎に送信

レートを決定する．送信レート計算のアルゴリズムは [3]

で提案している．我々が提案した手法は短いバーストフ

レームが低遅延で伝送されるものである．またイーサネッ

トのエンド間で送信遅延に基づく送信レート制御を採用し

ており，イーサネット内の輻輳を抑制し低遅延通信が実現

できる．送信レート計算に用いるレート方程式は

RNEXT = R+ (α− (RTT −RTTMIN )R)β

RTT, (1)

で示される．ここで R は送信レート, RTT はイーサネッ

トの Round-Trip Time, RTTMIN は RTTの最小値, αと

β は調整パラメータである．送信端で観測される RTT が

増大すると，送信レートを抑制することでイーサネット内

の輻輳を抑制し，RTTが最小値に近づくようにフィード

バックを行う．

イーサネット転送レイヤはまた，高信頼通信を実現するた

めにハードウェア ExpEtherブリッジとの間でGo-Back-N

ARQを行う．イーサネットフレームアービトレーション

部が Ackフレームを受信した場合，再送バッファに記憶さ

れたフレームから到達が確認されたフレームを解放する．

一方定められた時間内に Ackフレームを受信しない場合，

再送バッファのリードポインタを未到達の最初のフレーム

に戻す．また，逆方向の受信フレームに関しては，Ack生

成部が複数の受信フレームに対しまとめて 1つの Ackフ

レームを作成し送信ノードに返信する．

5. 評価結果

ソフトウェア ExpEtherを実装し評価を行った．本節で

図 6 評価構成.

は評価結果とその考察について述べる．

表 1 に実装と評価に用いたプラットフォームを示す．

KVMは CentOS 7で配布されるものを用いた．評価に用

いた遠隔 I/OデバイスはNIC及び SATA(Serial Advanced

Technology Attachment)コントローラである．これらは

一般的に用いられる I/Oデバイスであり，これらのデバ

イスを用いることで提案手法が様々な I/Oデバイスに適

用可能であることを示す．両 I/O デバイスは PCIe イン

ターフェースを保持していた．NICの帯域は 1Gb/sだっ

た．SATAコントローラはインテルX25-E Extreme SATA

SSD(Solid State Drive) に接続した．VM 内の OS，デバ

イスドライバ，遠隔 I/Oデバイスはコモディティ製品であ

り，提案手法のための改造は行っていない．

図 6に評価に用いた 3つの構成を示す．(a)ではホスト

と遠隔 I/OデバイスであるNICがソフトウェア ExpEther

により接続される．(b)ではホストと NICがハードウェア

の PCIe-over-Ethernetブリッジ (ハードウェア ExpEther

ブリッジ)で接続される．この場合ブリッジチップを実装

したネットワークインタフェースがホストの I/Oスロット

に挿入される．(c)では NICが直接ホストの I/Oスロット

に挿入される．(b)及び (c)では NICがホスト内の VMに

パススルーデバイスとして割り当てられる．(c)は性能評

価におけるベースラインである．なお，SATAコントロー

ラを用いた評価では図 6に示した遠隔 NICが SATAコン

トローラに置き換えられる．今回，評価機材の制約で対向

試験ホストの NICの帯域が 100Mb/sだった．

図 7にソフトウェア ExpEtherで接続した遠隔 NICを

介して評価した VM の Ping 遅延を示す．ソフトウェア

ExpEther の遅延はベースラインのローカルデバイスの

NICの 4.4倍だった．またハードウェアブリッジとベース

ラインの遅延は同等だった．これらの結果は，現在の実装

のボトルネックがホストと I/Oデバイス間の通信遅延では

なく，ソフトウェア ExpEtherの低速なソフトウェア処理

であることを示している．


Vol.2017-OS-140 No.62017/5/16


図 7 Ping 遅延.

表 2 処理時間の解析.

Process Time [ms]

Request Arbitration (Downstream) 0.033

Request Arbitration (Upstream) 0.035

TLP Construction and Encapsulation 0.002

TLP Decapsulation and Destruction 0.014

Transmission Scheduler 0.003

Frame Transmission 0.024

Inter-thread Communication 0.034

そこでソフトウェア処理のオーバヘッドをさらに解析す

るため，ソフトウェア ExpEther内の個別機能の処理時間

を解析した．表 2 に結果をまとめる．それぞれのプロセ

スは図 3及び 5に記載した名前に対応する．Upstreamは

I/Oデバイスからホスト方向に送信されるTLPのフローで

あり，Downstreamはその逆である．最終行のスレッド間

通信は，ソフトウェア ExpEtherを構成する複数のスレッ

ド間で行うメッセージ通信の時間である．ここで図 7 に遅

延を示した 1つの Pingでは，ホストと遠隔 NICの間で 10

往復程度の PCIeトランザクションが発生する．そこで表

2 で得られた遅延を 1 Pingコマンド分積算すると，図 7の

遅延を説明できることを確認した．この結果はソフトウェ

ア ExpEtherの仮想化オーバヘッドの大部分が，低速なソ

フトウェア処理に起因するという仮説を裏付けるものであ

る．表 2は数 10µ秒を要する機能が複数あることを示して

いる．

現在のソフトウェア ExpEtherの初期実装では，内部の

複数スレッド間のデータ通信にメッセージ通信を用いて

いる．一般にメッセージ通信を行うためには 20µ秒程度

が必要であり，表 2 のスレッド間通信が数 10µ秒に達す

る原因と考えられる．またその他の処理も複数スレッド構

成を前提としており，非効率な実装となっている可能性が

ある．これらの性能はソフトウェア ExpEtherの実装構成

を改善することで改善が期待される．それに加えパケッ

トの授受にポーリングを用いる場合，DPDK(Data Plane

Development Kit)[4]のような方法も全体性能の向上に役

立つ可能性がある．これらの性能改善は今後の課題である．

図 8にソフトウェア ExpEtherで接続したNICのスルー

プットを示す．送信結果は VMが試験ホストにパケット

図 8 iperf で測定した NIC のスループット.

図 9 fio で測定した SSD のスループット.

を送信する場合であり，受信結果は VMが試験ホストから

パケットを受信する場合である．評価には iperfを用いた．

現在のソフトウェア ExpEtherの実装オーバヘッドにより，

ベースラインより平均で 69% スループットが低下した．

図 9は SATAコントローラと接続した SSDのスループッ

トの評価結果である．評価には fioを用いた．ベンチマー

クにおける I/O アクセスサイズは 1MBに設定し，アクセ

スタイプはランダムリード/ライトとした．ここでもソフ

トウェア ExpEtherのスループットはベースラインと比較

し 90% 低下した．

以上の評価結果が示すように，現在の初期実装ではソフ

トウェア ExpEtherのソフトウェア処理の実装を改善する

ことで，性能を向上できる見込みが大きい．しかし，今回

得られた結果により本稿では新しい仮想化手法の実現性を

示した．また提案手法が一般的な PCIeデバイスに適用可

能であることを示した．評価に用いた NIC及び SATAコ

ントローラは，無改造のコモディティ製品である．

6. 関連技術

従来の I/Oデバイスのネットワークは I/Oデバイスが

割り当てられるホストに特殊なハードウェアブリッジが

必要だった．我々も [1], [5]で I/Oデバイスの接続に有線，

または無線イーサネットを使用する手法を提案した．Intel

は Thunderboltと呼ぶ独自規格のネットワークを商用化し

ている [2]．Krishnanも I/Oデバイスネットワークを実現

する別の技術を提案した [6]．ソフトウェア ExpEtherでは

I/Oデバイスをイーサネットに接続するためにハードウェ

アブリッジを用いるが，ホストには特殊なハードウェアを


Vol.2017-OS-140 No.62017/5/16


必要としない．

従来の I/Oデバイスのネットワークを実現する別の手

法として，ソフトウェア I/Oスタックを分離する手法が

ある．分離された I/Oスタックは異なるホストに配置さ

れ，それらのスタック間の通信をネットワークで伝送す

る．Hirofuchiらは USBスタックを [7]，Satranらは SCSI

スタックを [8] 分離する手法を提案した．これらの手法で

は I/Oデバイス及び IoTデバイスを保持するネットワー

クノードもホストコンピュータである必要があり，本稿の

目的と一致しない．

ホストの I/Oデバイスをホスト内のVMに割り当てる手

法も従来から複数提案されている．VMWare ESX Server

は I/O デバイスのドライバと VM からのアクセスを仲

介する仮想デバイスモデルの両方を VMMレイヤに保持

する [9]．一方 VMWare Workstation [10]や KVM [11]の

I/Oデバイスはホスト OSで動作するデバイスドライバか

ら駆動される．これらの方式では VMの I/Oデバイスへ

のアクセスはホスト OSのアプリケーションプログラムと

して動作するエミュレータで仲介される．また，I/Oデバ

イス仮想化のオーバヘッド削減に関する研究も実施されて

いる．パススルーモードはホストの I/Oデバイスをソフト

ウェア処理の仲介なく VMに割り当てる技術である [12]．

これにより I/Oデバイスから VMのメモリ領域に DMA

が行えるようになった．パススルーモードをハードウェア

で支援する技術としてアドレス変換 [13]や新たな PCIeデ

バイスのインターフェース [14]も導入された．本稿で提案

したソフトウェア ExpEtherでは KVMのパススルーモー

ドを拡張した．ソフトウェア ExpEtherはパススルーモー

ドを利用し，VMから遠隔 I/Oデバイスへのアクセスを検

出する．また遠隔 I/Oデバイスを用いるための新たな仮想

化レイヤを付加している．これらの拡張部分は主にホスト

OSのアプリケーションプログラムとして動作する．

VMMはまた，内包する VMのセキュア環境を実現する

手段としても用いられている [15]．その中で BitVisor [9]

は I/Oデバイスのセキュリティに着目している．パスス

ルーモードを用いた小規模の VMMがセキュリティの目的

でパススルーの I/Oアクセスを傍受する．一方提案手法

ではパススルー I/Oアクセスが検出され，イーサネットを

用いて接続した遠隔 I/Oデバイスへのアクセスに変換さ

れる．

7. まとめ

本稿ではイーサネットに分散する IoTデバイスが小型

コンピュータではなく I/Oデバイスのみと合わせて実装

される I/Oデバイスの IoT化に着目した．そして I/Oデ

バイスの IoT化を実現する新しい仮想化アーキテクチャ

としてソフトウェア ExpEtherを提案した．ソフトウェア

ExpEtherは IoTデバイスと合わせて実装される I/Oデバ

イスを遠隔の制御ホストに割り当て，制御ホストからロー

カルデバイスとして使用できるようにする．またソフト

ウェア ExpEtherはホストに特殊なハードウェアブリッジ

を必要としない．

ソフトウェア ExpEtherは遠隔の I/Oデバイスをホスト

の I/Oデバイスツリーに属すように仮想化する．そして

制御ホストと遠隔 I/Oデバイスとの間の PCIeトランザク

ションを仮想化ソフトウェアのレイヤで実現する．ソフト

ウェア ExpEtherは遠隔 I/Oデバイスのアドレス予約，コ

ンフィギュレーション，アドレスマッピング，そして TLP

作成とイーサネットフレームへのカプセル化機能を有す

る．仮想化は PCIeレイヤで行うため，PCIe標準に準拠す

るあらゆる I/Oデバイスが接続可能である．それに加え，

イーサネットスイッチ，I/Oデバイス，ドライバ，ドライ

バが動作する OSに変更の必要がない．

本稿ではソフトウェアExpEtherのプロトタイプをKVM

を用いて作成した．またプロトタイプの性能評価をNIC及

び SATAコントローラを用いて行った．評価結果は提案手

法の実現性と一般的な I/Oデバイスに対する広い適用性を

示した．しかし，本稿の初期実装では仮想化オーバヘッド

により遠隔 I/Oデバイスの性能が 68-90% 低下することが

わかった．これらのオーバヘッドは実装の改善による改善

が見込まれ，今後の課題である．

参考文献

[1] Suzuki, J. et al.: ExpressEther - Ethernet-Based Virtu-alization Technology for Reconfigurable Hardware Plat-form, Proc. IEEE Symposium on High Performance In-terconnects (HOTI’06), Stanford, CA, pp. 45–51 (2006).

[2] : Thunderbolt Technology, , available from〈http://www.intel.com/content/www/us/en/architecture-and-technology/thunderbolt/thunderbolt-technology-brief.html〉

[3] Shimonishi, H. et al.: A Congestion Control Algorithmfor Data Center Area Communications, Proc. IEEECQR Int. Workshop (2008).

[4] : Data Plane Development Kit, , available from〈http://dpdk.org/〉

[5] Hayashi, Y. et al.: Delay-Bounded Transport using Rate-less Codes for I/O Bus over Wireless Ethernet, Proc.IEEE International Conference on Communications,Kuala Lumpur, Malaysia (2016).

[6] Krishnan, V.: Evaluation of an Integrated PCI ExpressIO Expansion and Clustering Fabric, Proc. 16th IEEESymposium on High Performance Interconnects, Stan-ford, CA, pp. 93–100 (2008).

[7] Hirofuchi, T. et al.: USB/IP-A peripheral bus extensionfor device sharing over IP network, Proceedings of theannual conference on USENIX Annual Technical Con-ference, USENIX Association, pp. 42–42 (2005).

[8] Satran, J. and Meth, K.: Internet small computer sys-tems interface (iSCSI), RFC3720 (2004).

[9] Shinagawa, T. et al.: BitVisor: A Thin Hypervisorfor Enforcing I/O Device Security, Proceedings of the2009 ACM SIGPLAN/SIGOPS international confer-ence on Virtual execution environments, ACM, pp. 121–


Vol.2017-OS-140 No.62017/5/16


130 (2009).

[10] Sugerman, J. et al.: Virtualizing I/O Devices onVMware Workstation’s Hosted Virtual Machine Moni-tor., USENIX Annual Technical Conference, GeneralTrack, pp. 1–14 (2001).

[11] Habib, I.: Virtualization with KVM, Linux Journal,Vol. 2008, No. 166, p. 8 (2008).

[12] Ben-Yehuda, M. et al.: Utilizing IOMMUs for virtual-ization in Linux and Xen, OLS’06: The 2006 OttawaLinux Symposium, Citeseer, pp. 71–86 (2006).

[13] Abramson, D. et al.: Intel Virtualization Technology forDirected I/O., Intel technology journal, Vol. 10, No. 3(2006).

[14] Raj, H. and Schwan, K.: High performance and scal-able I/O virtualization via self-virtualized devices, Pro-ceedings of the 16th international symposium on Highperformance distributed computing, ACM, pp. 179–188(2007).

[15] Garfinkel, T. et al.: A Virtual Machine Introspec-tion Based Architecture for Intrusion Detection., NDSS,Vol. 3, pp. 191–206 (2003).


Vol.2017-OS-140 No.62017/5/16

I/O ÃÌ µw IoT = îqb ¹ÑÄ¢£ ExpEther w

Documents

Transcript of I/O ÃÌ µw IoT = îqb ¹ÑÄ¢£ ExpEther w