高速大容量通信技術に関する評価報告

Evaluation report of high–speed, wide–bandwidth data communication technology
濱村 翠＊ 藤野 遥子＊ 原 周＊

Midori Hamamura, Yoko Fujino, Hiroshi Hara

次世代無線通信規格：５G サービスの国内運用が本格開始され、５G 規格相当の製品開発の需要が急激に高まってきている。５G 規格では、高速大容量（eMBB）、低遅延（URLLC）、多数同時接続（mMTC）の３つの特長が定義されており、今後の通信システムの開発においても、ソフトウェアでの高速大容量通信の実現を求められることが予想される。そのような環境変化に備えた、通信速度向上の１つの策として、DPDK（Data Plane Development Kit：オープンソースの高速パケット処理用ライブラリとネットワークドライバのセット）を用いた、汎用サーバ上での高速大容量通信技術の確立を検討する。本稿では、この検討過程で検証した、DPDK 適用効果について報告する。
In Japan, some of the cellular phone companies have launched the full services using ５G（the５th generation technology standard for broadband cellular networks）. By this, the demand for ５G
products and systems increases rapidly. ５G has three main application areas, enhanced Mobile
Broadband（eMBB）, Ultra Reliable Low Latency Communications（URLLC）, and Massive MachineType Communications（mMTC）. We must implement these merits with the software in the future
telecommunication system. We are studying to construct the high–speed and wide–bandwidth datatransmission technology on a general–purpose server with DPDK（Data Plane Development Kit）
. In
this paper, we report the result of this consideration.

マートメータ分野のような多種多様なサービスに広がって

1．
まえがき

きている。また、携帯電話事業者による公衆網を用いた2020 年、従来の４G に比べ飛躍的な進化を遂げ、５Gサービスだけでなく、地域や事業者のニーズに応じて５サービスの運用が本格的に開始された（表１）。通信シス

G を活用するシステム（ローカル５G）の導入も広がり

テム分野においても、５G の特長（高速大容量、低遅延、つつある。今後、５G への移行と共に IoT 関連サービス多数同時接続）に対応した性能を持つ製品開発の需要がも更に充実し、高速大容量通信のニーズが高まってくる高まりつつある。2030 年代に商用化が期待されているものと予測する。

Beyond ５G（＊1では、持続可能な新たな価値の創造に資

高速大容量通信を実現する場合、従来は、専用のハーする特長を付加する議論も始まっている。このような背ドウェアやチップを用い、FPGA（＊2や DSP（＊3で開発す景から、通信容量の拡大と高速化の流れはますます加速ることが一般的であった。しかし、通信ニーズが多様化することが予想され、進化し続ける通信システム市場をしている現在、実現機能に特化した高価な専用ハード開拓し続けていくためには、高度な通信技術を先行的にウェアではなく、多種多様なサービスを同時に実現できる獲得しておくことが重要と考える。

安価な汎用サーバを用いた通信ソフトウェア開発の需要

通信システム市場は、IoT の普及により通信ニーズがが見込まれる。つまり、汎用サーバ上のソフトウェアで多様化し、自動車、産業機器、ホームセキュリティ、ス高速大容量通信を実現しておくことが価格／性能面で

表1
項目
伝送速度
遅延接続数大きなアドバンテージとなる。さらに、５G サービスの４G ／５G 特長比較

４G
0.1 ～１Gbps
10 ミリ秒
10 万台／ km2＊関西事業部 第三技術部

運用が始まり、５G 規格相当の製品開発の需要が急激に

５G
10 ～ 20Gbps
１ミリ秒以下100 万台／ km2

伸びつつある今、ソフトウェアによる高速大容量通信技術の早期確立は急務である。
本稿は、通信速度の向上が期待できる技術の１つである、

1MSS 技報・Vol.31

DPDK を適用した試作ソフトウェアの開発、評価に取りDPDK に関する評価結果について報告するものである。

組んでおり、その過程で得た DPDK 導入のための制約、2．DPDK を用いた高速大容量通信留意点を交え、次章以降で評価環境、方法、結果、課題について順に述べていく。

DPDK は、高速パケット処理を実現するネットワーク処理高速化技術の１つである。2010 年に Intel DPDK と3．
評価環境してリリースされた。リリース当初は、Intel 製の一部

本章では、DPDK 適用評価の環境について記述する。

NIC（＊4 のみへの対応であったが、2013 年に DPDK.orgが設立され、DPDK に名称を変えて以降、AMD の axgbe

3.1

や、Atomic Rules の ark、Cisco の eNic、Intel の e1000など

ハードウェア構成

本評価で使用するハードウェア環境を表２に示す。

（＊5、徐々に対応する NIC を増やし、汎用性を高めてCPU は後述する通信制御ソフトウェア・モデルを適用すいる。

るため、６コア以上のものを選定し、DPDK に対応した

従来のアプリケーションは、カーネル上で動作し、NIC を搭載する。

ハードウェアを意識することなく、カーネルの提供するシステムコールを呼び出すことで、ハードウェアを制御3.2する。カーネルは、ハードウェアの制御を共通的に処理評価環境できるように実装していることから、個々の制御の性能面

DPDK の評価環境を図２に示す。

では、ハードウェアの持つ性能を、最大限に発揮できて試験機は１GB NIC を搭載し、送信／受信の各機材をいない。カーネルの通信処理は、この、本来の実力を発用意する。測定系は、２系統用意し、１Gbps 環境と、２揮できていない部分に含まれる。これに対し DPDK は、Gbps 環境を構築する。２Gbps 環境では、各機材をそれ従来カーネルで行っていた NIC の制御をユーザ空間でぞれ２セット用意する。

行うことを目的とし、カーネル機能をバイパスすること伝送スループットを測定するために、ネットワーク・で、NIC の性能を最大限まで引き出す高速パケット処理

パフォーマンス測定ツール iperf 2.0.10 を使用する。受を実現している（図１）。

信機をサーバモードで、送信機をクライアントモードで起動し、評価用ハードウェア経由でパケットの送受信をこのように理論的には、DPDK を用いることで、通信行う設定とする。

に関するカーネルの冗長な処理部分を通さずに、高速大容量通信を実現できる。しかし、製品開発に導入するためには、導入の容易さはもちろんのこと、メリット、表２デメリットを押さえたうえで判断する必要がある。そこ

CPUで 現 在、 高 速 大 容 量 通 信 を 模 擬 す る 環 境 を 用 意 し、一般的な通信ユーザ空間
アプリケーション'3'.を用いた通信

クロック周波数
CPU 数
コア数
メモリ容量

NIC

アプリケーション

DPDK 動作ハードウェア

項目

説明Intel Xeon CPUD–1577
1.30 GHz
１1616 Gbyte
Intel Ethernet Connection X552 ／X557–AT 10 GBASE–T'3'.ライブラリ及びネットワークドライバ

評価用ハードウェア

カーネル

2Gbps環境の場合

システムコール
インタフェース

システムコール、メモリ管理、ドライバ管理HWF【オーバーヘッド解消】
カーネルを介さずに'3'.
ライブラリから直接1,&を制御することで、カーネルでの処理がなくなる。

1Gbps環境の場合

システムコール、メモリ管理、ドライバ管理HWF

送信機1

ハードウェア

HUB

受信機2

送信機2
1,&

図1

1,&

パケット伝送経路

DPDK の仕組み

図２

2

受信機1

上り

下り

DPDK 評価環境（1Gbps ／２Gbps）

MSS 技報・Vol.31

各々専用のコアを割り当てる。SWA は SWB との比較評

4．
評価方法

価を行うため、SWB と同じコア割り当てとする。

本章では、DPDK の有用性を判断するために、表3に4.2

示すとおり、段階的に評価を行う。

通信制御ソフトウェア・モデルへの適用評価

SWB に一部受信パケットを外部へ転送する機構を持

２つの評価手順では、それぞれ目的に応じた評価用のたせた SWC モデルを用いて評価を行う（図４）。

ソフトウェアを準備する。本評価で使用するソフトウェ

SWC は、主に自社で開発している通信制御ソフト

アを表４に示す。

ウェアに DPDK を適用する場合を想定し、モデル化して以降、各手順で使用する評価対象ソフトウェアの詳細いる。通信制御ソフトウェアが取り扱うパケットは、と、評価する測定項目について述べる。

表５のように制御データパケット（C–Plane、M–Plane）
4.1

対向通信モデルでの DPDK 評価とユーザデータパケット（U–Plane）に大別できる。

SWA、SWB の２モデルを用いて評価を行う（図3）。

通常、制御データパケットの伝送量はユーザデータパSWA、SWB は、共に送信機から受信したパケットをケットの数パーセント程度で、制御データパケットが複受信機に転送する同一の機構とし、パケット送受信部分雑な処理を伴うのに対し、ユーザデータパケットは簡易のみを置き換える。SWA は Linux Kernel の標準通信な処理と転送処理が中心となることが多い。このようなライブラリを、SWB は DPDK ライブラリを使用して両データ特性から、通信制御ソフトウェアではデータ種別に者の性能を比較する。DPDK は受信契機を常時監視する応じて処理を分離して設計している。高速大容量通信に仕組みにより性能が発揮されるため、SWB は受信／送信よりパケット伝送量が増えるケースは主にユーザデータパケットと想定されるため、SWC では、その処理部分をDPDK 評価手順分離して DPDK を適用したモデルとする。DPDK は NIC

説明
DPDK 適 用 ／ 非 適 用 の プ ロ グ ラ ム を対向通信モデル各々試験機と対向させ、DPDK によるでの性能評価速度性能の優位性を確認する。
通信制御ソフト 通信制御ソフトウェアをモデル化し、
ウ ェ ア・ モ デ ル 評価手順１の結果と比較して DPDK 適への適用評価用効果のあるシステム要件を抽出する。

を占有するため、ユーザデータパケットと制御データパ表３
手順
１
２

評価内容

表４
項目

名称
Ubuntu
Linux
DPDK
SWA
SWB

OS
Kernelライブラリ
評価対象SWCケットの双方を DPDK 適用プロセスで受信するが、制御データをプロセス間通信により Linux Kernel 上で動作するプロセスへ転送することで処理を分離する。
これらを踏まえ、図４で示す SWC は受信パケットの評価ソフトウェア

SWC

バージョン／説明18.04 LTS
4.15.0–72–lowlatency
19.11
DPDK 非適用プログラム
DPDK 適用プログラム
DPDK 適用プログラム（通信制御ソフトウェア・モデル）

DPDK非非適用プログラム

DPDK適適用プログラム[コア4]
Rxスレッド[コア2]
Analyzeスレッド

受信バッファ

Ana-Tx間キュー[コア5]
Analyze＋Txスレッド

Rx-Ana間キュー[コア3]
Txスレッド[コア1]
RxスレッドDPDKライブラリ
受信バッファ

kernelライブラリ
OS(Linux)
SWA：：DPDK非非 適 用 プ ロ グラ ム

SWB：：DPDK適適 用 プ ロ グラ ム
更新

[コア2]
Analyzeスレッド[コア2]
Analyzeスレッド

ハードウェア更新

NIC

受信[コア3]
Txスレッド[コア1]
Rxスレッド参照

参照

Ana-Tx間キュー

Rx-Ana間キュー

Ana-Tx間キュー

Rx-Ana間キュー[コア1]
Rxスレッド送信[コア3]
Txスレッド受信バッファ

プロ
ロセ ス 間通信（矢矢印先が受信）参照

参照

DPDKライブラリ

プロセス間通信しない場合のデータ経路

図４

ソフトウェア構成図（評価手順２）

表５

通信制御ソフトウェア処理パケット

受信バッファ

kernelライブラリ
RAWソケットOS(Linux)

OS(Linux)

ハードウェアハードウェア

種別
C–Plane
M–Plane

NIC

NIC

受信

図３

プロセス間通信する場合のデータ経路

送信

U–Plane

ソフトウェア構成図（評価手順1）

3

説明
制御、監視等のイベントにより発生するパケット
音声、映像等の定常的に伝送されるパケット伝送量

プロトコル

小TCP

大UDP

MSS 技報・Vol.31

転送経路を２つ設定する。プロセス間通信を介さずにLinux KernelとDPDKのパケット処理を比較した場合、DPDK でパケットの転送を行う経路と、プロセス間通信DPDK のほうが１パケット当たりの処理効率が良い。

を介してパケットの転送を行う経路である。

これは、Linux Kernel のパケット処理では、netfilter によるパケットフィルタリングやルーティングが行われる

4.3

測定項目

が、DPDK ではそれらを実施しないため、パケット処理

本評価で確認した測定項目を表６に示す。各項目はの効率が良いことが要因と推測する。

データ長ごとに 180 秒間測定する。

さらに、データ長が 1024 byte 以降では、DPDK 適用有無に関わらず、ジッタが増加している。これは、測定

表６
ジッタ

項目に使用した送信機の性能限界により、送信時点で既に測定項目一覧

測定ツール
iperf
ping RTT（往復時間）
iperf

レイテンシ
スループット

周期１秒

ジッタが増大したことによるものである。5.3 節で後述す

１秒

送信機当たりのスループットが１Gbps 近くに到達してるとおり、データ長が 1024 byte 以上の場合は、１つの１秒いた。送信機に搭載されている NIC は１GbE であるた
め、性能限界に近いスループットが入力されていたこと※ジッタとは、伝送時のデータの揺らぎのこと。レイテンシとは、データの応答時間のこと。スループットは、データの伝送速度を表す。になる。このような状況では NIC の性能がボトルネックとなり、測定結果が悪化したものと考える。本問題を解消するには、１Gbps 以上の性能を有する NIC を送信

5．
評価結果・考察機に搭載する必要がある。

各測定項目の結果を以下に示す。また以降、SWA、さらに、SWB と直結は長時間稼働した場合に、周期的SWB、SWC のデータと併せ、比較用に評価用ハードな変動や連続的なバーストが発生しないかを確認するた

ウェアを経由せずに試験機をエンド・ツー・エンドで直めに、1000 秒間の測定を行った。ジッタ発生の分布は、結して測定した値（以降、直結）も示す。

正 規 分 布 に 従 う と 仮 定 し、 代 表 値 と し て デ ー タ 長
32 byte での測定結果から得られた確率密度分布を、図６5.1

ジッタに示す。
図６から、SWB と直結の分布傾向はおおむね同じであ

２Gbps での各データ長での SWA、SWB、直結の平均り、周期性や連続的なバーストの発生等の特異な傾向はジッタ測定結果を図５に示す。

見られない。

SWB では、32 ～ 1024 byte まで直結に近い測定結果となった。SWA と比べ、データ長あたりの変動も少ない。

5.2

SWA は 32 ～ 1024 byte まで送信機１と２で差異もみらレイテンシ

２Gbps での各データ長での SWA、SWB、直結の平均れるが、総じて SWB は SWA よりジッタが低い。

レイテンシ測定結果を図７に示す。

これらの理由として、以下が挙げられる。

SWA は全体的にレイテンシの変動が大きい。一方で、SWB は変動が小さく、直結に近い測定結果となった。

0.035

また、データ長が 1024 byte 以降では、DPDK 適用有無

0.03に関わらず、レイテンシが増加している。

0.020.4
0.35

0.015
0.010.005
0SWB

0.3

確率密度

ジッタ[ms]

0.025

0200

400

600

800

1000

1200

14000.05

データ長[byte]
SWA

SWB

SWB

直結

直結

送信機1

送信機2

送信機1

送信機2

送信機1

送信機2

図５0.2
0.15
0.1

1600

SWA

直結

0.25

000.002
20.004460.0060.0088ジッタ(msec)

SWA、SWB、直結平均ジッタ

図６4

ジッタ発生の確率密度分布（データ長 32 byte）

MSS 技報・Vol.31

20.02
0.018

SWB

0.016

確率密度

RTT時間[ms]

直結

0.014

1.5

10.0120.010.008
0.006
0.004
0.002

0.5

000.05500.11000.151502000.22500.25

レイテンシ(msec)
00200400-0.5600

800

1000

1200

1400

図81600

分割し測定した。また、プロセス間通信による処理遅延

データ長[byte]
SWA

SWA

SWB

SWB

直結

直結

送信機1送信機2

送信機1

送信機2

送信機1送信機2

図7レイテンシ確率密度分布（データ長 32 byte）

及び通信遅延が、システム全体の速度性能に与える影響を確認するために、全データをプロセス間通信した場合も併せて測定した。

SWA、SWB、直結平均レイテンシ以下で、各測定結果の考察を述べる。
(1)

この傾向は、ジッタと同様であることから、ジッタと適用効果について

図 ９ か ら、TCP と UDP 共 に、 １ Gbps で は Linux同じ要因が発生しているものと考える。
レイテンシも、長時間稼働した場合に周期的な変動やKernel と DPDK を用いた場合で速度性能差はない。図連続的なバーストが発生しないかを確認するために、10 から、２Gbps では、DPDK の効果が顕著に現れた。

1000 秒間の測定を行った。レイテンシの分布も、正規分(2)有効範囲について

図 10 の UDP 通信において、データ長が 1024 byte 付布に従うと仮定し、代表値としてデータ長 32 byte での

近で、送信機と受信機の一組当たりのスループットが、測定結果から得られた確率密度分布を図８に示す。
図８から、直結と SWB では中央値に差はあるものの、１Gbps に到達し、NIC の性能限界に至っていた。この分布傾向はおおむね同じであり、周期性や連続的なバーため、今回の測定では 1024 byte 未満を有効範囲としてストの発生等の特異な傾向は見られない。

考える。

5.3

TCP 1Gbps平均スループット

スループット1000

１Gbps、２Gbps での各データ長でのスループットの800

スループット[Mbits/sec]

結果を以下に示す。
SWC の測定に関しては、SWA と SWB で差異が見られない場合は、SWC も同様の結果になると考え、SWBと SWA で差異がみられた２Gbps の UDP のみ測定を行った。測定内容も、通信制御ソフトウェア・モデルを適用した適用効果を確認するために、プロセス間通信の600
40020000200

SWA

1000１Mbps 未満となるものが大半を占める。このことを踏

800

スループット[Mbits/sec]

100 byte 未満のものが多く、必要とされる速度性能もまえ、表７に示す比率で、制御データとユーザデータを制御データ
ユーザデータ

800

1000

1200

SWB

1000

1200

直結

UDP 1Gbps平均スループット

御 ソ フ ト ウ ェ ア で は、 制 御 デ ー タ は、 デ ー タ 長 がデータ

600

データ長[byte]トラヒックを変化させ測定を行った。一般的に、通信制

表7400

データ分割内容
内容

データ長：64 byte
流量：SWB の全流量の１%
流量：SWB の全流量から制御データ分を除いた
もの

600
400
20000200400

SWA

図95600800

データ長[byte]
SWB

直結

１Gbps 平均スループット

MSS 技報・Vol.31

表8スループット[Mbits/sec]

TCP 2Gbps平均スループット
2000
1800
1600
1400
1200
1000
800
600
4002000

データ長［byte］

0200

400

600

800

1000

1200

1400

3264
128
256
512
768
1,024
1,280
1,460

1600

データ長[byte]
SWA

SWB

直結

UDP 2Gbps平均スループット
スループット[Mbits/sec]

2000
1800
1600
1400
1200
1000
800
600
400
200
0

２Gbps スループット比

スループット比（対 SWA）［倍］
SWB

SWC
UDP

TCP

UDP

1.01
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00

7.79
5.44
6.10
4.14
2.21
1.54
1.24
0.99
1.00

全データプロセス間通信
2.25
2.10
1.84
2.11
1.68
1.47
1.24
1.00
1.00

制御データ分割
7.58
5.44
6.01
4.14
2.19
1.53
1.23
0.99
0.99

測定有効
範
囲
○
○
○
○
○
○－－－

場合もまとめて送信するためであると考える。実際に、データ長 32 byte を指定して送信した場合でも、伝送時の実際のデータ長は 400 ～ 2000 byte であり、指定したデータ長よりも長いパケットとなっている。データ長の長いパケットは、短いパケットよりもスループットを得
0200

400

600

800

1000

1200

1400

やすいため、UDP の場合と比較して早い段階で速度性能

1600

データ長[byte]
SWA

SWB

直結

SWC（全データプロセス間通信）が出る結果となっている。
また今回は送信側の性能も２Gbps であり、TCP 通信
では送信側によって通信速度が制御されるため、結果的

SWC（制御データ分割）

図 10に Linux Kernel でも処理できる程度の速度となり、TCP通信ではDPDKの速度優位性は確認できなかった。今後、２Gbps 平均スループット１Gbps 以上の通信性能をもつ NIC などを用いて性能を(3)確認する必要がある。

通信制御ソフトウェア・モデルについて(2)

表８から、今回の測定の有効範囲において、DPDK 適

UDP 通信について用による速度性能の改善効果は約 1.5 ～ 7.7 倍得られるこ

今回の結果から、UDP では DPDK の適用有無によるとが分かった。また、全データプロセス間通信を行った性能差があった。特にデータ長の短い場合において、場合においても、SWA よりも約 1.4 ～ 2.2 倍速度性能がより顕著であった。これは、パケット伝送量に差がある改善している。また、制御データ分割を行った場合は、ためと考えられる。
UDP 通信においては、同一帯域の場合、ヘッダなどが約 1.5 ～ 7.5 倍の速度性能となり、SWB と同程度のスルー付加されるため、帯域上限まで送信するパケット量はプットになった。
このことから、制御データを別プロセスで処理したとデータ長が短いパケットほど多くなる。今回実測した結しても、DPDK を適用したユーザデータの通信には影響

果、データ長 32 byte の場合のパケット量は、1460 byteがないと考えられる。つまり、通信制御ソフトウェアのの場合の約 27 倍であった。このように、UDP 通信では構成でユーザデータの高速通信が実現可能であることがデータ長の短い場合は、パケットの伝送量が多くなる。
データ長が短い場合に性能差がより顕著であったことわかった。

から、DPDK は１パケットあたりの処理効率が Linux２Gbps では、速度性能の改善効果が得られたが、TCPKernel よりも高いことがわかる。

通信と UDP 通信では得られる結果に差が生じた。この

これは、DPDK が Linux Kernel を用いた場合とは異点について考察する。
(1)なり、ハードウェアからの処理契機となる割り込みやTCP 通信について

今回の結果から、TCP での DPDK 適用有無による性能

カーネル空間のソケットバッファーへのコピー、プロト差はない。また、UDP と比べ比較的短いデータ長から通コルスタックの解析処理を行わずにユーザ空間にパケッ信帯域の限界まで速度性能が出ている。これは、TCP のトが伝達されることに起因する。このため、DPDK は１具備するウインドウサイズ機構により、データ長の短いパケットあたりの処理効率が高くなる。

6MSS 技報・Vol.31

て、受信パケットの取りこぼしを引き起こす可能性が高6．
結論まる。このような場合は、受信したパケットをプロセス間通信で他のプロセス（他のコア）に転送し、解析や制本章では、本評価で得られた結果を基に、DPDK 適用御を移譲する仕組みが必要となる。

効果とシステム要件を整理する。また、本測定の過程でまた、DPDK は Linux Kernel のネットワークプロト

判明した DPDK 適用時の注意点についても述べる。

コルスタックを使用できない。したがって、DPDK を使
6.1

DPDK 適用効果用してプロトコル処理を行う場合は、IP、ICMP といっ

本測定の結果を踏まえ、Linux Kernel で処理する場合た利用頻度の高いプロトコルについても、独自でネットと比較した DPDK 適用による効果は次の２つである。

ワークプロトコルスタックを開発する必要があるため、(1) ２Gbps 以上の帯域で、特にデータ長が 256 byte 以下DPDK 適用による性能効果とネットワークプロトコルのパケットを扱う場合は、２～ 7.5 倍の大幅なススタックに要するコスト／期間とのトレードオフを、十ループット改善を期待できる。

分に検証する必要がある。

(2)

ジッタ変動 0.006 ms 以下、レイテンシ 0.2 ms 以下に7．課題と今後の展開抑えられ、通信品質の向上が見込める。

本評価を踏まえ、課題及び今後の展開は次のとおり。

今回の測定では、１Gbps 以下のスループットでは適(1)用効果は得られなかった。１Gbps 以上のスループット

10 Gbps 環境での検証

環境準備の都合で、１GB NIC を２つ使用して２Gbps

要否が DPDK 適用の判断基準になると考える。
DPDK のホームページ等で公開されている測定結果はの帯域を確保したネットワーク環境で測定を行った。し複数 NIC を使用して測定しているケースが多いため、こかしながら、１GB NIC の性能限界により Linux Kernel

れまでは単一の NIC での効果有無を判断できなかった。と DPDK の TCP 通信での性能差異の確認で十分な測定

しかし、本評価では、１つの NIC を使用して DPDK のが 出 来 な か っ た。 ま た、 ５G の 最 大 ス ル ー プ ッ ト は評価を行い、改善効果があることを確認できた。

20 Gbps まで到達するといわれていることから、測定環

今回の結果は、１つの NIC のみを搭載するシステムに境の帯域の向上が必須である。直近では、市販品でも構対し、DPDK 適用する際の参考情報として活用できると築が容易な 10 GB NIC を用いたネットワーク環境を構築考える。

し、更なる評価を実施していく予定である。
(2)

6.2

システム要件パケットサイズ拡張による効果増大の検証

パケットサイズによる DPDK の優位性が確認された。
本測定では適用に至らなかったが、ジャンボフレームを本測定結果を踏まえて、システムに DPDK を適用するための必要要件は次のとおりである。

有効化した場合、パケットサイズが大きくなるため、よ(1)

NIC が DPDK に対応していることり一層の改善効果が得られる可能性がある。このため、(2)

DPDK が NIC を占有できること

今後はジャンボフレームを有効化したネットワーク環境(3)

DPDK を割り付けるコアを占有できること（複数コでの評価も行う予定である。ジャンボフレームを有効にアが存在すること）することで、SWC ではプロセス間通信にかかる処理負荷も増えていくため、ジャンボフレームの有効化が、SWC

6.3

DPDK 適用時の注意点の構成における性能に与える効果と影響も引き続き検証してゆく。

DPDK を適用する場合の注意点として、受信処理が(3)

ポーリング処理であることと、ネットワークプロトコルプロセス間通信の改善

本測定では、プロセス間通信の実現方式として、名前スタックを使用できない点が挙げられる。
DPDK は、パケットの受信において NIC をポーリング付きパイプを使用した。さらに、他のプロセス間通信方

す る こ と を 前 提 と し て 実 装 さ れ て い る。 こ の た め、式、例えば、共有メモリ等の別のプロセス間通信を使用

DPDK でパケット受信を行うプログラムは、NIC を常にすることで、更なる速度改善の余地を検討する。

監視することで、パケットの取りこぼしを防止すること(4)ノウハウの獲得になるため、コアの CPU 負荷は 100 % となる。受信パ

DPDK を使用したソフトウェアの開発ノウハウの獲ケットを転送するだけのような単純なシステムであれば得が必要である。本測定のために、DPDK の開発環境の問題は無いが、受信したパケットを解析し、解析結果に構築方法や、実機へのデプロイ方法といったノウハウを応じて制御を行うシステムでは、処理量の増大に応じ獲得できた。ただし、あくまで DPDK が有する多くの7MSS 技報・Vol.31

機能のうち、一部機能の利用にとどめているため、評価(3) 荻原直彦：第５世代移動通信システム（５G）の今できていない機能についても評価を進めてゆく。また、と将来展望，総務省総合通信基盤局（2019 年）

DPDK 適用時の制約として、DPDK の専用ネットワーク

https://www.soumu.go.jp/main_content/000633132.pdf

ドライバは Linux Kernel の制御外となることがある。

(4) 総務省：Beyond ５G 推進戦略（概要）（2020 年）

これにより、Linux で使用できるネットワーク管理系コ

https://www.soumu.go.jp/main_content/000702111.pdf

マンド（ifconfig 等）やデバッガ等が使えない。このように、保守性や解析性にデメリットがあるため、これらのIntel、Xeon は、Intel Corporation 又はその子会社の米制約についても解決してゆく。

国及びその他の国における商標又は登録商標です。
AMD は、
Advanced Micro Devices, Inc. の商標又は登録

8．
むすび商標です。
Cisco は、
Cisco Systems, Inc. 及びその関連会社の米国及

本稿では、ソフトウェアの高速大容量技術実現に向けたびその他の国における商標又は登録商標です。

１つの手段として、DPDK 導入による効果が、どの程度Ubuntu は、Canonical Ltd. の商標又は登録商標です。

見込めるのか、Linux Kernel を用いた場合との比較評価

Linux は、Linus Torvalds 氏の米国及びその他の国におについて述べた。

ける商標又は登録商標です。

評価の結果、DPDK 導入は有用であり、伝送速度の大幅な向上、通信品質の改善が得られることが分かった。

執筆者紹介

加えて、評価作業を通じて、製品開発への導入に向けた濱村 翠

課題設定が可能となった。
今後は、これらの課題を解決するとともに、我々の持2002 年入社。入社以来、携帯電話基地局や列車無線等つソフトウェア資産に DPDK を適用し、より具体的なの、情報通信システム、組込みシステムの開発に携わる。

ソフトウェアの評価を行っていきたいと考えている。
藤野 遥子
＊1

第６世代移動体通信システム：６G のこと

2013 年入社。入社以来、情報通信システム、組込みシス＊2

Field–Programmable Gate Array

テムの開発に携わる。

＊3

Digital Signal Processor＊4

Network Interface Card

原周

＊5

最新のサポート状況は DPDK ホームページ参照

2007 年入社。入社以来、衛星電話基地局やネットワーク機器等の、情報通信システム、組込みシステムの開発に参考文献携わる。

(1) DPDK：Data Plane Development Kit
https://www.dpdk.org/(2) Harald Welte：The journey of a packet through thelinux 2.4 network stack
http://ftp.gnumonks.org/pub/doc/packet-journey-2.4.html

8MSS 技報・Vol.31