ホーム > 特許ランキング > 日本電信電話株式会社
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024180507
(43)【公開日】2024-12-26
(54)【発明の名称】サーバおよびプログラム
(51)【国際特許分類】
G06F 9/48 20060101AFI20241219BHJP
G06F 9/455 20180101ALI20241219BHJP
【ＦＩ】
G06F9/48 100Z
G06F9/455 150
【審査請求】有
【請求項の数】7
【出願形態】ＯＬ
(21)【出願番号】P 2024177790
(22)【出願日】2024-10-10
(62)【分割の表示】P 2023506646の分割
【原出願日】2021-03-18
(71)【出願人】
【識別番号】000004226
【氏名又は名称】日本電信電話株式会社
(74)【代理人】
【識別番号】110001807
【氏名又は名称】弁理士法人磯野国際特許商標事務所
(72)【発明者】
【氏名】藤本 圭
(72)【発明者】
【氏名】金子 雅志
(57)【要約】
【課題】消費電力の低減を図りつつ、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行う。
【解決手段】OS７０が、リングバッファ７２と、ポールリスト１８６と、を有し、カーネル１７１内に、ポーリングモデルを用いてパケット到着を監視するthreadを立ち上げるサーバ内遅延制御装置１００を備え、ポールリスト１８６を監視するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファ７２に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファ７２から削除する刈取りを実行するパケット刈取部１２０と、パケットが所定期間到着しない場合はスレッドをスリープさせ、かつ、パケット到着時はこのスレッドのハードウェア割込によりスリープ解除を行うsleep管理部１３０と、を備える。
【選択図】図１
【解決手段】OS７０が、リングバッファ７２と、ポールリスト１８６と、を有し、カーネル１７１内に、ポーリングモデルを用いてパケット到着を監視するthreadを立ち上げるサーバ内遅延制御装置１００を備え、ポールリスト１８６を監視するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファ７２に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファ７２から削除する刈取りを実行するパケット刈取部１２０と、パケットが所定期間到着しない場合はスレッドをスリープさせ、かつ、パケット到着時はこのスレッドのハードウェア割込によりスリープ解除を行うsleep管理部１３０と、を備える。
【選択図】図１
【特許請求の範囲】
【請求項1】
サーバ内遅延制御装置であって、
OSが、
カーネルと、
前記OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を有し、
前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
前記サーバ内遅延制御装置は、
前記ポールリストを監視するパケット到着監視部と、
パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、
パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、を備える
ことを特徴とするサーバ内遅延制御装置。
OSが、
カーネルと、
前記OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を有し、
前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
前記サーバ内遅延制御装置は、
前記ポールリストを監視するパケット到着監視部と、
パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、
パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、を備える
ことを特徴とするサーバ内遅延制御装置。
【請求項2】
サーバ内遅延制御装置であって、
仮想マシン内で動作するGuest OSが、
カーネルと、
前記Guest OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、
刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部と、を有し、
前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
前記サーバ内遅延制御装置は、
前記ポールリストを監視するパケット到着監視部と、
パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する前記刈取りを実行するパケット刈取部と、
パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、を備える
ことを特徴とするサーバ内遅延制御装置。
仮想マシン内で動作するGuest OSが、
カーネルと、
前記Guest OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、
刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部と、を有し、
前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
前記サーバ内遅延制御装置は、
前記ポールリストを監視するパケット到着監視部と、
パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する前記刈取りを実行するパケット刈取部と、
パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、を備える
ことを特徴とするサーバ内遅延制御装置。
【請求項3】
サーバ内遅延制御装置であって、
仮想マシンおよび前記仮想マシン外に形成された外部プロセスが動作可能なHost OSが、
カーネルと、
前記Host OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、
前記カーネルにより作成される仮想インターフェイスであるtapデバイスと、を備え、
前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
前記サーバ内遅延制御装置は、
前記ポールリストを監視するパケット到着監視部と、
パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、
パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、を備える
ことを特徴とするサーバ内遅延制御装置。
仮想マシンおよび前記仮想マシン外に形成された外部プロセスが動作可能なHost OSが、
カーネルと、
前記Host OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、
前記カーネルにより作成される仮想インターフェイスであるtapデバイスと、を備え、
前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
前記サーバ内遅延制御装置は、
前記ポールリストを監視するパケット到着監視部と、
パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、
パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、を備える
ことを特徴とするサーバ内遅延制御装置。
【請求項4】
前記スリープ中に、前記スレッドが使用するＣＰＵコアのＣＰＵ動作周波数を低く設定するCPU周波数設定部を備える
ことを特徴とする請求項１乃至３のいずれか一項に記載のサーバ内遅延制御装置。
ことを特徴とする請求項１乃至３のいずれか一項に記載のサーバ内遅延制御装置。
【請求項5】
前記スリープ中に、前記スレッドが使用するＣＰＵコアのＣＰＵアイドル状態を省電力モードに設定するＣＰＵアイドル設定部を備える
ことを特徴とする請求項１乃至３のいずれか一項に記載のサーバ内遅延制御装置。
ことを特徴とする請求項１乃至３のいずれか一項に記載のサーバ内遅延制御装置。
【請求項6】
前記カーネルは、当該カーネルを起動させたまま、処理動作を変更可能なパッチを有する
ことを特徴とする請求項１乃至３のいずれか一項に記載のサーバ内遅延制御装置。
ことを特徴とする請求項１乃至３のいずれか一項に記載のサーバ内遅延制御装置。
【請求項7】
サーバ内遅延制御装置のサーバ内遅延制御方法であって、
OSが、
カーネルと、
前記OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を有し、
前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置を備えており、
前記サーバ内遅延制御装置は、
前記ポールリストを監視するステップと、
パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するステップと、
パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うステップと、を実行する
ことを特徴とするサーバ内遅延制御方法。
OSが、
カーネルと、
前記OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を有し、
前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置を備えており、
前記サーバ内遅延制御装置は、
前記ポールリストを監視するステップと、
パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するステップと、
パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うステップと、を実行する
ことを特徴とするサーバ内遅延制御方法。
【請求項8】
OSが、
カーネルと、
前記OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を有し、
前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置を備えており、前記サーバ内遅延制御装置としてのコンピュータに、
前記ポールリストを監視するパケット到着監視手順、
パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取手順、
パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理手順、
を実行させるためのプログラム。
カーネルと、
前記OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を有し、
前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置を備えており、前記サーバ内遅延制御装置としてのコンピュータに、
前記ポールリストを監視するパケット到着監視手順、
パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取手順、
パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理手順、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラムに関する。
【背景技術】
【0002】
ＮＦＶ（Network Functions Virtualization：ネットワーク機能仮想化）による仮想化技術の進展などを背景に、サービス毎にシステムを構築して運用することが行われている。また、上記サービス毎にシステムを構築する形態から、サービス機能を再利用可能なモジュール単位に分割し、独立した仮想マシン（ＶＭ：Virtual Machineやコンテナなど）環境の上で動作させることで、部品のようにして必要に応じて利用し運用性を高めるといったＳＦＣ（Service Function Chaining）と呼ばれる形態が主流となりつつある。
【0003】
仮想マシンを構成する技術としてLinux（登録商標）とＫＶＭ（kernel-based virtual machine）で構成されたハイパーバイザー環境が知られている。この環境では、ＫＶＭモジュールが組み込まれたHost OS（物理サーバ上にインストールされたＯＳをHost OSと呼ぶ）がハイパーバイザーとしてカーネル空間と呼ばれるユーザ空間とは異なるメモリ領域で動作する。この環境においてユーザ空間にて仮想マシンが動作し、その仮想マシン内にGuest OS（仮想マシン上にインストールされたＯＳをGuest OSと呼ぶ）が動作する。
【0004】
Guest OSが動作する仮想マシンは、Host OSが動作する物理サーバとは異なり、（イーサーネットカードデバイスなどに代表される）ネットワークデバイスを含むすべてのＨＷ（hardware）が、ＨＷからGuest OSへの割込処理やGuest OSからハードウェアへの書き込みに必要なレジスタ制御となる。このようなレジスタ制御では、本来物理ハードウェアが実行すべき通知や処理がソフトウェアで擬似的に模倣されるため、性能がHost OS環境に比べ、低いことが一般的である。
【0005】
この性能劣化において、特にGuest OSから自仮想マシン外に存在するHost OSや外部プロセスに対して、ＨＷの模倣を削減し、高速かつ統一的なインターフェイスにより通信の性能と汎用性を向上させる技術がある。この技術として、virtioというデバイスの抽象化技術、つまり準仮想化技術が開発されており、すでにLinux（登録商標）を始め、FreeBSD（登録商標）など多くの汎用ＯＳに組み込まれ、現在利用されている。
【0006】
virtioでは、コンソール、ファイル入出力、ネットワーク通信といったデータ入出力に関して、転送データの単一方向の転送用トランスポートとして、リングバッファで設計されたキューによるデータ交換をキューのオペレーションにより定義している。そして、virtioのキューの仕様を利用して、それぞれのデバイスに適したキューの個数と大きさをGuest OS起動時に用意することにより、Guest OSと自仮想マシン外部との通信を、ハードウェアエミュレーションを実行せずにキューによるオペレーションだけで実現することができる。
【0007】
［割込モデルによるパケット転送（汎用VM構成の例）］
図９は、汎用Linux kernel（登録商標）およびＶＭ構成のサーバ仮想化環境における、割込モデルによるパケット転送を説明する図である。
ＨＷ１０は、NIC（Network Interface Card）１１（物理NIC）(インターフェイス部)を有し、Host OS２０、仮想マシンを構築するハイパーバイザーであるＫＶＭ３０、仮想マシン（ＶＭ１，ＶＭ２）４０、およびGuest OS５０により構築された仮想通信路を経由してuser space（ユーザスペース）６０上のパケット処理ＡＰＬ（Application）１との間でデータ送受信の通信を行う。以下の説明において、図９の太矢印に示すように、パケット処理ＡＰＬ１が、ＨＷ１０からのパケットを受け取るデータの流れをＲｘ側受信と称し、パケット処理ＡＰＬ１が、ＨＷ１０にパケットを送信するデータの流れをＴｘ側送信と称する。
図９は、汎用Linux kernel（登録商標）およびＶＭ構成のサーバ仮想化環境における、割込モデルによるパケット転送を説明する図である。
ＨＷ１０は、NIC（Network Interface Card）１１（物理NIC）(インターフェイス部)を有し、Host OS２０、仮想マシンを構築するハイパーバイザーであるＫＶＭ３０、仮想マシン（ＶＭ１，ＶＭ２）４０、およびGuest OS５０により構築された仮想通信路を経由してuser space（ユーザスペース）６０上のパケット処理ＡＰＬ（Application）１との間でデータ送受信の通信を行う。以下の説明において、図９の太矢印に示すように、パケット処理ＡＰＬ１が、ＨＷ１０からのパケットを受け取るデータの流れをＲｘ側受信と称し、パケット処理ＡＰＬ１が、ＨＷ１０にパケットを送信するデータの流れをＴｘ側送信と称する。
【0008】
Host OS２０は、kernel２１、Ring Buffer２２、およびDriver２３を有し、kernel２１は、kernel threadであるvhost-netモジュール２２１と、tapデバイス２２２と、仮想スイッチ(br)２２３と、を有する。
【0009】
tapデバイス２２２は、仮想ネットワークのカーネルデバイスであり、ソフトウェアでサポートされている。仮想マシン（ＶＭ１）４０は、仮想ブリッジ(bridge)に作成される仮想スイッチ(br)２２３を介してGuest OS５０とHost OS２０が通信できる。tapデバイス２２２は、この仮想ブリッジに作成されるGuest OS５０の仮想NIC（vNIC）と繋がるデバイスである。
【0010】
Host OS２０は、Guest OS５０の仮想マシン内で構築された構成情報（共有バッファキューの大きさ、キューの数、識別子、リングバッファへアクセスするための先頭アドレス情報など）をvhost-netモジュール２２１にコピーし、仮想マシン側の端点の情報をHost OS２０内部に構築する。このvhost-netモジュール２２１は、virtioネットワーキング用のカーネルレベルのバックエンドであり、virtioパケット処理タスクをユーザ領域（ユーザ空間）からkernel２１のvhost-netモジュール２２１に移すことで仮想化のオーバーヘッドを低減できる。
【0011】
Guest OS５０は、仮想マシン（ＶＭ１）上にインストールされたGuest OS（Guest１）と、仮想マシン（ＶＭ２）上にインストールされたGuest OS（Guest２）と、を有し、仮想マシン（ＶＭ１，ＶＭ２）４０内でGuest OS５０（Guest１，Guest２）が動作する。Guest OS５０として、Guest１を例に採ると、Guest OS５０（Guest１）は、kernel５１、Ring Buffer５２、およびDriver５３を有し、Driver５３は、virtio-driver５３１を備える。
【0012】
具体的には、ＰＣＩ（Peripheral Component Interconnect）デバイスとして仮想マシン内にコンソール、ファイル入出力、ネットワーク通信それぞれに対しvirtioデバイスが存在し（コンソールはvirtio-console、ファイル入出力はvirtio-blk、ネットワークはvirtio-netと呼ばれるデバイスとそれに対応するＯＳが持つドライバがvirtioキューで定義されている）、Guest OS起動時に、Guest OSと相手側とのデータの受け渡し端点（送受信端点）を２つ作り、データ送受信の親子関係を構築する。多くの場合、親子関係は仮想マシン側（子側）とGuest OS（親側）で構成する。
【0013】
子側は仮想マシン内のデバイスの構成情報として存在し、それぞれのデータ領域のサイズと必要とする端点の組み合わせの個数、デバイスの種別を親側に要求する。親側は子側の要求に従い、必要な分のデータを貯蓄し受け渡すための共有バッファキューのためのメモリを割り当て確保し、子側がアクセスできるようにそのアドレス番地を子側に返す。データの受け渡しに必要とされる共有バッファキューのオペレーションについては、virtioではすべて共通であり、親側、子側両方合意済みとして実行される。さらに共有バッファキューの大きさも両方合意済みとする（つまりデバイスごとに決まっている）。これにより、子側にアドレスを伝えるだけで、親側、子側の双方が共有するキューを操作することが可能となる。
【0014】
virtioにおいて用意する共有バッファキューは単一方向用として用意されるため、例えば、virtio-netデバイスと呼ばれる仮想ネットワークデバイスでは送信用、受信用、コントロール用の３つのRing Buffer５２で構成される。親と子の通信は、共有バッファキューへの書き込みとバッファ更新通知により実現し、Ring Buffer５２に書き込んだ後、相手側に通知する。相手側は通知を受けると、どの共有バッファキューにどの程度新規のデータが入っているのかをvirtioの共通オペレーションを利用して確認し、新規のバッファ領域を取り出す。これにより、親から子または子から親へのデータの受け渡しが成立する。
【0015】
以上のように、親子でお互いデータ交換用のRing Buffer５２とそれぞれのリングバッファ用のオペレーション方法（virtioで共通）を共有することにより、ハードウェアエミュレーションを必要としない、Guest OS５０と外部との通信を実現する。これにより、従来のハードウェアエミュレーションに比べ、Guest OS５０と外部とのデータの送受信を高速に実現することが可能である。
【0016】
仮想マシン内のGuest OS５０が外部と通信する場合は、子側が外部と接続し、子側が外部と親側の中継役としてデータを送受信する必要がある。例えば、Guest OS５０とHost OS２０間の通信がその例の１つである。ここで、外部をHost OS２０とした場合、既存の通信方法として２パターン存在する。
【0017】
第１の方法（以下、外部通信方式１と呼ぶ）は、仮想マシン内に子側の端点を構築し、Guest OS５０と仮想マシン間の通信と、Host OS２０が提供する通信端点（通常、tap／tunデバイスと呼ばれる）を、仮想マシン内で接続する。この接続により以下のとおりの接続を構築し、Guest OS５０からHost OS２０への通信を実現する。
【0018】
このとき、Guest OS５０はtapドライバやHost OS２０が動作するカーネル空間というメモリ領域とは異なる権限を持つユーザ空間であるメモリ領域で動作している。このため、Guest OS５０からHost OS２０への通信には最低１回メモリコピーが発生してしまう。
【0019】
第２の方法（以下、外部通信方式２と呼ぶ）は、これを解決する手段として、vhost-netという技術が存在する。vhost-netでは一度仮想マシン内で構築された親側の構成情報（共有バッファキューの大きさ、キューの数、識別子、リングバッファへアクセスするための先頭アドレス情報など）をHost OS２０内部のvhost-netモジュール２２１にコピーし、子側の端点の情報をホスト内部に構築する。この構築により、共有バッファキューの操作をGuest OS５０とHost OS２０間で直接実施することを可能とする技術である。これにより、コピーは実質０回で済むようになり、virtio-netに比べ、コピー回数が１回少ない分、外部通信方式１と比較し、より高速にデータ転送が実現できる。
【0020】
このように、virtioで接続されたHost OS２０とGuest OS５０において、virtio-net関連のメモリコピー回数を減らすことにより、パケット転送処理を高速化することができる。
【0021】
なお、kernel v4.10(2017.2～)以降、tapインターフェイスの仕様変更があり、tapデバイスから挿入されたパケットは、tapデバイスへパケットコピーを行った処理と同一コンテキスト内で完結されるようになった。これにより、ソフトウェア割込（softIRQ）の発生がなくなった。
【0022】
［ポーリングモデルによるパケット転送（DPDKの例）］
複数の仮想マシンを接続、連携させる手法はInter-VM Communicationと呼ばれ、データセンタなどの大規模な環境では、ＶＭ間の接続に、仮想スイッチが標準的に利用されてきた。しかし、通信の遅延が大きい手法であることから、より高速な手法が新たに提案されている。例えば、SR-IOV（Single Root I/O Virtualization）と呼ばれる特別なハードウェアを用いる手法や、高速パケット処理ライブラリであるIntel DPDK（Intel Data Plane Development Kit）（以下、ＤＰＤＫという）を用いたソフトウェアによる手法などが提案されている（非特許文献１参照）。
複数の仮想マシンを接続、連携させる手法はInter-VM Communicationと呼ばれ、データセンタなどの大規模な環境では、ＶＭ間の接続に、仮想スイッチが標準的に利用されてきた。しかし、通信の遅延が大きい手法であることから、より高速な手法が新たに提案されている。例えば、SR-IOV（Single Root I/O Virtualization）と呼ばれる特別なハードウェアを用いる手法や、高速パケット処理ライブラリであるIntel DPDK（Intel Data Plane Development Kit）（以下、ＤＰＤＫという）を用いたソフトウェアによる手法などが提案されている（非特許文献１参照）。
【0023】
ＤＰＤＫは、従来Linux kernel（登録商標）が行っていたＮＩＣ（Network Interface Card）の制御をユーザ空間で行うためのフレームワークである。Linux kernelにおける処理との最大の違いは、ＰＭＤ（Pull Mode Driver）と呼ばれるポーリングベースの受信機構を持つことである。通常、Linux kernelでは、ＮＩＣへのデータの到達を受けて、割込が発生し、それを契機に受信処理が実行される。一方、ＰＭＤは、データ到達の確認や受信処理を専用のスレッドが継続的に行う。コンテキストスイッチや割込などのオーバーヘッドを排除することで高速なパケット処理を行うことができる。ＤＰＤＫは、パケット処理のパフォーマンスとスループットを大幅に高めて、データプレーン・アプリケーション処理に多くの時間を確保することを可能にする。
【0024】
ＤＰＤＫは、ＣＰＵ（Central Processing Unit）やＮＩＣなどのコンピュータ資源を占有的に使用する。このため、ＳＦＣのようにモジュール単位で柔軟につなぎ替える用途には適用しづらい。これを緩和するためのアプリケーションであるＳＰＰ（Soft Patch Panel）がある。ＳＰＰは、ＶＭ間に共有メモリを用意し、各ＶＭが同じメモリ空間を直接参照できる構成にすることで、仮想化層でのパケットコピーを省略する。また、物理ＮＩＣと共有メモリ間のパケットのやり取りには、ＤＰＤＫを用いて高速化を実現する。ＳＰＰは、各ＶＭのメモリ交換の参照先を制御することで、パケットの入力先、出力先をソフトウェア的に変更することができる。この処理によって、ＳＰＰは、ＶＭ間やＶＭと物理ＮＩＣ間の動的な接続切替を実現する。
【0025】
図１０は、OvS-DPDK（Open vSwitch with DPDK）の構成における、ポーリングモデルによるパケット転送を説明する図である。図９と同一構成部分には、同一符号を付して重複箇所の説明を省略する。
図１０に示すように、Host OS２０は、パケット処理のためのソフトウェアであるOvS-DPDK７０を備え、OvS-DPDK７０は、仮想マシン（ここではＶＭ１）に接続するための機能部であるvhost-user７１と、ＮＩＣ（ＤＰＤＫ）１１（物理ＮＩＣ）に接続するための機能部であるdpdk(PMD)７２と、を有する。
また、パケット処理ＡＰＬ１Ａは、Guest OS５０区間においてポーリングを行う機能部であるdpdk(PMD)２を具備する。すなわち、パケット処理ＡＰＬ１Ａは、図９のパケット処理ＡＰＬ１にdpdk(PMD)２を具備させて、パケット処理ＡＰＬ１を改変したＡＰＬである。
図１０に示すように、Host OS２０は、パケット処理のためのソフトウェアであるOvS-DPDK７０を備え、OvS-DPDK７０は、仮想マシン（ここではＶＭ１）に接続するための機能部であるvhost-user７１と、ＮＩＣ（ＤＰＤＫ）１１（物理ＮＩＣ）に接続するための機能部であるdpdk(PMD)７２と、を有する。
また、パケット処理ＡＰＬ１Ａは、Guest OS５０区間においてポーリングを行う機能部であるdpdk(PMD)２を具備する。すなわち、パケット処理ＡＰＬ１Ａは、図９のパケット処理ＡＰＬ１にdpdk(PMD)２を具備させて、パケット処理ＡＰＬ１を改変したＡＰＬである。
【0026】
ポーリングモデルによるパケット転送は、DPDKの拡張として、共有メモリを介してゼロコピーでHost OS２０とGuest OS５０間、および、Guest OS５０間のパケットコピーを高速に行うＳＰＰにおいて、ＧＵＩにより経路操作を可能とする。
【0027】
［New API(NAPI)によるＲｘ側パケット処理］
図１１は、Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理の概略図である（非特許文献２参照）。図９と同一構成部分には、同一符号を付している。
図１１に示すように、New API(NAPI)は、OS７０（例えば、Host OS）を備えるサーバ上で、ユーザが使用可能なuser space６０に配置されたパケット処理ＡＰＬ１を実行し、OS７０に接続されたＨＷ１０のＮＩＣ１１とパケット処理ＡＰＬ１との間でパケット転送を行う。
図１１は、Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理の概略図である（非特許文献２参照）。図９と同一構成部分には、同一符号を付している。
図１１に示すように、New API(NAPI)は、OS７０（例えば、Host OS）を備えるサーバ上で、ユーザが使用可能なuser space６０に配置されたパケット処理ＡＰＬ１を実行し、OS７０に接続されたＨＷ１０のＮＩＣ１１とパケット処理ＡＰＬ１との間でパケット転送を行う。
【0028】
OS７０は、kernel７１、Ring Buffer７２、およびDriver７３を有し、kernel７１は、プロトコル処理部７４を有する。
Kernel７１は、OS７０（例えば、Host OS）の基幹部分の機能であり、ハードウェアの監視やプログラムの実行状態をプロセス単位で管理する。ここでは、kernel７１は、パケット処理ＡＰＬ１からの要求に応えるとともに、ＨＷ１０からの要求をパケット処理ＡＰＬ１に伝える。Kernel７１は、パケット処理ＡＰＬ１からの要求に対して、システムコール（「非特権モードで動作しているユーザプログラム」が「特権モードで動作しているカーネル」に処理を依頼）を介することで処理する。
Kernel７１は、Socket７５を介して、パケット処理ＡＰＬ１へパケットを伝達する。Kernel７１は、Socket７５を介してパケット処理ＡＰＬ１からパケットを受信する。
Kernel７１は、OS７０（例えば、Host OS）の基幹部分の機能であり、ハードウェアの監視やプログラムの実行状態をプロセス単位で管理する。ここでは、kernel７１は、パケット処理ＡＰＬ１からの要求に応えるとともに、ＨＷ１０からの要求をパケット処理ＡＰＬ１に伝える。Kernel７１は、パケット処理ＡＰＬ１からの要求に対して、システムコール（「非特権モードで動作しているユーザプログラム」が「特権モードで動作しているカーネル」に処理を依頼）を介することで処理する。
Kernel７１は、Socket７５を介して、パケット処理ＡＰＬ１へパケットを伝達する。Kernel７１は、Socket７５を介してパケット処理ＡＰＬ１からパケットを受信する。
【0029】
Ring Buffer７２は、Kernel７１が管理し、サーバ中のメモリ空間にある。Ring Buffer７２は、Kernel７１が出力するメッセージをログとして格納する一定サイズのバッファであり、上限サイズを超過すると先頭から上書きされる。
【0030】
Driver７３は、kernel７１でハードウェアの監視を行うためデバイスドライバである。なお、Driver７３は、kernel７１に依存し、作成された（ビルドされた）カーネルソースが変われば、別物になる。この場合、該当ドライバ・ソースを入手し、ドライバを使用するOS上で再ビルドし、ドライバを作成することになる。
【0031】
プロトコル処理部７４は、ＯＳＩ（Open Systems Interconnection）参照モデルが定義するＬ２（データリンク層）／Ｌ３（ネットワーク層）／Ｌ４（トランスポート層）のプロトコル処理を行う。
【0032】
Socket７５は、kernel７１がプロセス間通信を行うためのインターフェイスである。Socket７５は、ソケットバッファを有し、データのコピー処理を頻繁に発生させない。Socket７５を介しての通信確立までの流れは、下記の通りである。1.サーバ側がクライアントを受け付けるソケットファイルを作成する。2.受付用ソケットファイルに名前をつける。3.ソケット・キューを作成する。4.ソケット・キューに入っているクライアントからの接続の最初の1つを受け付ける。5.クライアント側ではソケットファイルを作成する。6.クライアント側からサーバへ接続要求を出す。7.サーバ側で、受付用ソケットファイルとは別に、接続用ソケットファイルを作成する。通信確立の結果、パケット処理ＡＰＬ１は、kernel７１に対してread()やwrite()などのシステムコールを呼び出せるようになる。
【0033】
以上の構成において、Kernel７１は、ＮＩＣ１１からのパケット到着の知らせを、ハードウェア割込（hardIRQ）により受け取り、パケット処理のためのソフトウェア割込（softIRQ）をスケジューリングする。
上記、Linux kernel 2.5/2.6より実装されているNew API(NAPI)は、パケットが到着するとハードウェア割込（hardIRQ）の後、ソフトウェア割込（softIRQ）により、パケット処理を行う。図１１に示すように、割込モデルによるパケット転送は、割込処理（図１１の符号ｃ参照）によりパケットの転送を行うため、割込処理の待ち合わせが発生し、パケット転送の遅延が大きくなる。
上記、Linux kernel 2.5/2.6より実装されているNew API(NAPI)は、パケットが到着するとハードウェア割込（hardIRQ）の後、ソフトウェア割込（softIRQ）により、パケット処理を行う。図１１に示すように、割込モデルによるパケット転送は、割込処理（図１１の符号ｃ参照）によりパケットの転送を行うため、割込処理の待ち合わせが発生し、パケット転送の遅延が大きくなる。
【0034】
以下、NAPI Rx側パケット処理概要について説明する。
［New API(NAPI)によるＲｘ側パケット処理構成］
図１２は、図１１の破線で囲んだ箇所におけるNew API(NAPI)によるＲｘ側パケット処理の概要を説明する図である。
<Device driver>
図１２に示すように、Device driverには、ネットワークインターフェースカードであるNIC１１（物理NIC）、NIC１１の処理要求の発生によって呼び出され要求された処理（ハードウェア割込）を実行するハンドラであるhardIRQ８１、およびソフトウェア割込の処理機能部であるnetif_rx８２が配置される。
［New API(NAPI)によるＲｘ側パケット処理構成］
図１２は、図１１の破線で囲んだ箇所におけるNew API(NAPI)によるＲｘ側パケット処理の概要を説明する図である。
<Device driver>
図１２に示すように、Device driverには、ネットワークインターフェースカードであるNIC１１（物理NIC）、NIC１１の処理要求の発生によって呼び出され要求された処理（ハードウェア割込）を実行するハンドラであるhardIRQ８１、およびソフトウェア割込の処理機能部であるnetif_rx８２が配置される。
【0035】
<Networking layer>
Networking layerには、netif_rx８２の処理要求の発生によって呼び出され要求された処理（ソフトウェア割込）を実行するハンドラであるsoftIRQ８３、ソフトウェア割込（softIRQ）の実体を行う制御機能部であるdo_softirq８４が配置される。また、ソフトウェア割込（softIRQ）を受けて実行するパケット処理機能部であるnet_rx_action８５、ＮＩＣ１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を登録するpoll_list８６、sk_buff構造体（Kernel７１が、パケットがどうなっているかを知覚できるようにするための構造体）を作成するnetif_receive_skb８７、Ring Buffer７２が配置される。
Networking layerには、netif_rx８２の処理要求の発生によって呼び出され要求された処理（ソフトウェア割込）を実行するハンドラであるsoftIRQ８３、ソフトウェア割込（softIRQ）の実体を行う制御機能部であるdo_softirq８４が配置される。また、ソフトウェア割込（softIRQ）を受けて実行するパケット処理機能部であるnet_rx_action８５、ＮＩＣ１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を登録するpoll_list８６、sk_buff構造体（Kernel７１が、パケットがどうなっているかを知覚できるようにするための構造体）を作成するnetif_receive_skb８７、Ring Buffer７２が配置される。
【0036】
<Protocol layer>
Protocol layerには、パケット処理機能部であるip_rcv８８、arp_rcv８９等が配置される。
Protocol layerには、パケット処理機能部であるip_rcv８８、arp_rcv８９等が配置される。
【0037】
上記netif_rx８２、do_softirq８４、net_rx_action８５、netif_receive_skb８７、ip_rcv８８、およびarp_rcv８９は、Kernel７１の中でパケット処理のために用いられるプログラムの部品（関数の名称）である。
【0038】
［New API(NAPI)によるＲｘ側パケット処理動作］
図１２の矢印（符号）ｄ～ｏは、Ｒｘ側パケット処理の流れを示している。
NIC１１のhardware機能部１１ａ（以下、NIC１１という）が、対向装置からフレーム内にパケット（またはフレーム）を受信すると、ＤＭＡ（Direct Memory Access）転送によりＣＰＵを使用せずに、Ring Buffer７２へ到着したパケットをコピーする（図１２の符号ｄ参照）。このRing Buffer７２は、サーバの中にあるメモリ空間で、Kernel７１（図１１参照）が管理している。
図１２の矢印（符号）ｄ～ｏは、Ｒｘ側パケット処理の流れを示している。
NIC１１のhardware機能部１１ａ（以下、NIC１１という）が、対向装置からフレーム内にパケット（またはフレーム）を受信すると、ＤＭＡ（Direct Memory Access）転送によりＣＰＵを使用せずに、Ring Buffer７２へ到着したパケットをコピーする（図１２の符号ｄ参照）。このRing Buffer７２は、サーバの中にあるメモリ空間で、Kernel７１（図１１参照）が管理している。
【0039】
しかし、NIC１１が、Ring Buffer７２へ到着したパケットをコピーしただけでは、Kernel７１は、そのパケットを認知できない。そこで、NIC１１は、パケットが到着すると、ハードウェア割込（hardIRQ）をhardIRQ８１に上げ（図１２の符号ｅ参照）、netif_rx８２が下記の処理を実行することで、Kernel７１は、当該パケットを認知する。なお、図１２の楕円で囲んで示すhardIRQ８１は、機能部ではなくハンドラを表記する。
【0040】
netif_rx８２は、実際に処理をする機能であり、hardIRQ８１（ハンドラ）が立ち上がると（図１２の符号ｆ参照）、poll_list８６に、ハードウェア割込（hardIRQ）の中身の情報の１つである、ＮＩＣ１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を保存して、キューの刈取り（バッファに溜まっているパケットの中身を参照して、そのパケットの処理を、次に行う処理を考慮してバッファから該当するキューのエントリを削除する）を登録する（図１２の符号ｇ参照）。具体的には、netif_rx８２は、Ring Buffer７２にパケットが詰め込まれたことを受けて、NIC１１のドライバを使って、以後のキューの刈取りをpoll_list８６に登録する（図１２の符号ｇ参照）。これにより、poll_list８６には、Ring Buffer７２にパケットが詰め込まれたことによる、キューの刈取り情報が登録される。
【0041】
このように、図１２の<Device driver>において、NIC１１は、パケットを受信すると、ＤＭＡ転送によりRing Buffer７２へ到着したパケットをコピーする。また、NIC１１は、hardIRQ８１（ハンドラ）を上げ、netif_rx８２は、poll_list８６にnet_deviceを登録し、ソフトウェア割込（softIRQ）をスケジューリングする。
ここまでで、図１２の<Device driver>におけるハードウェア割込の処理は停止する。
ここまでで、図１２の<Device driver>におけるハードウェア割込の処理は停止する。
【0042】
その後、netif_rx８２は、poll_list８６に積まれているキューに入っている情報（具体的にはポインタ）を用いて、Ring Buffer７２に格納されているデータを刈取ることを、ソフトウェア割込（softIRQ）でsoftIRQ８３（ハンドラ）に上げ（図１２の符号ｈ参照）、ソフトウェア割込の制御機能部であるdo_softirq８４に通知する（図１２の符号ｉ参照）。
【0043】
do_softirq８４は、ソフトウェア割込制御機能部であり、ソフトウェア割込の各機能を定義（パケット処理は各種あり、割込処理はそのうちの一つ。割込処理を定義する）している。do_softirq８４ｆは、この定義をもとに、実際にソフトウェア割込処理を行うnet_rx_action８５に、今回の（該当の）ソフトウェア割込の依頼を通知する（図１２の符号ｊ参照）。
【0044】
net_rx_action８５は、softIRQの順番がまわってくると、poll_list８６に登録されたnet_deviceをもとに（図１２の符号ｋ参照）、Ring Buffer７２からパケットを刈取るためのポーリングルーチンを呼び出し、パケットを刈取る（図１２の符号ｌ参照）。このとき、net_rx_action８５は、poll_list８６が空になるまで刈取りを続ける。
その後、net_rx_action８５は、netif_receive_skb８７に通達をする（図１２の符号ｍ参照）。
その後、net_rx_action８５は、netif_receive_skb８７に通達をする（図１２の符号ｍ参照）。
【0045】
netif_receive_skb８７は、sk_buff構造体を作り、パケットの内容を解析し、タイプ毎に後段のプロトコル処理部７４（図１１参照）へ処理をまわす。すなわち、netif_receive_skb８７は、パケットの中身を解析し、パケットの中身に応じて処理をする場合には、<Protocol layer>のip_rcv８８に処理を回し（図１２の符号ｎ）、また、例えばＬ２であればarp_rcv８９に処理をまわす（図１２の符号ｏ）。
【0046】
非特許文献３には、サーバ内ネットワーク遅延制御装置（ＫＢＰ：Kernel Busy Poll）が記載されている。ＫＢＰは、kernel内でpollingモデルによりパケット到着を常時監視する。これにより、softIRQを抑止し、低遅延なパケット処理を実現する。
【先行技術文献】
【非特許文献】
【0047】
【非特許文献1】“Developer Quick Start Guide Learn How To Get Involved With DPDK,” Intel, ［online］,［令和３年３月５日検索］,インターネット 〈 URL : https://www.dpdk.org/〉
【非特許文献2】New API(NAPI), ［online］,［令和３年３月５日検索］,インターネット 〈 URL : http:// http://lwn.net/2002/0321/a/napi-howto.php3〉
【非特許文献3】Kei Fujimoto, Kenichi Matsui, Masayuki Akutsu, “KBP: Kernel Enhancements for Low-Latency Networking without Application Customization in Virtual Server”, IEEE CCNC 2021.
【発明の概要】
【発明が解決しようとする課題】
【0048】
しかしながら、割込モデルとポーリングモデルによるパケット転送のいずれについても下記課題がある。
割込モデルは、ＨＷからイベント（ハードウェア割込）を受けたkernelがパケット加工を行うためのソフトウェア割込処理によってパケット転送を行う。このため、割込モデルは、割込（ソフトウェア割込）処理によりパケット転送を行うので、他の割込との競合や、割込先ＣＰＵがより優先度の高いプロセスに使用されていると待ち合わせが発生し、パケット転送の遅延が大きくなるといった課題がある。この場合、割込処理が混雑すると、更に待ち合わせ遅延は大きくなる。
例えば、図９に示すように、割込モデルによるパケット転送は、割込処理（図９の符号ａ，ｂ参照）によりパケットの転送を行うため、割込処理の待ち合わせが発生し、パケット転送の遅延が大きくなる。
割込モデルは、ＨＷからイベント（ハードウェア割込）を受けたkernelがパケット加工を行うためのソフトウェア割込処理によってパケット転送を行う。このため、割込モデルは、割込（ソフトウェア割込）処理によりパケット転送を行うので、他の割込との競合や、割込先ＣＰＵがより優先度の高いプロセスに使用されていると待ち合わせが発生し、パケット転送の遅延が大きくなるといった課題がある。この場合、割込処理が混雑すると、更に待ち合わせ遅延は大きくなる。
例えば、図９に示すように、割込モデルによるパケット転送は、割込処理（図９の符号ａ，ｂ参照）によりパケットの転送を行うため、割込処理の待ち合わせが発生し、パケット転送の遅延が大きくなる。
【0049】
割込モデルにおいて、遅延が発生するメカニズムについて補足する。
一般的なkernelは、パケット転送処理はハードウェア割込処理の後、ソフトウェア割込処理にて伝達される。
パケット転送処理のソフトウェア割込が発生した際に、下記条件（１）～（３）においては、前記ソフトウェア割込処理を即時に実行することができない。このため、ksoftirqd（ＣＰＵ毎のカーネルスレッドであり、ソフトウェア割込の負荷が高くなったときに実行される）等のスケジューラにより調停され、割込処理がスケジューリングされることにより、ｍｓオーダの待ち合わせが発生する。
（１）他のハードウェア割込処理と競合した場合
（２）他のソフトウェア割込処理と競合した場合
（３）優先度の高い他プロセスやkernel thread（migration thread等）、割込先ＣＰＵが使用されている場合
上記条件では、前記ソフトウェア割込処理を即時に実行することができない。
一般的なkernelは、パケット転送処理はハードウェア割込処理の後、ソフトウェア割込処理にて伝達される。
パケット転送処理のソフトウェア割込が発生した際に、下記条件（１）～（３）においては、前記ソフトウェア割込処理を即時に実行することができない。このため、ksoftirqd（ＣＰＵ毎のカーネルスレッドであり、ソフトウェア割込の負荷が高くなったときに実行される）等のスケジューラにより調停され、割込処理がスケジューリングされることにより、ｍｓオーダの待ち合わせが発生する。
（１）他のハードウェア割込処理と競合した場合
（２）他のソフトウェア割込処理と競合した場合
（３）優先度の高い他プロセスやkernel thread（migration thread等）、割込先ＣＰＵが使用されている場合
上記条件では、前記ソフトウェア割込処理を即時に実行することができない。
【0050】
また、New API(NAPI)によるパケット処理についても同様に、図１２の破線囲みｐに示すように、割込処理（softIRQ）の競合に起因し、ｍｓオーダのＮＷ遅延が発生する。
【0051】
一方、ポーリングモデルは、ＣＰＵを占有して通信キューをポーリングし、パケット到着時に即時刈取る。ポーリングモデルは、転送遅延を小さくすることが可能であるものの、ＡＰＬにポーリング機能を具備させる必要が生じるので、ＡＰＬに改変が必要である。
例えば、図１０に示すように、ポーリングモデルによるパケット転送は、パケット処理ＡＰＬ１にGuest OS５０区間においてポーリングを行う機能部であるdpdk(PMD)７２を具備させる必要があり、パケット処理ＡＰＬ１の改変が必要となる。
例えば、図１０に示すように、ポーリングモデルによるパケット転送は、パケット処理ＡＰＬ１にGuest OS５０区間においてポーリングを行う機能部であるdpdk(PMD)７２を具備させる必要があり、パケット処理ＡＰＬ１の改変が必要となる。
【0052】
また、非特許文献３に記載のＫＢＰは、kernel内でpollingモデルによりパケット到着を常時監視することで、softIRQを抑止し、低遅延なパケット処理を実現することができる。
しかし、パケット到着を常時監視するkernel threadがＣＰＵコアを専有し、常にＣＰＵタイムを使用するため、消費電力が高くなる課題がある。図１３および図１４を参照して、ワークロードとＣＰＵ使用率の関係について説明する。
しかし、パケット到着を常時監視するkernel threadがＣＰＵコアを専有し、常にＣＰＵタイムを使用するため、消費電力が高くなる課題がある。図１３および図１４を参照して、ワークロードとＣＰＵ使用率の関係について説明する。
【0053】
【0054】
図１４は、非特許文献３に記載のＫＢＰにおける、busy poll threadが使用するＣＰＵ使用率を示す図である。
図１４に示すように、ＫＢＰでは、kernel threadはbusy pollを行うために、ＣＰＵコアを専有する。図１３に示す間欠的なパケット受信であっても、ＫＢＰでは、パケット到着有無に関わらず常にＣＰＵを使用するため、消費電力が大きくなる課題がある。
図１４に示すように、ＫＢＰでは、kernel threadはbusy pollを行うために、ＣＰＵコアを専有する。図１３に示す間欠的なパケット受信であっても、ＫＢＰでは、パケット到着有無に関わらず常にＣＰＵを使用するため、消費電力が大きくなる課題がある。
【0055】
このような背景を鑑みて本発明がなされたのであり、本発明は、消費電力の低減を図りつつ、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことを課題とする。
【課題を解決するための手段】
【0056】
前記した課題を解決するため、サーバ内遅延制御装置であって、OSが、カーネルと、前記OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を有し、前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、前記サーバ内遅延制御装置は、前記ポールリストを監視するパケット到着監視部と、パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、を備えることを特徴とするサーバ内遅延制御装置とした。
【発明の効果】
【0057】
本発明によれば、消費電力の低減を図りつつ、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
【図面の簡単な説明】
【0058】
【図1】本発明の実施形態に係るサーバ内遅延制御システムの概略構成図である。
【図2】本発明の実施形態に係るサーバ内遅延制御システムのNew API(NAPI)によるＲｘ側パケット処理の詳細を説明する図である。
【図3】本発明の実施形態に係るサーバ内遅延制御システムのpolling thread動作例を示す図である。
【図4】本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のＲｘ側動作および省電力化のための管理処理を示すフローチャートである。
【図5】本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置の省電力化のためのCPU周波数/CPU idle設定処理を示すフローチャートである。
【図6】本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。
【図7】汎用Linux kernelおよびＶＭ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システムを適用した例を示す図である。
【図8】コンテナ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システムを適用した例を示す図である。
【図9】汎用Linux kernelおよびＶＭ構成のサーバ仮想化環境における、割込モデルによるパケット転送を説明する図である。
【図10】OvS-DPDKの構成における、ポーリングモデルによるパケット転送を説明する図である。
【図11】Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理の概略図である。
【図13】映像（３０ＦＰＳ）のデータ転送例を示す図である。
【図14】非特許文献３に記載のＫＢＰにおける、busy poll threadが使用するＣＰＵ使用率を示す図である。
【発明を実施するための形態】
【0059】
以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるサーバ内遅延制御システム等について説明する。
［概要］
図１は、本発明の実施形態に係るサーバ内遅延制御システムの概略構成図である。本実施形態は、Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理に適用した例である。図１１と同一構成部分には、同一符号を付している。
図１に示すように、サーバ内遅延制御システム１０００は、OS７０（例えば、Host OS）を備えるサーバ上で、ユーザが使用可能なuser space６０に配置されたパケット処理ＡＰＬ１を実行し、OS７０に接続されたＨＷ１０のＮＩＣ１１とパケット処理ＡＰＬ１との間でパケット転送を行う。
［概要］
図１は、本発明の実施形態に係るサーバ内遅延制御システムの概略構成図である。本実施形態は、Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理に適用した例である。図１１と同一構成部分には、同一符号を付している。
図１に示すように、サーバ内遅延制御システム１０００は、OS７０（例えば、Host OS）を備えるサーバ上で、ユーザが使用可能なuser space６０に配置されたパケット処理ＡＰＬ１を実行し、OS７０に接続されたＨＷ１０のＮＩＣ１１とパケット処理ＡＰＬ１との間でパケット転送を行う。
【0060】
OS７０は、kernel１７１、Ring Buffer７２、およびDriver７３を有し、kernel１７１は、サーバ内遅延制御装置１００およびプロトコル処理部７４を有する。
【0061】
本実施形態では、kernel１７１が、サーバ内遅延制御装置１００を備える関係で、図１１に示すkernel７１と区別して新たな番号を付している。kernel１７１は、サーバ内遅延制御装置１００が設置されている以外は、図１１に示すkernel７１と同一機能である。ただし、kernel１７１は、livepatch（後記）を用いることで、既存のkernel７１（図１１参照）を改造（新しくビルド）することなく、実現が可能である。
【0062】
kernel１７１は、OS７０（例えば、Host OS）の基幹部分の機能であり、ハードウェアの監視やプログラムの実行状態をプロセス単位で管理する。ここでは、kernel１７１は、パケット処理ＡＰＬ１からの要求に応えるとともに、ＨＷ１０からの要求をパケット処理ＡＰＬ１に伝える。kernel１７１は、パケット処理ＡＰＬ１からの要求に対して、システムコールを介することで処理する。
kernel１７１は、Socket７５を介して、パケット処理ＡＰＬ１へパケットを送信する。Kernel７１は、Socket７５を介してパケット処理ＡＰＬ１からパケットを受信する。
kernel１７１は、Socket７５を介して、パケット処理ＡＰＬ１へパケットを送信する。Kernel７１は、Socket７５を介してパケット処理ＡＰＬ１からパケットを受信する。
【0063】
Ring Buffer７２は、サーバの中にあるメモリ空間においてkernel１７１が管理する。Ring Buffer７２は、kernel１７１が出力するメッセージをログとして格納する一定サイズのバッファであり、上限サイズを超過すると先頭から上書きされる。
【0064】
Driver７３は、kernel１７１でハードウェアの監視を行うためデバイスドライバである。
【0065】
プロトコル処理部７４は、ＯＳＩ参照モデルが定義するＬ２／Ｌ３／Ｌ４のプロトコル処理を行う。
【0066】
Socket７５は、kernel１７１がプロセス間通信を行うためのインターフェイスである。Socket７５は、ソケットバッファを有し、データのコピー処理を頻繁に発生させない。
【0067】
<サーバ内遅延制御装置>
サーバ内遅延制御装置１００は、パケット到着監視部１１０と、パケット刈取部１２０と、sleep管理部１３０と、CPU周波数/CPU idle設定部１４０（CPU周波数設定部，ＣＰＵアイドル設定部）と、を備える。
サーバ内遅延制御装置１００は、パケット到着監視部１１０と、パケット刈取部１２０と、sleep管理部１３０と、CPU周波数/CPU idle設定部１４０（CPU周波数設定部，ＣＰＵアイドル設定部）と、を備える。
【0068】
パケット到着監視部１１０は、パケットが到着していないかを監視するためのthreadである。パケット到着監視部１１０は、poll_list１８６（図２参照）を監視（polling）する。
【0069】
パケット到着監視部１１０は、poll_list１８６からRing_Buffer７２（図２参照）にパケットが存在するポインタ情報と、net_device情報とを取得し、パケット刈取部１２０へ当該情報（ポインタ情報およびnet_device情報）を伝達する。ここで、poll_list１８６に複数パケット情報が存在する場合は、複数分当該情報を伝達する。
【0070】
パケット刈取部１２０は、パケットが到着している場合は、Ring Buffer７２に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをRing Buffer７２から削除する刈取りを実行する（以下、単にRing Buffer７２からパケットを刈取るという場合がある）。パケット刈取部１２０は、受信した情報をもとにRing_Buffer７２からパケットを取り出し、netif_receive_skb８７へパケットを伝達する。
【0071】
sleep管理部１３０は、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はこのスレッド（polling thread）のハードウェア割込（hardIRQ）によりスリープ解除を行う（詳細後記）。
【0072】
CPU周波数/CPU idle設定部１４０は、スリープ中に、スレッド（polling thread）が使用するＣＰＵコアのＣＰＵ動作周波数を低く設定する。CPU周波数/CPU idle設定部１４０は、スリープ中に、このスレッド（polling thread）が使用するＣＰＵコアのＣＰＵアイドル（CPU idle）状態を省電力モードに設定する（詳細後記）。
【0073】
図２は、図１のサーバ内遅延制御システム１０００のNew API(NAPI)によるＲｘ側パケット処理の詳細を説明する図である。図１および図１２と同一構成部分には、同一符号を付している。
<Device driver>
図２に示すように、Device driverには、ネットワークインターフェースカードであるNIC１１、NIC１１の処理要求の発生によって呼び出され要求された処理（ハードウェア割込）を実行するハンドラであるhardIRQ８１、およびソフトウェア割込の処理機能部であるnetif_rx１８２が配置される。
<Device driver>
図２に示すように、Device driverには、ネットワークインターフェースカードであるNIC１１、NIC１１の処理要求の発生によって呼び出され要求された処理（ハードウェア割込）を実行するハンドラであるhardIRQ８１、およびソフトウェア割込の処理機能部であるnetif_rx１８２が配置される。
【0074】
<Networking layer>
Networking layerには、NIC１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を登録するpoll_list１８６、パケット到着監視部１１０、キューを刈取ったパケットを、割込の発生しないソケット通信のためのsk_buff構造体（kernel１７１が、パケットの状態を示す構造体）を作成するnetif_receive_skb８７、およびRing Buffer７２が配置される。
Networking layerには、NIC１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を登録するpoll_list１８６、パケット到着監視部１１０、キューを刈取ったパケットを、割込の発生しないソケット通信のためのsk_buff構造体（kernel１７１が、パケットの状態を示す構造体）を作成するnetif_receive_skb８７、およびRing Buffer７２が配置される。
【0075】
<Protocol layer>
Protocol layerには、パケット処理機能部であるip_rcv８８、arp_rcv８９等が配置される。なお、プロトコル処理は、ip_rcv８８、arp_rcv８９以外にもある。
Protocol layerには、パケット処理機能部であるip_rcv８８、arp_rcv８９等が配置される。なお、プロトコル処理は、ip_rcv８８、arp_rcv８９以外にもある。
【0076】
上記netif_rx１８２、netif_receive_skb８７、ip_rcv８８、およびarp_rcv８９は、Kernel１７１の中でパケット処理のために呼ばれるプログラムの部品（関数の名称）である。
【0077】
以下、サーバ内遅延制御システム１０００の動作を説明する。
［本発明によるＲｘ側パケット処理動作］
図２の矢印（符号）ｄ～ｇ，ｋ～ｏは、Ｒｘ側パケット処理の流れを示している。
NIC１１が、対向装置からフレーム内にパケット（またはフレーム）を受信すると、ＤＭＡ転送によりＣＰＵを使用せずに、Ring Buffer７２へ到着したパケットをコピーする（図２の符号ｄ参照）。このRing Buffer７２は、サーバ中のメモリ空間で、Kernel１７１（図１参照）が管理している。
［本発明によるＲｘ側パケット処理動作］
図２の矢印（符号）ｄ～ｇ，ｋ～ｏは、Ｒｘ側パケット処理の流れを示している。
NIC１１が、対向装置からフレーム内にパケット（またはフレーム）を受信すると、ＤＭＡ転送によりＣＰＵを使用せずに、Ring Buffer７２へ到着したパケットをコピーする（図２の符号ｄ参照）。このRing Buffer７２は、サーバ中のメモリ空間で、Kernel１７１（図１参照）が管理している。
【0078】
NIC１１は、パケットが到着すると、ハードウェア割込（hardIRQ）をhardIRQ８１（ハンドラ）に立ち上げ（図２の符号ｅ参照）、netif_rx１８２が下記の処理を実行することで、Kernel１７１は、当該パケットを認知する。
【0079】
netif_rx１８２は、hardwire８１（ハンドラ）が立ち上がると（図２の符号ｆ参照）、poll_list１８６に、ハードウェア割込（hardIRQ）の中身の情報の１つである、ＮＩＣ１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を保存して、キューの刈取り情報を登録する（図２の符号ｇ参照）。具体的には、netif_rx１８２は、Ring Buffer７２にパケットが詰め込まれたことを受けて、NIC１１のドライバを使って、以後のキューの刈取りをpoll_list１８６に登録する（図２の符号ｇ参照）。これにより、poll_list１８６には、Ring Buffer７２にパケットが詰め込まれたことによる、キューの刈取りが登録される。
【0080】
netif_rx１８２は、poll_list１８６にnet_deviceを登録するが、図１２のnetif_rx８２とは異なり、ソフトウェア割込（softIRQ）のスケジューリングは行わない。すなわち、netif_rx１８２は、ソフトウェア割込（softIRQ）のスケジューリングは行わない点で、図１２のnetif_rx８２とは異なる。
【0081】
また、netif_rx１８２は、sleepしているpolling threadを呼び起こすsleep解除を行う（図２の符号ｐ参照）。本実施形態は、非特許文献３に記載のＫＢＰに対し、このpolling threadの呼び起こし処理（sleep解除）を追加している。
ここまでで、図２の<Device driver>におけるハードウェア割込の処理は停止する。
ここまでで、図２の<Device driver>におけるハードウェア割込の処理は停止する。
【0082】
本実施形態では、図１２に示す<Networking layer>において、softIRQ８３およびdo_softirq８４が削除され、これに伴い、図１２に示すnetif_rx８２が、softIRQ８３（ハンドラ）を立ち上げる通知（図１２の符号ｈ参照）も行わない。
【0083】
本実施形態では、サーバ内遅延制御システム１０００は、図１２に示すsoftIRQ８３およびdo_softirq８４を削除し、代わりに図２に示す<Networking layer>のサーバの中にあるメモリ空間に、サーバ内遅延制御装置１００を設ける。
【0084】
図２に示す<Networking layer>において、サーバ内遅延制御装置１００のパケット到着監視部１１０は、poll_list１８６を監視（polling）し（図２の符号ｋ参照）、パケット到着有無を確認する。
【0085】
パケット到着監視部１１０は、poll_list１８６から、Ring_Buffer７２にパケットが存在するポインタ情報と、net_device情報とを取得し、パケット刈取部１２０へ当該情報（ポインタ情報およびnet_device情報）を伝達する（図２の符号ｑ参照）。ここで、poll_list１８６に複数パケット情報が存在する場合は、複数分当該情報を伝達する。
【0086】
サーバ内遅延制御装置１００のパケット刈取部１２０は、パケットが到着している場合は、Ring Buffer７２からパケットを刈取る（図２の符号ｌ参照）。
パケット刈取部１２０は、受信した情報をもとにRing_Buffer７２からパケットを取り出し、netif_receive_skb８７へパケットを伝達する（図２の符号ｍ参照）。
パケット刈取部１２０は、受信した情報をもとにRing_Buffer７２からパケットを取り出し、netif_receive_skb８７へパケットを伝達する（図２の符号ｍ参照）。
【0087】
このように、サーバ内遅延制御システム１０００は、ＮＷ遅延発生の主要因であるパケット処理のsoftIRQを停止し、サーバ内遅延制御装置１００のパケット到着監視部１１０がパケット到着を監視するpolling threadを実行する。そして、パケット刈取部１２０が、パケット到着時に、pollingモデル（softIRQなし）によりパケット処理を行う。
【0088】
すなわち、サーバ内遅延制御装置１００におけるpolling threadは、kernel threadとして動作し、pollingモードでパケット到着を監視する。パケット到着監視部１１０は、poll_list１８６を監視する。パケット刈取部１２０は、パケット到着時にRing Buffer７２からパケットを取り出し、netif_receive_skb８７へパケットを転送する。
【0089】
パケット到着時は、ハード割込ハンドラでpolling threadを起こすことで、softIRQ競合を回避して、即時にパケット転送処理が可能となる。言い換えれば、kernel threadとしてパケット到着監視機能を待機させておき、ハード割込で起こすことで、NAPI等のソフト割込によるパケット転送処理よりも低遅延化が可能になる。
【0090】
パケット到着を監視するkernel threadは、パケット到着がない間はsleep可能とする。
上記polling threadは、パケット到着有無に応じてsleepし、パケット到着時はhardIRQ８１によりsleep解除を行う。具体的には、サーバ内遅延制御装置１００のsleep管理部１３０は、パケット到着有無に応じて、すなわち一定期間パケットの到着がないと、polling threadをsleepさせる。sleep管理部１３０は、パケット到着時はhardIRQ８１によりsleep解除を行う。これにより、softIRQ競合を回避して、低遅延化を実現する。
上記polling threadは、パケット到着有無に応じてsleepし、パケット到着時はhardIRQ８１によりsleep解除を行う。具体的には、サーバ内遅延制御装置１００のsleep管理部１３０は、パケット到着有無に応じて、すなわち一定期間パケットの到着がないと、polling threadをsleepさせる。sleep管理部１３０は、パケット到着時はhardIRQ８１によりsleep解除を行う。これにより、softIRQ競合を回避して、低遅延化を実現する。
【0091】
サーバ内遅延制御装置１００のCPU周波数/CPU idle設定部１４０は、パケット到着有無に応じてＣＰＵ動作周波数やidle設定を変更する。具体的には、CPU周波数/CPU idle設定部１４０は、sleep時はＣＰＵ周波数を下げ、再度起動時はＣＰＵ周波数を高める（ＣＰＵ動作周波数をもとに戻す）。また、CPU周波数/CPU idle設定部１４０は、sleep時はCPU idle設定を省電力に変更する。sleep時にＣＰＵ動作周波数を低く変更する、また、CPU idle設定を省電力に変更することで省電力化も達成する。
【0092】
netif_receive_skb８７は、sk_buff構造体を作り、パケットの内容を解析し、タイプ毎に後段のプロトコル処理部７４（図１１参照）へ処理をまわす。すなわち、netif_receive_skb８７は、パケットの中身を解析し、パケットの中身に応じて処理をする場合には、<Protocol layer>のip_rcv８８に処理を回し、また、例えばＬ２であればarp_rcv８９に処理をまわす。
【0093】
図３は、サーバ内遅延制御装置１００のpolling thread動作例を示す図である。縦軸は、polling threadが使用するＣＰＵコアのＣＰＵ使用率[％]を示し、横軸は、時間を示す。なお、図３は、図１３に示す間欠的にパケットが受信される映像（３０ＦＰＳ）のデータ転送例に対応するパケット到着によるpolling thread動作例を示している。
図３に示すように、サーバ内遅延制御装置１００のsleep管理部１３０は、一定期間パケットの到着がない場合（より詳細には、あるパケット到着してから、保守・運用者があらかじめ定めた固定値(一定期間)を経過しても次のパケット到着がない場合）に、polling threadをsleepさせる（図３の符号ｓ参照）。そして、sleep管理部１３０は、パケット到着のhardIRQ８１でpolling threadを起動させる（図３の符号ｔ参照）。
なお、sleep 時には、kernelthreadがＣＰＵコアを専有していないため、polling threadが使用する以外にも、システム安定動作のためのタイマの割込みが該当ＣＰＵコアに入ったり、エラー処理等のためのmigration threadが該当ＣＰＵコアに入ったりすることで、polling threadが使用するＣＰＵコアのＣＰＵ使用率が変動する場合がある（図３の符号ｕ参照）。
図３に示すように、サーバ内遅延制御装置１００のsleep管理部１３０は、一定期間パケットの到着がない場合（より詳細には、あるパケット到着してから、保守・運用者があらかじめ定めた固定値(一定期間)を経過しても次のパケット到着がない場合）に、polling threadをsleepさせる（図３の符号ｓ参照）。そして、sleep管理部１３０は、パケット到着のhardIRQ８１でpolling threadを起動させる（図３の符号ｔ参照）。
なお、sleep 時には、kernelthreadがＣＰＵコアを専有していないため、polling threadが使用する以外にも、システム安定動作のためのタイマの割込みが該当ＣＰＵコアに入ったり、エラー処理等のためのmigration threadが該当ＣＰＵコアに入ったりすることで、polling threadが使用するＣＰＵコアのＣＰＵ使用率が変動する場合がある（図３の符号ｕ参照）。
【0094】
［live patchによる登録動作］
次に、live patchによる登録動作について説明する。
サーバ内遅延制御システム１０００（図１参照）は、図１に示すOS７０のkernel１７１が、サーバ内遅延制御装置１００を備える。kernel１７１は、livepatchを用いることで、既存のkernel７１（図１１参照）を改造（新しくビルド）することなく、実現が可能になる。以下、kernel１７１に適用されるlivepatchについて説明する。
次に、live patchによる登録動作について説明する。
サーバ内遅延制御システム１０００（図１参照）は、図１に示すOS７０のkernel１７１が、サーバ内遅延制御装置１００を備える。kernel１７１は、livepatchを用いることで、既存のkernel７１（図１１参照）を改造（新しくビルド）することなく、実現が可能になる。以下、kernel１７１に適用されるlivepatchについて説明する。
【0095】
livepatchは、Linux（登録商標）kernelに適用されるカーネルパッチ機能である。livepatchを使うことで、システムを再起動することなくカーネル空間に即座に修正を適用することができる。すなわち、
（１）livepatchは、netif_rx１８２（図２参照）のsoftIRQスケジューリング機能を抑制する。
（１）livepatchは、netif_rx１８２（図２参照）のsoftIRQスケジューリング機能を抑制する。
【0096】
（２）livepatchは、パケット到着監視を行うthread（パケット到着監視部１１０、具体的にはisol_net_rx）を起動する。起動する際、他プロセスやkernel threadにbusy poll（図２の符号ｋ参照）の邪魔をされないように、thread（パケット到着監視部１１０）は、ＣＰＵコアを専有する。そのために、当該threadはリアルタイムプロセス等の高優先設定を割り当てる。トラヒックフロー数（または、トラヒック量）に応じて、複数ＣＰＵコア上でthreadを起動し、監視するpoll_list１８６（図２参照）を割り当てる。これにより、トラヒックフロー（トラヒック量）に応じたスケールアウトが可能になる。
以降、図２に示すパケット処理の動作が実行される。
以降、図２に示すパケット処理の動作が実行される。
【0097】
［サーバ内遅延制御装置１００のＲｘ側パケット処理動作フロー］
図４は、サーバ内遅延制御装置１００（図２参照）のＲｘ側動作および省電力化のための管理処理を示すフローチャートである。図２を参照してＲｘ側動作を説明する。
polling threadが起動している間は、本動作フローをループして実行する。
ステップＳ１では、サーバ内遅延制御装置１００のパケット到着監視部１１０（図２参照）は、poll_list１８６（図２参照）をＣＰＵを専有して監視（poll）し（図２の符号ｋ参照）、パケット到着有無を確認する。
図４は、サーバ内遅延制御装置１００（図２参照）のＲｘ側動作および省電力化のための管理処理を示すフローチャートである。図２を参照してＲｘ側動作を説明する。
polling threadが起動している間は、本動作フローをループして実行する。
ステップＳ１では、サーバ内遅延制御装置１００のパケット到着監視部１１０（図２参照）は、poll_list１８６（図２参照）をＣＰＵを専有して監視（poll）し（図２の符号ｋ参照）、パケット到着有無を確認する。
【0098】
ステップＳ２では、パケット到着監視部１１０（図２参照）は、poll list１８６にパケット到着を意味するポインタ情報があるか否かを判別する。
poll list１８６にパケット到着を意味するポインタ情報がある場合（Ｓ２：Ｙｅｓ）、ステップＳ３に進み、poll list１８６にパケット到着を意味するポインタ情報がない場合（Ｓ２：Ｎｏ）、ステップＳ１の処理に戻る。
poll list１８６にパケット到着を意味するポインタ情報がある場合（Ｓ２：Ｙｅｓ）、ステップＳ３に進み、poll list１８６にパケット到着を意味するポインタ情報がない場合（Ｓ２：Ｎｏ）、ステップＳ１の処理に戻る。
【0099】
ステップＳ３では、パケット到着監視部１１０は、poll_list１８６からRing_Buffer７２（図２参照）にパケットが存在するポインタ情報と、NET_DEVICE情報とを取得し、パケット刈取部１２０へ当該情報（ポインタ情報およびNET_DEVICE情報）を伝達する（図２の符号ｑ参照）。ここで、poll_list１８６に複数パケット情報が存在する場合は、複数分当該情報を伝達する。
【0100】
ステップＳ４では、サーバ内遅延制御装置１００のパケット刈取部１２０（図２参照）は、パケットが到着している場合は、Ring Buffer７２に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをRing Buffer７２から削除する刈取りを実行する（図２の符号ｌ参照）。
【0101】
ステップＳ５では、パケット刈取部１２０は、受信した情報をもとにRing_Buffer７２からパケットを取り出し、netif_receive_skb８７へパケットを伝達する（図２の符号ｍ参照）。
【0102】
ステップＳ６では、サーバ内遅延制御装置１００のsleep管理部１３０は、一定期間を経過してもpoll_list１８６にパケットの格納がない（パケット到着がない）ことを判別する。
一定期間を経過してもpoll_list１８６にパケットの格納がない場合（Ｓ６：Ｙｅｓ）、ステップＳ７でsleep管理部１３０は、polling threadをsleepに落とす（スリープさせる）。poll_list１８６にパケットの格納がある場合（Ｓ６：Ｎｏ）、ステップＳ１に戻る。
一定期間を経過してもpoll_list１８６にパケットの格納がない場合（Ｓ６：Ｙｅｓ）、ステップＳ７でsleep管理部１３０は、polling threadをsleepに落とす（スリープさせる）。poll_list１８６にパケットの格納がある場合（Ｓ６：Ｎｏ）、ステップＳ１に戻る。
【0103】
ステップＳ８では、CPU周波数/CPU idle設定部１４０は、polling threadが使用するＣＰＵコアの動作周波数を低く設定して本フローの処理を終える。CPU周波数/CPU idle設定部１４０は、CPU idle設定もできる場合は、有効化する。
【0104】
図５は、サーバ内遅延制御装置１００の省電力化のためのCPU周波数/CPU idle設定処理を示すフローチャートである。
ステップＳ１１において、パケット到着時に起動されるハード割込処理部（図２のnetif_rx１８２）は、パケット到着時にpolling thread（図２のサーバ内遅延制御装置１００）を起動する。既にpolling threadが起動している場合はそのまま継続する。sleep管理部１３０は、パケット到着時のhardIRQによりsleep解除を行う。
ステップＳ１１において、パケット到着時に起動されるハード割込処理部（図２のnetif_rx１８２）は、パケット到着時にpolling thread（図２のサーバ内遅延制御装置１００）を起動する。既にpolling threadが起動している場合はそのまま継続する。sleep管理部１３０は、パケット到着時のhardIRQによりsleep解除を行う。
【0105】
ステップＳ１２において、CPU周波数/CPU idle設定部１４０は、polling threadが使用するＣＰＵコアの動作周波数を高く（ＣＰＵコアの動作周波数をもとに戻す）設定して本フローの処理を終了する。ここで、CPU周波数/CPU idle設定部１４０は、ＣＰＵ idel設定も変更している場合はもとに戻す。
【0106】
<付加機能>
poll_list１８６からのパケット刈り取り漏れを防ぐために、polling threadを定期的に起動し、poll_list１８６のパケット到着有無を確認してもよい。
このようにすることで、NIC１１によるパケット到着と、polling threadのsleepが同時に発生する等のタイミング問題があった場合に、poll_list１８６にパケットが残ることを防止することができる。
poll_list１８６からのパケット刈り取り漏れを防ぐために、polling threadを定期的に起動し、poll_list１８６のパケット到着有無を確認してもよい。
このようにすることで、NIC１１によるパケット到着と、polling threadのsleepが同時に発生する等のタイミング問題があった場合に、poll_list１８６にパケットが残ることを防止することができる。
【0107】
［本実施形態と既存技術との差異］
次に、本実施形態と既存技術（図１２参照）との差異について説明する。
次に、本実施形態と既存技術（図１２参照）との差異について説明する。
【0108】
<背景>
一般に、ハードウェア割込（hardIRQ）は、優先度が高く、該当ＣＰＵの処理を中断し、hardIRQの処理を最優先で処理する必要がある。このため、オーバーヘッドが大きい。そのため、hardIRQでは、パケット到着を知らせるのみとし、パケット処理は、softIRQで処理する設計思想となっている（「kernelの原則」という）。ここで、softIRQは、他のsoftIRQと競合し、待たされる事象が発生する（遅延発生の要因となる）。
従来技術が割込モデルにしている理由は、かつてはＣＰＵリソースが限られていた（または、Raspberry PiのようなSingle board ComputerのようにＣＰＵコアが少ないデバイスでも動作させる）ために、１つのＣＰＵコアを他の処理と共有して使用する設計思想になっていたためである。この場合、通常の処理や割込処理等でＣＰＵタイムを切り替えながら処理を行う。上記割込処理であっても、softIRQは競合することになり、待ち時間が発生する。
なお、softIRQのスケジューリングを行うスケジューラであるksoftirqdは、softIRQの種別に応じて優先度を付与する機能を具備しておらず、この競合による遅延発生は抑制できない。
一般に、ハードウェア割込（hardIRQ）は、優先度が高く、該当ＣＰＵの処理を中断し、hardIRQの処理を最優先で処理する必要がある。このため、オーバーヘッドが大きい。そのため、hardIRQでは、パケット到着を知らせるのみとし、パケット処理は、softIRQで処理する設計思想となっている（「kernelの原則」という）。ここで、softIRQは、他のsoftIRQと競合し、待たされる事象が発生する（遅延発生の要因となる）。
従来技術が割込モデルにしている理由は、かつてはＣＰＵリソースが限られていた（または、Raspberry PiのようなSingle board ComputerのようにＣＰＵコアが少ないデバイスでも動作させる）ために、１つのＣＰＵコアを他の処理と共有して使用する設計思想になっていたためである。この場合、通常の処理や割込処理等でＣＰＵタイムを切り替えながら処理を行う。上記割込処理であっても、softIRQは競合することになり、待ち時間が発生する。
なお、softIRQのスケジューリングを行うスケジューラであるksoftirqdは、softIRQの種別に応じて優先度を付与する機能を具備しておらず、この競合による遅延発生は抑制できない。
【0109】
<既存技術（図１２参照）>
図１２に示すように、kernel７１（図１１）は、NIC１１からのパケット到着の知らせを、hardIRQ８１により受け取り（図１２の符号ｈ参照）、パケット処理のためのsoftIRQ８３をスケジューリングする（図１２の破線囲みｐ参照）。この際、他の割込処理と競合すると待合せが発生し、ｍｓオーダのＮＷ遅延が発生する。
図１２に示すように、kernel７１（図１１）は、NIC１１からのパケット到着の知らせを、hardIRQ８１により受け取り（図１２の符号ｈ参照）、パケット処理のためのsoftIRQ８３をスケジューリングする（図１２の破線囲みｐ参照）。この際、他の割込処理と競合すると待合せが発生し、ｍｓオーダのＮＷ遅延が発生する。
【0110】
<サーバ内遅延制御システム１０００（図２参照）>
・パケット到着監視部１１０およびパケット刈取部１２０の実装
図２に示すように、サーバ内遅延制御システム１０００は、<Networking layer>において、netif_rx１８２は、poll_list１８６にnet_deviceを登録するが、既存技術（図１２参照）のnetif_rx８２とは異なり、ソフトウェア割込（softIRQ）のスケジューリングは行わない（「変更点１」）。
・パケット到着監視部１１０およびパケット刈取部１２０の実装
図２に示すように、サーバ内遅延制御システム１０００は、<Networking layer>において、netif_rx１８２は、poll_list１８６にnet_deviceを登録するが、既存技術（図１２参照）のnetif_rx８２とは異なり、ソフトウェア割込（softIRQ）のスケジューリングは行わない（「変更点１」）。
【0111】
図２に示すように、サーバ内遅延制御システム１０００は、<Networking layer>のサーバの中にあるメモリ空間に、サーバ内遅延制御装置１００を設ける（「変更点２」）。
サーバ内遅延制御装置１００のパケット到着監視部１１０は、poll_list１８６を常に監視（busy poll）し（図２の符号ｋ参照）、パケット到着有無を確認する。
サーバ内遅延制御装置１００のパケット到着監視部１１０は、poll_list１８６を常に監視（busy poll）し（図２の符号ｋ参照）、パケット到着有無を確認する。
【0112】
パケット到着監視部１１０は、poll_list１８６からRing_Buffer７２にパケットが存在するポインタ情報と、NET_DEVICE情報とを取得し、パケット刈取部１２０へ当該情報（ポインタ情報およびNET_DEVICE情報）を伝達する（図２の符号ｑ参照）。
【0113】
サーバ内遅延制御装置１００のパケット刈取部１２０は、パケットが到着している場合は、Ring Buffer７２からパケットを刈取る（図２の符号ｌ参照）。
【0114】
パケット刈取部１２０は、受信した情報をもとにRing_Buffer７２からパケットを取り出し、netif_receive_skb８７へパケットを伝達する（図２の符号ｍ参照）。
【0115】
上記「変更点１」による作用効果は、下記の通りである。
まず、本実施形態では、ハードウェア割込（hardIRQ）によるパケット到着の通知については、NAPIを踏襲する。softIRQは、ＣＰＵリソースを有効活用する点では便利であるが、パケットの即時転送の観点では適さない。そのため、本実施形態では、softIRQの機能を停止し、kernelの中でpollingモデルを実現する点が新しい。具体的には、図２に示すnetif_rx１８２が、図１２に示すnetif_rx８２のように、softIRQ８３（ハンドラ）を立ち上げる通知（図１２の符号ｈ参照）を行わないことに示されている。
まず、本実施形態では、ハードウェア割込（hardIRQ）によるパケット到着の通知については、NAPIを踏襲する。softIRQは、ＣＰＵリソースを有効活用する点では便利であるが、パケットの即時転送の観点では適さない。そのため、本実施形態では、softIRQの機能を停止し、kernelの中でpollingモデルを実現する点が新しい。具体的には、図２に示すnetif_rx１８２が、図１２に示すnetif_rx８２のように、softIRQ８３（ハンドラ）を立ち上げる通知（図１２の符号ｈ参照）を行わないことに示されている。
【0116】
なお、pollingモデルについては、ユーザスペースからpollingを行うＤＰＤＫが既存技術としてある（図１０参照）。しかしながら、ＤＰＤＫは、ＡＰＬからpollingを行うため、ＡＰＬに改変が必要である。
【0117】
上記「変更点２」による作用効果は、下記の通りである。
本実施形態は、図１に示すkernel１７１の中でpolling専用のthread（サーバ内遅延制御装置１００のパケット到着監視部１１０）を起動し、サーバ内遅延制御装置１００のパケット刈取部１２０が、パケット到着時に、pollingモデル（softIRQなし）によりパケット処理を行う。これにより、ＡＰＬ改変不要になる、換言すれば、既存のPOSIX socket APIを利用することが可能になる。
本実施形態は、図１に示すkernel１７１の中でpolling専用のthread（サーバ内遅延制御装置１００のパケット到着監視部１１０）を起動し、サーバ内遅延制御装置１００のパケット刈取部１２０が、パケット到着時に、pollingモデル（softIRQなし）によりパケット処理を行う。これにより、ＡＰＬ改変不要になる、換言すれば、既存のPOSIX socket APIを利用することが可能になる。
【0118】
また、前述threadが他のsoftIRQなどにＣＰＵタイムを奪われないようにするために、上記［live patchによる登録］で述べたように、thread起動時にＣＰＵコアを専有し、高優先設定を行うことで、pollingの邪魔をさせない。
【0119】
以上、サーバ内遅延制御装置１００は、パケット到着監視部１１０およびパケット刈取部１２０を備えることで、低遅延なパケット転送を実現する。すなわち、パケット到着時のソフトウェア割込（softIRQ）を停止し、kernel内でpollingモデルを実現する。パケット到着を監視するkernel threadを新たに作り、poll_list１８６へのパケット到着を監視する。これにより、パケット到着時は、待合せなく即時に刈り取られるため、低遅延なパケット処理を実現できる。
【0120】
・sleep管理部１３０およびCPU周波数/CPU idle設定部１４０の実装
サーバ内遅延制御装置１００は、さらに、sleep管理部１３０およびCPU周波数/CPU idle設定部１４０を備えることで、上述した低遅延なパケット処理に加え、省電力を図る。すなわち、パケット到着を監視するkernel threadは、パケット到着がない間はsleep可能とする。sleep中のthreadは、パケット到着時のhardIRQハンドラで起こすことで、softIRQ競合を回避しながら即時起動する。ＣＰＵ動作周波数やCPU idle状態を、上記sleepに合わせて調整することで更に低消費電力化を図る。
サーバ内遅延制御装置１００は、さらに、sleep管理部１３０およびCPU周波数/CPU idle設定部１４０を備えることで、上述した低遅延なパケット処理に加え、省電力を図る。すなわち、パケット到着を監視するkernel threadは、パケット到着がない間はsleep可能とする。sleep中のthreadは、パケット到着時のhardIRQハンドラで起こすことで、softIRQ競合を回避しながら即時起動する。ＣＰＵ動作周波数やCPU idle状態を、上記sleepに合わせて調整することで更に低消費電力化を図る。
【0121】
< sleep管理部１３０およびCPU周波数/CPU idle設定部１４０の詳細動作（図２参照）>
図２に示すnetif_rx１８２は、パケット到着時にpolling threadがsleepしている場合に起動する（図２の符号ｐ参照）。既にpolling threadが起動している場合は、特に何も動作せずにハードウェア割込ハンドラを終了する。
図２に示すnetif_rx１８２は、パケット到着時にpolling threadがsleepしている場合に起動する（図２の符号ｐ参照）。既にpolling threadが起動している場合は、特に何も動作せずにハードウェア割込ハンドラを終了する。
【0122】
ハードウェア割込ハンドラにより起動されたpolling thread（サーバ内遅延制御装置１００）のCPU周波数/CPU idle設定部１４０は、polling threadが使用するＣＰＵコアのＣＰＵ動作周波数を高く（ＣＰＵコアの動作周波数をもとに戻す）設定する。
ここで、kernelは、ＣＰＵコアの動作周波数をgovernor設定により変更が可能であり、CPU周波数/CPU idle設定部１４０は、governor設定等を利用して、ＣＰＵ動作周波数を高く設定することができる。ただし、CPU idle設定は、ＣＰＵ機種依存するものである。なお、ＣＰＵコアがCPU idle設定を有効化している場合は、解除することも可能である。
ここで、kernelは、ＣＰＵコアの動作周波数をgovernor設定により変更が可能であり、CPU周波数/CPU idle設定部１４０は、governor設定等を利用して、ＣＰＵ動作周波数を高く設定することができる。ただし、CPU idle設定は、ＣＰＵ機種依存するものである。なお、ＣＰＵコアがCPU idle設定を有効化している場合は、解除することも可能である。
【0123】
パケット到着監視部１１０は、poll_list１８６にパケットのポインタが格納されているかを確認する。ポインタが格納されている場合は、パケット刈取部１２０へ、該当ポインタ情報とdevice driver情報を伝達する。
【0124】
polling threadが起動している間は、ここまでの動作をループして実行する。また、このループによるパケット到着確認間隔を、パケット到着の頻度に応じて、増減させてもよい。例えば、単一時間Ｔ当たりのパケット到着数Ｎをカウントし、確認頻度をＮ／Ｔ[回/秒]以上に設定する等である。この増減により、ＣＰＵ使用率をさらに低減することが可能になる。
【0125】
パケット刈取部１２０は、受信したポインタ情報とdevice driver情報をもとに、Ring Buffer７２からパケットを刈り取る。その後、図２に示すnetif_receive_skb８７（パケット構造体管理部）へ該当データを伝達する。
netif_receive_skb８７は、受信したデータからパケット処理に必要な構造体（sk_buff構造体等）を作成する。なお、以降は、kernelによるプロトコル処理へつづく。
netif_receive_skb８７は、受信したデータからパケット処理に必要な構造体（sk_buff構造体等）を作成する。なお、以降は、kernelによるプロトコル処理へつづく。
【0126】
sleep管理部１３０は、上記poll_list１８６のパケットのポインタ確認において、poll_list１８６のパケット到着有無情報をパケット到着監視部１１０から受け取る。sleep管理部１３０は、このパケット到着有無情報をもと、一定期間にパケット到着がないと判断した場合は、CPU周波数/CPU idle設定部１４０へパケット到着が一定期間ない旨を伝達する。
【0127】
CPU周波数/CPU idle設定部１４０は、パケット到着が一定期間ない場合に、sleep管理部１３０からの通知を受け、polling threadが使用するＣＰＵコアのＣＰＵ動作周波数を低く設定する。この時、CPU周波数/CPU idle設定部１４０は、CPU idle設定を有効化できる場合は、有効化する（ただしＣＰＵ機種依存がある）。
【0128】
sleep管理部１３０は、CPU周波数/CPU idle設定部１４０による設定が終了した後に、polling threadをsleep状態に落とす（スリープさせる）。
なお、ＣＰＵ周波数設定を低くする処理と、このsleep状態に落とす処理は、同時に実行してもよい。また、パケット転送処理が完了していることを確認してからsleepしてもよい。
なお、ＣＰＵ周波数設定を低くする処理と、このsleep状態に落とす処理は、同時に実行してもよい。また、パケット転送処理が完了していることを確認してからsleepしてもよい。
【0129】
［ハードウェア構成］
本実施形態に係るサーバ内遅延制御装置１００は、例えば図６に示すような構成のコンピュータ９００によって実現される。
図６は、サーバ内遅延制御装置１００の機能を実現するコンピュータ９００の一例を示すハードウェア構成図である。
コンピュータ９００は、ＣＰＵ９０１、ＲＯＭ９０２、ＲＡＭ９０３、ＨＤＤ９０４、通信インターフェイス（Ｉ／Ｆ：Interface）９０６、入出力インターフェイス（Ｉ／Ｆ）９０５、およびメディアインターフェイス（Ｉ／Ｆ）９０７を有する。
本実施形態に係るサーバ内遅延制御装置１００は、例えば図６に示すような構成のコンピュータ９００によって実現される。
図６は、サーバ内遅延制御装置１００の機能を実現するコンピュータ９００の一例を示すハードウェア構成図である。
コンピュータ９００は、ＣＰＵ９０１、ＲＯＭ９０２、ＲＡＭ９０３、ＨＤＤ９０４、通信インターフェイス（Ｉ／Ｆ：Interface）９０６、入出力インターフェイス（Ｉ／Ｆ）９０５、およびメディアインターフェイス（Ｉ／Ｆ）９０７を有する。
【0130】
ＣＰＵ９０１は、ＲＯＭ９０２またはＨＤＤ９０４に格納されたプログラムに基づいて動作し、図１に示すサーバ内遅延制御装置１００の各部の制御を行う。ＲＯＭ９０２は、コンピュータ９００の起動時にＣＰＵ９０１によって実行されるブートプログラムや、コンピュータ９００のハードウェアに依存するプログラム等を格納する。
【0131】
ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、マウスやキーボード等の入力装置９１０、および、ディスプレイ等の出力装置９１１を制御する。ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、入力装置９１０からデータを取得するともに、生成したデータを出力装置９１１へ出力する。なお、プロセッサとしてＣＰＵ９０１とともに、ＧＰＵ（Graphics Processing Unit）等を用いてもよい。
【0132】
ＨＤＤ９０４は、ＣＰＵ９０１により実行されるプログラムおよび当該プログラムによって使用されるデータ等を記憶する。通信Ｉ／Ｆ９０６は、通信網（例えば、ＮＷ（Network）９２０）を介して他の装置からデータを受信してＣＰＵ９０１へ出力し、また、ＣＰＵ９０１が生成したデータを、通信網を介して他の装置へ送信する。
【0133】
メディアＩ／Ｆ９０７は、記録媒体９１２に格納されたプログラムまたはデータを読み取り、ＲＡＭ９０３を介してＣＰＵ９０１へ出力する。ＣＰＵ９０１は、目的の処理に係るプログラムを、メディアＩ／Ｆ９０７を介して記録媒体９１２からＲＡＭ９０３上にロードし、ロードしたプログラムを実行する。記録媒体９１２は、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto Optical disk）等の光磁気記録媒体、磁気記録媒体、導体メモリテープ媒体又は半導体メモリ等である。
【0134】
例えば、コンピュータ９００が本実施形態に係る一装置として構成されるサーバ内遅延制御装置１００として機能する場合、コンピュータ９００のＣＰＵ９０１は、ＲＡＭ９０３上にロードされたプログラムを実行することによりサーバ内遅延制御装置１００の機能を実現する。また、ＨＤＤ９０４には、ＲＡＭ９０３内のデータが記憶される。ＣＰＵ９０１は、目的の処理に係るプログラムを記録媒体９１２から読み取って実行する。この他、ＣＰＵ９０１は、他の装置から通信網（ＮＷ９２０）を介して目的の処理に係るプログラムを読み込んでもよい。
【0135】
［適用例］
サーバ内遅延制御装置１００は、Kernel内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置であればよく、ＯＳは限定されない。また、サーバ仮想化環境下であることも限定されない。したがって、サーバ内遅延制御システム１０００は、図７および図８に示す各構成に適用が可能である。
サーバ内遅延制御装置１００は、Kernel内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置であればよく、ＯＳは限定されない。また、サーバ仮想化環境下であることも限定されない。したがって、サーバ内遅延制御システム１０００は、図７および図８に示す各構成に適用が可能である。
【0136】
<ＶＭ構成への適用例>
図７は、汎用Linux kernel（登録商標）およびＶＭ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システム１０００Ａを適用した例を示す図である。図１および図９と同一構成部分には、同一符号を付している。
図７に示すように、サーバ内遅延制御システム１０００Ａは、Guest OS７０のKernel１７１内にサーバ内遅延制御装置１００が配置され、Host OS９０のKernel９１内にサーバ内遅延制御装置１００が配置される。
図７は、汎用Linux kernel（登録商標）およびＶＭ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システム１０００Ａを適用した例を示す図である。図１および図９と同一構成部分には、同一符号を付している。
図７に示すように、サーバ内遅延制御システム１０００Ａは、Guest OS７０のKernel１７１内にサーバ内遅延制御装置１００が配置され、Host OS９０のKernel９１内にサーバ内遅延制御装置１００が配置される。
【0137】
詳細には、サーバは、仮想マシンおよび仮想マシン外に形成された外部プロセスが動作可能なHost OS９０と、仮想マシン内で動作するGuest OS７０と、を備える。
HostOS９０は、Kernel９１と、HostOS９０を備えるサーバ中のメモリ空間で、Kernel９１が管理するRing Buffer２２と、NIC11からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するpoll_list１８６（図２）と、kernel threadであるvhost-netモジュール２２１と、Kernel９１により作成される仮想インターフェイスであるtapデバイス２２２と、仮想スイッチ(br)２２３と、を有する。
HostOS９０は、Kernel９１と、HostOS９０を備えるサーバ中のメモリ空間で、Kernel９１が管理するRing Buffer２２と、NIC11からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するpoll_list１８６（図２）と、kernel threadであるvhost-netモジュール２２１と、Kernel９１により作成される仮想インターフェイスであるtapデバイス２２２と、仮想スイッチ(br)２２３と、を有する。
【0138】
Kernel９１は、サーバ内遅延制御装置１００を備える。
Kernel９１は、tapデバイス２２２を介して、仮想マシン３０へパケットを伝達する。
Kernel９１は、tapデバイス２２２を介して、仮想マシン３０へパケットを伝達する。
【0139】
一方、GuestOS７０は、Kernel1７１と、GuestOS７０を備えるサーバ中のメモリ空間で、Kernel171が管理するRing Buffer52と、NIC11からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するpoll_list１８６ （図２）と、Kernel１７１が、プロセス間通信を行うためのインターフェイスであるSocket７５と、を備える。
【0140】
Kernel１７１は、サーバ内遅延制御装置１００と、刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部７４と、を備える。
Kernel１７１は、プロトコル処理部７４を介して、パケット処理ＡＰＬ１へパケットを伝達する。
Kernel１７１は、プロトコル処理部７４を介して、パケット処理ＡＰＬ１へパケットを伝達する。
【0141】
このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、HostOS９０とGuestOS７０とのいずれのOSにおいても、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
【0142】
<コンテナ構成への適用例>
図８は、コンテナ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システム１０００Ｂを適用した例を示す図である。図１と同一構成部分には、同一符号を付している。
図８に示すように、サーバ内遅延制御システム１０００Ｂは、Guest OS１８０と、OSをContainer２１０に代えた、コンテナ構成を備える。Container２１０は、vNIC（仮想NIC）２１１を有する。Guest OS１８０のKernel１８１内にサーバ内遅延制御装置１００が配置される。
図８は、コンテナ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システム１０００Ｂを適用した例を示す図である。図１と同一構成部分には、同一符号を付している。
図８に示すように、サーバ内遅延制御システム１０００Ｂは、Guest OS１８０と、OSをContainer２１０に代えた、コンテナ構成を備える。Container２１０は、vNIC（仮想NIC）２１１を有する。Guest OS１８０のKernel１８１内にサーバ内遅延制御装置１００が配置される。
【0143】
コンテナなどの仮想サーバ構成のシステムにおいて、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
【0144】
<ペアメタル構成（非仮想化構成）への適用例>
本発明は、ペアメタル構成のように非仮想化構成のシステムに適用できる。非仮想化構成のシステムにおいて、ＡＰＬ３を改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
本発明は、ペアメタル構成のように非仮想化構成のシステムに適用できる。非仮想化構成のシステムにおいて、ＡＰＬ３を改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
【0145】
<拡張技術>
本発明は、トラヒックフロー数が増えた場合に、インバウンドのネットワークトラフィックを複数ＣＰＵで処理可能なＲＳＳ（Receive-Side Scaling）と連携して、パケット到着監視threadに割り当てるＣＰＵ数を増やすことで、ネットワーク負荷に対するスケールアウトが可能になる。
本発明は、トラヒックフロー数が増えた場合に、インバウンドのネットワークトラフィックを複数ＣＰＵで処理可能なＲＳＳ（Receive-Side Scaling）と連携して、パケット到着監視threadに割り当てるＣＰＵ数を増やすことで、ネットワーク負荷に対するスケールアウトが可能になる。
【0146】
［効果］
以上説明したように、OS（OS７０）が、カーネル（Kernel１７１）と、OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファ（Ring Buffer７２)と、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（poll_list１８６）と、を有し、カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００を備えており、サーバ内遅延制御装置１００は、ポールリストを監視（polling）するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファから削除する刈取りを実行するパケット刈取部１２０と、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はこのスレッド（polling thread）のハードウェア割込（hardIRQ）によりスリープ解除を行うsleep管理部１３０と、を備える。
以上説明したように、OS（OS７０）が、カーネル（Kernel１７１）と、OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファ（Ring Buffer７２)と、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（poll_list１８６）と、を有し、カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００を備えており、サーバ内遅延制御装置１００は、ポールリストを監視（polling）するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファから削除する刈取りを実行するパケット刈取部１２０と、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はこのスレッド（polling thread）のハードウェア割込（hardIRQ）によりスリープ解除を行うsleep管理部１３０と、を備える。
【0147】
このようにすることで、サーバ内遅延制御装置１００は、ＮＷ遅延発生の主要因であるパケット処理のソフトウェア割込（softIRQ）を停止し、サーバ内遅延制御装置１００のパケット到着監視部１１０がパケット到着を監視するthreadを実行し、パケット刈取部１２０が、パケット到着時に、pollingモデル（softIRQなし）によりパケット処理を行う。そして、sleep管理部１３０が、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させることで、スレッド（polling thread）はパケット未到着時にsleepする。sleep管理部１３０は、パケット到着時はハードウェア割込（hardIRQ）によりスリープ解除を行う。
これにより、下記（１）～（４）の効果を奏する。
これにより、下記（１）～（４）の効果を奏する。
【0148】
（１）遅延発生の原因となるパケット到着時のソフトウェア割込（softIRQ）を停止し、カーネル（Kernel１７１）内でpollingモデルを実現する。すなわち、サーバ内遅延制御システム１０００は、既存技術のNAPIと異なり、ＮＷ遅延の主要因となる割込モデルではなく、pollingモデルを実現する。パケット到着時は、待合せなく即時に刈り取られるため、低遅延なパケット処理を実現することができる。
【0149】
（２）サーバ内遅延制御装置１００におけるpolling threadは、kernel threadとして動作し、pollingモードでパケット到着を監視している。パケット到着を監視するkernel thread（polling thread）は、パケット到着がない間はsleepする。パケット到着がない場合は、sleepによってＣＰＵを使用しないので、省電力の効果を得ることができる。
【0150】
そして、パケット到着時には、sleep中のpolling threadは、パケット到着時のhardIRQハンドラで起こされる（sleep解除される）。hardIRQハンドラでsleep解除されることで、softIRQ競合を回避しながら、polling threadを即時起動させることができる。ここで、sleep解除は、タイマを持っていてこのタイマにより起こすものではなく、hardIRQハンドラで起こす点に特徴がある。なお、あらかじめトラヒックロードが分かっている場合、例えば図１３に示すワークロード転送レートのように３０ｍｓsleepが分かっている場合は、このタイミング合わせてhardIRQハンドラで起こすようにしてもよい。
【0151】
このように、サーバ内遅延制御装置１００は、パケット転送処理を行うpolling threadのsleep管理を行うことで、低遅延と省電力を両立させることができる。
【0152】
（３）ＡＰＬにパケット高速転送のための機能を具備させる必要がなく、ＡＰＬはカーネル（Kernel１７１）が持つ既存POSIX socket APIとのインタワークを行うだけでよい。すなわち、サーバ内遅延制御システム１０００は、既存技術のＤＰＤＫと異なり、kernel内でpollingモデルを実現するため、ＡＰＬに改変が不要である。具体的には、図１０に示すように、パケット高速転送のための機能（図１０のdpdk(PMD)２参照）を、パケット処理ＡＰＬ１Ａ（図１０参照）具備させる必要がなく、本サーバ内遅延制御システム１０００のパケット処理ＡＰＬ１（図１参照）は、kernelが持つ既存POSIX socket APIとのインタワークを行うだけでよい（kernelのプロトコルスタックに手を加えない）。このため、ＡＰＬを改変することなく、実現が可能である。
【0153】
（４）同様の理由で、独自のkernelを作る必要がなく、実現が可能である。
【0154】
また、仮想マシン内で動作するGuest OS（GuestOS７０）が、カーネル（Kernel１７１）と、Guest OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファ（Ring Buffer７２）と、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（poll_list１８６）と、刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部７４と、を有し、カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００を備えており、サーバ内遅延制御装置１００は、ポールリストを監視（polling）するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファから削除する刈取りを実行するパケット刈取部１２０と、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はこのスレッド（polling thread）のハードウェア割込（hardIRQ）によりスリープ解除を行うsleep管理部１３０と、を備えることを特徴とする。
【0155】
このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、Guest OS（GuestOS７０）を備えるサーバについて、消費電力の低減を図りつつ、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
【0156】
また、仮想マシンおよび仮想マシン外に形成された外部プロセスが動作可能なHost OS（HostOS９０）が、カーネル（Kernel９１）と、Host OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファ（Ring Buffer２２）と、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（poll_list１８６）と、カーネル（Kernel９１）により作成される仮想インターフェイスであるtapデバイス２２２と、を備え、カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００を備えており、サーバ内遅延制御装置１００は、ポールリストを監視（polling）するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファ（Ring Buffer７２）に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファ（Ring Buffer７２）から削除する刈取りを実行するパケット刈取部１２０と、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はこのスレッド（polling thread）のハードウェア割込（hardIRQ）によりスリープ解除を行うsleep管理部１３０と、を備えることを特徴とする。
【0157】
このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、カーネル（Kernel１７１）とHost OS（HostOS９０）とを備えるサーバについて、消費電力の低減を図りつつ、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
【0158】
サーバ内遅延制御装置１００において、スリープ中に、スレッドが使用するＣＰＵコアのＣＰＵ動作周波数を低く設定するＣＰＵ周波数設定部（CPU周波数/CPU idle設定部１４０）を備えることを特徴とする。
【0159】
このように、サーバ内遅延制御装置１００は、ＣＰＵ動作周波数をトラヒックに合わせて動的に変動させる、すなわち、スリープによりＣＰＵを使わないのであれば、スリープ中におけるＣＰＵ動作周波数を低く設定することで、より省電力の効果を高めることができる。
【0160】
サーバ内遅延制御装置１００において、スリープ中に、スレッドが使用するＣＰＵコアのＣＰＵアイドル状態を省電力モードに設定するＣＰＵアイドル設定部（CPU周波数/CPU idle設定部１４０）を備えることを特徴とする。
【0161】
このようにすることにより、サーバ内遅延制御装置１００は、CPU idle状態（動作電圧を変更するなど、ＣＰＵ機種に応じた省電力機能）をトラヒックに合わせて動的に変動させることで、より省電力の効果を高めることができる。
【0162】
サーバ内遅延制御装置１００において、カーネル（Kernel１７１）は、当該カーネル(Kernel171)を起動させたまま、処理動作を変更可能なパッチ（livepatch）を有することを特徴とする。
【0163】
このようにすることにより、サーバ内遅延制御装置１００は、livepatchを用いて、（Kernel１７１）を起動させたまま、処理動作が変更可能になるので、kernelの改造が不要である。このため、サーバ内遅延制御装置１００は、例えばkernelのセキュリティアップデートの度に、開発し直す必要がなく、関連するkernel機能に変更があった場合のみ、処理動作を変更すればよい。
【0164】
なお、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
【0165】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。
【符号の説明】
【0166】
１ パケット処理ＡＰＬ（アプリケーション）
１０ ＨＷ
１１ NIC（物理NIC）(インターフェイス部)
７０ OS
７４ プロトコル処理部
６０ user space（ユーザスペース）
７２ Ring Buffer（リングバッファ）
９０ Host OS（OS）
９１，１７１，１８１ Kernel（カーネル）
１００ サーバ内遅延制御装置（polling thread）
１１０ パケット到着監視部
１２０ パケット刈取部
１３０ sleep管理部
１４０ CPU周波数/CPU idle設定部（CPU周波数設定部，ＣＰＵアイドル設定部）
１８０ Guest OS（OS）
１８６ poll_list（ポールリスト）
２１０ Container
１０００，１０００Ａ，１０００Ｂ サーバ内遅延制御システム
１０ ＨＷ
１１ NIC（物理NIC）(インターフェイス部)
７０ OS
７４ プロトコル処理部
６０ user space（ユーザスペース）
７２ Ring Buffer（リングバッファ）
９０ Host OS（OS）
９１，１７１，１８１ Kernel（カーネル）
１００ サーバ内遅延制御装置（polling thread）
１１０ パケット到着監視部
１２０ パケット刈取部
１３０ sleep管理部
１４０ CPU周波数/CPU idle設定部（CPU周波数設定部，ＣＰＵアイドル設定部）
１８０ Guest OS（OS）
１８６ poll_list（ポールリスト）
２１０ Container
１０００，１０００Ａ，１０００Ｂ サーバ内遅延制御システム
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【手続補正書】
【提出日】2024-11-07
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
カーネル内にてポーリングを含むパケット処理を行うサーバであって、
前記サーバは、
パケットの到着を監視するパケット到着監視部と、
スレッドをスリープさせるスリープ管理部と、を備え、
前記スリープ管理部は、パケットが所定期間到着しない場合に、前記スレッドをスリープさせること
を特徴とするサーバ。
前記サーバは、
パケットの到着を監視するパケット到着監視部と、
スレッドをスリープさせるスリープ管理部と、を備え、
前記スリープ管理部は、パケットが所定期間到着しない場合に、前記スレッドをスリープさせること
を特徴とするサーバ。
【請求項2】
前記スリープ中に、前記スレッドが使用するＣＰＵコアのＣＰＵ動作周波数を低く設定するＣＰＵ周波数設定部を備える
ことを特徴とする請求項１に記載のサーバ。
ことを特徴とする請求項１に記載のサーバ。
【請求項3】
前記スリープ中に、前記スレッドが使用するＣＰＵコアのＣＰＵアイドル状態を省電力モードに設定するＣＰＵアイドル設定部を備える
ことを特徴とする請求項１に記載のサーバ。
ことを特徴とする請求項１に記載のサーバ。
【請求項4】
カーネル内にてポーリングを含むパケット処理を行うサーバであって、
前記サーバは、
パケットの到着を監視するパケット到着監視部と、
前記ポーリングにおけるスレッドがスリープ状態である場合において、前記パケット到着監視部がパケットの到着を確認したとき、ハードウェア割込により前記スリープ状態を解除するスリープ管理部と、を備える
ことを特徴とするサーバ。
前記サーバは、
パケットの到着を監視するパケット到着監視部と、
前記ポーリングにおけるスレッドがスリープ状態である場合において、前記パケット到着監視部がパケットの到着を確認したとき、ハードウェア割込により前記スリープ状態を解除するスリープ管理部と、を備える
ことを特徴とするサーバ。
【請求項5】
前記スリープ状態が解除された場合に、前記スレッドが使用するＣＰＵコアのＣＰＵ動作周波数を、前記スリープ状態でのＣＰＵ動作周波数よりも高く設定するＣＰＵ周波数設定部を備える
ことを特徴とする請求項４に記載のサーバ。
ことを特徴とする請求項４に記載のサーバ。
【請求項6】
前記スリープ状態が解除された場合に、前記スレッドが使用するＣＰＵコアのＣＰＵアイドル状態として設定された省電力モードを解除するＣＰＵアイドル設定部を備える
ことを特徴とする請求項４に記載のサーバ。
ことを特徴とする請求項４に記載のサーバ。
【請求項7】
コンピュータを、請求項１乃至請求項６のいずれか一項に記載のサーバとして機能させるためのプログラム。
【手続補正3】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【0001】
本発明は、サーバおよびプログラムに関する。
【手続補正4】
【補正対象書類名】明細書
【補正対象項目名】００５６
【補正方法】変更
【補正の内容】
【0056】
前記した課題を解決するため、カーネル内にてポーリングを含むパケット処理を行うサーバであって、前記サーバは、パケットの到着を監視するパケット到着監視部と、スレッドをスリープさせるスリープ管理部と、を備え、前記スリープ管理部は、パケットが所定期間到着しない場合に、前記スレッドをスリープさせることを特徴とするサーバとした。