JP7662062B2 - サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム - Google Patents

Description

本発明は、サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラムに関する。

ＮＦＶ（Network Functions Virtualization：ネットワーク機能仮想化）による仮想化技術の進展などを背景に、サービス毎にシステムを構築して運用することが行われている。また、上記サービス毎にシステムを構築する形態から、サービス機能を再利用可能なモジュール単位に分割し、独立した仮想マシン（ＶＭ：Virtual Machineやコンテナなど）環境の上で動作させることで、部品のようにして必要に応じて利用し運用性を高めるといったＳＦＣ（Service Function Chaining）と呼ばれる形態が主流となりつつある。

仮想マシンを構成する技術としてLinux（登録商標）とＫＶＭ（kernel-based virtual machine）で構成されたハイパーバイザー環境が知られている。この環境では、ＫＶＭモジュールが組み込まれたHost OS（物理サーバ上にインストールされたＯＳをHost OSと呼ぶ）がハイパーバイザーとしてカーネル空間と呼ばれるユーザ空間とは異なるメモリ領域で動作する。この環境においてユーザ空間にて仮想マシンが動作し、その仮想マシン内にGuest OS（仮想マシン上にインストールされたＯＳをGuest OSと呼ぶ）が動作する。

Guest OSが動作する仮想マシンは、Host OSが動作する物理サーバとは異なり、（イーサーネットカードデバイスなどに代表される）ネットワークデバイスを含むすべてのＨＷ（hardware）が、ＨＷからGuest OSへの割込処理やGuest OSからハードウェアへの書き込みに必要なレジスタ制御となる。このようなレジスタ制御では、本来物理ハードウェアが実行すべき通知や処理がソフトウェアで擬似的に模倣されるため、性能がHost OS環境に比べ、低いことが一般的である。

この性能劣化において、特にGuest OSから自仮想マシン外に存在するHost OSや外部プロセスに対して、ＨＷの模倣を削減し、高速かつ統一的なインターフェイスにより通信の性能と汎用性を向上させる技術がある。この技術として、virtioというデバイスの抽象化技術、つまり準仮想化技術が開発されており、すでにLinux（登録商標）を始め、FreeBSD（登録商標）など多くの汎用ＯＳに組み込まれ、現在利用されている。

virtioでは、コンソール、ファイル入出力、ネットワーク通信といったデータ入出力に関して、転送データの単一方向の転送用トランスポートとして、リングバッファで設計されたキューによるデータ交換をキューのオペレーションにより定義している。そして、virtioのキューの仕様を利用して、それぞれのデバイスに適したキューの個数と大きさをGuest OS起動時に用意することにより、Guest OSと自仮想マシン外部との通信を、ハードウェアエミュレーションを実行せずにキューによるオペレーションだけで実現することができる。

［ポーリングモデルによるパケット転送（DPDKの例）］
複数の仮想マシンを接続、連携させる手法はInter-VM Communicationと呼ばれ、データセンタなどの大規模な環境では、ＶＭ間の接続に、仮想スイッチが標準的に利用されてきた。しかし、通信の遅延が大きい手法であることから、より高速な手法が新たに提案されている。例えば、SR-IOV（Single Root I/O Virtualization）と呼ばれる特別なハードウェアを用いる手法や、高速パケット処理ライブラリであるIntel DPDK（Intel Data Plane Development Kit）（以下、ＤＰＤＫという）を用いたソフトウェアによる手法などが提案されている。

ＤＰＤＫは、従来Linux kernel（登録商標）が行っていたＮＩＣ（Network Interface Card）の制御をユーザ空間で行うためのフレームワークである。Linux kernelにおける処理との最大の違いは、ＰＭＤ（Pull Mode Driver）と呼ばれるポーリングベースの受信機構を持つことである。通常、Linux kernelでは、ＮＩＣへのデータの到達を受けて、割込が発生し、それを契機に受信処理が実行される。一方、ＰＭＤは、データ到達の確認や受信処理を専用のスレッドが継続的に行う。コンテキストスイッチや割込などのオーバーヘッドを排除することで高速なパケット処理を行うことができる。ＤＰＤＫは、パケット処理のパフォーマンスとスループットを大幅に高めて、データプレーン・アプリケーション処理に多くの時間を確保することを可能にする。

ＤＰＤＫは、ＣＰＵ（Central Processing Unit）やＮＩＣなどのコンピュータ資源を占有的に使用する。このため、ＳＦＣのようにモジュール単位で柔軟につなぎ替える用途には適用しづらい。これを緩和するためのアプリケーションであるＳＰＰ（Soft Patch Panel）がある。ＳＰＰは、ＶＭ間に共有メモリを用意し、各ＶＭが同じメモリ空間を直接参照できる構成にすることで、仮想化層でのパケットコピーを省略する。また、物理ＮＩＣと共有メモリ間のパケットのやり取りには、ＤＰＤＫを用いて高速化を実現する。ＳＰＰは、各ＶＭのメモリ交換の参照先を制御することで、パケットの入力先、出力先をソフトウェア的に変更することができる。この処理によって、ＳＰＰは、ＶＭ間やＶＭと物理ＮＩＣ間の動的な接続切替を実現する。

［New API(NAPI)によるＲｘ側パケット処理］
図１３は、Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理の概略図である（非特許文献１参照）。
図１３に示すように、New API(NAPI)は、OS７０（例えば、Host OS）を備えるサーバ上で、ユーザが使用可能なUser space６０に配置されたパケット処理ＡＰＬ１を実行し、OS７０に接続されたＨＷ１０のＮＩＣ１１とパケット処理ＡＰＬ１との間でパケット転送を行う。

OS７０は、kernel７１、Ring Buffer７２、およびDriver７３を有し、kernel７１は、プロトコル処理部７４を有する。
Kernel７１は、OS７０（例えば、Host OS）の基幹部分の機能であり、ハードウェアの監視やプログラムの実行状態をプロセス単位で管理する。ここでは、kernel７１は、パケット処理ＡＰＬ１からの要求に応えるとともに、ＨＷ１０からの要求をパケット処理ＡＰＬ１に伝える。Kernel７１は、パケット処理ＡＰＬ１からの要求に対して、システムコール（「非特権モードで動作しているユーザプログラム」が「特権モードで動作しているカーネル」に処理を依頼）を介することで処理する。
Kernel７１は、Socket７５を介して、パケット処理ＡＰＬ１へパケットを伝達する。Kernel７１は、Socket７５を介してパケット処理ＡＰＬ１からパケットを受信する。

Ring Buffer７２は、Kernel７１が管理し、サーバ中のメモリ空間にある。Ring Buffer７２は、Kernel７１が出力するメッセージをログとして格納する一定サイズのバッファであり、上限サイズを超過すると先頭から上書きされる。

Driver７３は、kernel７１でハードウェアの監視を行うためデバイスドライバである。なお、Driver７３は、kernel７１に依存し、作成された（ビルドされた）カーネルソースが変われば、別物になる。この場合、該当ドライバ・ソースを入手し、ドライバを使用するOS上で再ビルドし、ドライバを作成することになる。

プロトコル処理部７４は、ＯＳＩ（Open Systems Interconnection）参照モデルが定義するＬ２（データリンク層）／Ｌ３（ネットワーク層）／Ｌ４（トランスポート層）のプロトコル処理を行う。

Socket７５は、kernel７１がプロセス間通信を行うためのインターフェイスである。Socket７５は、ソケットバッファを有し、データのコピー処理を頻繁に発生させない。Socket７５を介しての通信確立までの流れは、下記の通りである。1.サーバ側がクライアントを受け付けるソケットファイルを作成する。2.受付用ソケットファイルに名前をつける。3.ソケット・キューを作成する。4.ソケット・キューに入っているクライアントからの接続の最初の1つを受け付ける。5.クライアント側ではソケットファイルを作成する。6.クライアント側からサーバへ接続要求を出す。7.サーバ側で、受付用ソケットファイルとは別に、接続用ソケットファイルを作成する。通信確立の結果、パケット処理ＡＰＬ１は、kernel７１に対してread()やwrite()などのシステムコールを呼び出せるようになる。

以上の構成において、Kernel７１は、NIC１１からのパケット到着の知らせを、ハードウェア割込（hardIRQ）により受け取り、パケット処理のためのソフトウェア割込（softIRQ）をスケジューリングする。
上記、Linux kernel 2.5/2.6より実装されているNew API(NAPI)は、パケットが到着するとハードウェア割込（hardIRQ）の後、ソフトウェア割込（softIRQ）により、パケット処理を行う。図１３に示すように、割込モデルによるパケット転送は、割込処理（図１３の符号ａ参照）によりパケットの転送を行うため、割込処理の待ち合わせが発生し、パケット転送の遅延が大きくなる。

以下、NAPI Rx側パケット処理概要について説明する。
［New API(NAPI)によるＲｘ側パケット処理構成］
図１４は、図１３の破線で囲んだ箇所におけるNew API(NAPI)によるＲｘ側パケット処理の概要を説明する図である。
<Device driver>
図１４に示すように、Device driverには、ネットワークインターフェースカードであるNIC１１（物理NIC）、NIC１１の処理要求の発生によって呼び出され要求された処理（ハードウェア割込）を実行するハンドラであるhardIRQ８１、およびソフトウェア割込の処理機能部であるnetif_rx８２が配置される。

<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７２が配置される。

<Protocol layer>
Protocol layerには、パケット処理機能部であるip_rcv８８、arp_rcv８９等が配置される。

上記netif_rx８２、do_softirq８４、net_rx_action８５、netif_receive_skb８７、ip_rcv８８、およびarp_rcv８９は、Kernel７１の中でパケット処理のために用いられるプログラムの部品（関数の名称）である。

［New API(NAPI)によるＲｘ側パケット処理動作］
図１４の矢印（符号）ｂ～ｍは、Ｒｘ側パケット処理の流れを示している。
NIC１１のhardware機能部１１ａ（以下、NIC１１という）が、対向装置からフレーム内にパケット（またはフレーム）を受信すると、ＤＭＡ（Direct Memory Access）転送によりＣＰＵを使用せずに、Ring Buffer７２へ到着したパケットをコピーする（図１４の符号ｂ参照）。このRing Buffer７２は、サーバの中にあるメモリ空間で、Kernel７１（図１３参照）が管理している。

しかし、NIC１１が、Ring Buffer７２へ到着したパケットをコピーしただけでは、Kernel７１は、そのパケットを認知できない。そこで、NIC１１は、パケットが到着すると、ハードウェア割込（hardIRQ）をhardIRQ８１に上げ（図１４の符号ｃ参照）、netif_rx８２が下記の処理を実行することで、Kernel７１は、当該パケットを認知する。なお、図１４の楕円で囲んで示すhardIRQ８１は、機能部ではなくハンドラを表記する。

netif_rx８２は、実際に処理をする機能であり、hardIRQ８１（ハンドラ）が立ち上がると（図１４の符号ｄ参照）、poll_list８６に、ハードウェア割込（hardIRQ）の中身の情報の１つである、ＮＩＣ１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を保存する。そして、netif_rx８２は、キューの刈取り（バッファに溜まっているパケットの中身を参照して、そのパケットの処理を、次に行う処理を考慮してバッファから該当するキューのエントリを削除する）を登録する（図１４の符号ｅ参照）。具体的には、netif_rx８２は、Ring Buffer７２にパケットが詰め込まれたことを受けて、NIC１１のドライバを使って、以後のキューの刈取りをpoll_list８６に登録する（図１４の符号ｅ参照）。これにより、poll_list８６には、Ring Buffer７２にパケットが詰め込まれたことによる、キューの刈取り情報が登録される。

このように、図１４の<Device driver>において、NIC１１は、パケットを受信すると、ＤＭＡ転送によりRing Buffer７２へ到着したパケットをコピーする。また、NIC１１は、hardIRQ８１（ハンドラ）を上げ、netif_rx８２は、poll_list８６にnet_deviceを登録し、ソフトウェア割込（softIRQ）をスケジューリングする。
ここまでで、図１４の<Device driver>におけるハードウェア割込の処理は停止する。

その後、netif_rx８２は、poll_list８６に積まれているキューに入っている情報（具体的にはポインタ）を用いて、Ring Buffer７２に格納されているデータを刈取ることを、ソフトウェア割込（softIRQ）でsoftIRQ８３（ハンドラ）に上げ（図１４の符号ｆ参照）、ソフトウェア割込の制御機能部であるdo_softirq８４に通知する（図１４の符号ｇ参照）。

do_softirq８４は、ソフトウェア割込制御機能部であり、ソフトウェア割込の各機能を定義（パケット処理は各種あり、割込処理はそのうちの一つ。割込処理を定義する）している。do_softirq８４は、この定義をもとに、実際にソフトウェア割込処理を行うnet_rx_action８５に、今回の（該当の）ソフトウェア割込の依頼を通知する（図１４の符号ｈ参照）。

net_rx_action８５は、softIRQの順番がまわってくると、poll_list８６に登録されたnet_deviceをもとに（図１４の符号ｉ参照）、Ring Buffer７２からパケットを刈取るためのポーリングルーチンを呼び出し、パケットを刈取る（図１４の符号ｊ参照）。このとき、net_rx_action８５は、poll_list８６が空になるまで刈取りを続ける。
その後、net_rx_action８５は、netif_receive_skb８７に通達をする（図１４の符号ｋ参照）。

netif_receive_skb８７は、sk_buff構造体を作り、パケットの内容を解析し、タイプ毎に後段のプロトコル処理部７４（図１３参照）へ処理をまわす。すなわち、netif_receive_skb８７は、パケットの中身を解析し、パケットの中身に応じて処理をする場合には、<Protocol layer>のip_rcv８８に処理を回し（図１４の符号ｌ）、また、例えばＬ２であればarp_rcv８９に処理をまわす（図１４の符号ｍ）。

特許文献１には、サーバ内ネットワーク遅延制御装置（ＫＢＰ：Kernel Busy Poll）が記載されている。ＫＢＰは、kernel内でpollingモデルによりパケット到着を常時監視する。これにより、softIRQを抑止し、低遅延なパケット処理を実現する。

国際公開第２０２１／１３０８２８号

New API(NAPI), ［online］,［令和４年１月１１日検索］,インターネット 〈 URL : http:// http://lwn.net/2002/0321/a/napi-howto.php3〉

しかしながら、割込モデルとポーリングモデルによるパケット転送のいずれについても下記課題がある。
割込モデルは、ＨＷからイベント（ハードウェア割込）を受けたkernelがパケット加工を行うためのソフトウェア割込処理によってパケット転送を行う。このため、割込モデルは、割込（ソフトウェア割込）処理によりパケット転送を行うので、他の割込との競合や、割込先ＣＰＵがより優先度の高いプロセスに使用されていると待ち合わせが発生し、パケット転送の遅延が大きくなるといった課題がある。この場合、割込処理が混雑すると、更に待ち合わせ遅延は大きくなる。
例えば、割込モデルによるパケット転送は、割込処理によりパケットの転送を行うため、割込処理の待ち合わせが発生し、パケット転送の遅延が大きくなる。

割込モデルにおいて、遅延が発生するメカニズムについて補足する。
一般的なkernelは、パケット転送処理はハードウェア割込処理の後、ソフトウェア割込処理にて伝達される。
パケット転送処理のソフトウェア割込が発生した際に、下記条件（１）～（３）においては、前記ソフトウェア割込処理を即時に実行することができない。このため、ksoftirqd（ＣＰＵ毎のカーネルスレッドであり、ソフトウェア割込の負荷が高くなったときに実行される）等のスケジューラにより調停され、割込処理がスケジューリングされることにより、ｍｓオーダの待ち合わせが発生する。
（１）他のハードウェア割込処理と競合した場合
（２）他のソフトウェア割込処理と競合した場合
（３）優先度の高い他プロセスやkernel thread（migration thread等）、割込先ＣＰＵが使用されている場合
上記条件では、前記ソフトウェア割込処理を即時に実行することができない。

また、New API(NAPI)によるパケット処理についても同様に、図１４の破線囲みｎに示すように、割込処理（softIRQ）の競合に起因し、ｍｓオーダのＮＷ遅延が発生する。
一方、特許文献１に記載の技術を用いると、パケット到着を常時監視することにより、ソフトウェア割込を抑止し、低遅延なパケット刈取を実現できる。しかしながら、パケット到着を監視するため、ＣＰＵコアを専有しＣＰＵタイムを使用するため、消費電力が高くなる。すなわち、パケット到着を常時監視するkernel threadがＣＰＵコアを専有し、常にＣＰＵタイムを使用するため、消費電力が大きくなる課題がある。図１５および図１６を参照して、ワークロードとＣＰＵ使用率の関係について説明する。

図１５は、映像（３０ＦＰＳ）のデータ転送例である。図１５に示すワークロードは、転送レート３５０Ｍｂｐｓで、３０ｍｓごとに間欠的にデータ転送を行っている。

図１６は、特許文献１に記載のＫＢＰにおける、busy poll threadが使用するＣＰＵ使用率を示す図である。
図１６に示すように、ＫＢＰでは、kernel threadはbusy pollを行うために、ＣＰＵコアを専有する。図１５に示す間欠的なパケット受信であっても、ＫＢＰでは、パケット到着有無に関わらず常にＣＰＵを使用するため、消費電力が大きくなる課題がある。

このような背景を鑑みて本発明がなされたのであり、本発明は、polling threadをsleepさせることによるＨＷ割込の過剰な発生を抑制し、消費電力の低減を図りつつ、サーバ内の遅延を小さくしてパケット転送を行うことを課題とする。

前記した課題を解決するため、サーバ内遅延制御装置であって、OSのカーネル空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置であって、インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストを監視するパケット到着監視部と、パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、ハードウェア割込回数を記憶するＨＷ割込回数記憶部と、前記ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出した前記ＨＷ割込頻度に基づいて前記スリープ管理部のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部と、を備えることを特徴とするサーバ内遅延制御装置とした。

本発明によれば、polling threadをsleepさせることによるＨＷ割込の過剰な発生を抑制し、消費電力の低減を図りつつ、サーバ内の遅延を小さくしてパケット転送を行うことができる。

本発明の実施形態に係るサーバ内遅延制御システムの概略構成図である。 図１のpolling thread（サーバ内遅延制御装置）をkernel spaceに配置した構成例である。 図１のpolling thread（サーバ内遅延制御装置）をUser spaceに配置した構成例である。 本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のpolling thread動作例を示す図である。 本発明の実施形態に係るサーバ内遅延制御システムのパケット到着速度とhardIRQ回数の関係を表わすグラフである。 比較例のパケット到着によるＨＷ割込と、ＨＷ割込で立ち上がるpolling threadを示す図である。 パケット到着によるＨＷ割込と、ＨＷ割込で立ち上がるpolling threadを示す図である。 本発明の実施形態に係るサーバ内遅延制御システムのpolling thread（サーバ内遅延制御装置）のＮＩＣおよびＨＷ割込処理を示すフローチャートである。 本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のＨＷ割込頻度制御処理を示すフローチャートである。 本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。 汎用Linux kernel（登録商標）およびＶＭ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システムを適用した例を示す図である。 コンテナ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システムを適用した例を示す図である。 Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理の概略図である。 図１３の破線で囲んだ箇所におけるNew API(NAPI)によるＲｘ側パケット処理の概要を説明する図である。 映像（３０ＦＰＳ）のデータ転送例を示す図である。 特許文献１に記載のＫＢＰにおける、busy poll threadが使用するＣＰＵ使用率を示す図である。

以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるサーバ内遅延制御システム等について説明する。
［概要］
図１は、本発明の実施形態に係るサーバ内遅延制御システムの概略構成図である。本実施形態は、Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理に適用した例である。図１３と同一構成部分には、同一符号を付している。
図１に示すように、サーバ内遅延制御システム１０００は、OS（例えば、Host OS）を備えるサーバ上で、ユーザが使用可能なUser spaceに配置されたパケット処理ＡＰＬ１を実行し、OSに接続されたＨＷのNIC１１とパケット処理ＡＰＬ１との間でパケット転送を行う。

サーバ内遅延制御システム１０００は、ネットワークインターフェースカードであるNIC１１（物理NIC）、NIC１１の処理要求の発生によって呼び出され要求された処理（ハードウェア割込）を実行するハンドラであるhardIRQ８１、ＨＷ割込の処理機能部であるＨＷ割込処理部１８２、receive list１８６、Ring_Buffer７２、polling thread（サーバ内遅延制御装置１００）と、プロトコル処理部７４と、を備える。
Ring Buffer７２は、サーバの中にあるメモリ空間においてkernelが管理する。Ring Buffer７２は、kernelが出力するメッセージをログとして格納する一定サイズのバッファであり、上限サイズを超過すると先頭から上書きされる。
プロトコル処理部７４は、Ethernet，IP，TCP/UDP等である。プロトコル処理部７４は、例えばＯＳＩ参照モデルが定義するＬ２／Ｌ３／Ｌ４のプロトコル処理を行う。

<サーバ内遅延制御装置>
サーバ内遅延制御装置１００は、kernel space またはUser spaceのいずれかに配置されるpolling threadである。
サーバ内遅延制御装置１００は、パケット到着監視部１１０と、パケット刈取部１２０と、sleep管理部１３０と、CPU周波数/CPU idle設定部１４０と、ＨＷ割込回数管理テーブル１５０ａ（ＨＷ割込回数記憶部）を有するＨＷ割込頻度制御部１５０と、を備える。

パケット到着監視部１１０は、パケットが到着していないかを監視するためのthreadである。パケット到着監視部１１０は、receive list１８６を監視（polling）する。

パケット到着監視部１１０は、receive list１８６からRing_Buffer７２にパケットが存在するポインタ情報と、net_device情報とを取得し、パケット刈取部１２０へ当該情報（ポインタ情報およびnet_device情報）を伝達する。ここで、receive list１８６に複数パケット情報が存在する場合は、複数分当該情報を伝達する。

パケット刈取部１２０は、パケットが到着している場合は、Ring Buffer７２に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをRing Buffer７２から削除する刈取りを実行する（以下、単にRing Buffer７２からパケットを刈取るという場合がある）。パケット刈取部１２０は、受信した情報をもとにRing_Buffer７２からパケットを取り出し、プロトコル処理部７４へパケットを伝達する。
パケット刈取部１２０は、Ring_Buffer７２に複数のパケットが貯まっているときは、複数パケットをまとめて刈り取って、後続のプロトコル処理部７４へ渡す。なお、このまとめて刈り取る数をquotaと言い、バッチ処理という呼び方をすることも多い。プロトコル処理部７４は、プロトコル処理も複数パケットをまとめて処理するので高速である。

sleep管理部１３０は、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はこのスレッド（polling thread）のハードウェア割込（hardIRQ）によりスリープ解除を行う（詳細後記）。

CPU周波数/CPU idle設定部１４０は、スリープ中に、スレッド（polling thread）が使用するＣＰＵコアのＣＰＵ動作周波数を低く設定する。CPU周波数/CPU idle設定部１４０は、スリープ中に、このスレッド（polling thread）が使用するＣＰＵコアのＣＰＵアイドル（CPU idle）状態を省電力モードに設定する（詳細後記）。

ＨＷ割込頻度制御部１５０は、ＨＷ割込回数をもとにＨＷ割込頻度を算出し、算出したＨＷ割込頻度に基づいてsleep管理部１３０のスリープによる、ＨＷ割込許可または禁止を制御する。具体的には、ＨＷ割込頻度制御部１５０は、算出したＨＷ割込頻度と所定閾値とを比較し、当該ＨＷ割込頻度が所定閾値より小さい場合、sleep管理部１３０によるスリープを一定時間実行させない（詳細後記）。

ＨＷ割込回数管理テーブル１５０ａは、ＨＷ割込回数として、ＨＷ割込が発生したタイムスタンプ（ＨＷ割込がいつ発生したかを示すタイムスタンプ）を記憶する。ＨＷ割込頻度制御部１５０は、ＨＷ割込回数管理テーブル１５０ａに記憶したタイムスタンプの回数をもとにＨＷ割込回数を算出する。

<サーバ内遅延制御装置の配置>
図２および図３は、図１のpolling thread（サーバ内遅延制御装置１００）の配置を説明する図である。
・polling threadのkernel space配置
図２は、図１のpolling thread（サーバ内遅延制御装置１００）をkernel spaceに配置した構成例である。
図２に示すサーバ内遅延制御システム１０００は、kernel spaceにpolling thread（サーバ内遅延制御装置１００）、プロトコル処理部７４が配置される。このpolling thread（サーバ内遅延制御装置１００）は、kernel space内で動作する。サーバ内遅延制御システム１０００は、OSを備えるサーバ上で、User spaceに配置されたパケット処理ＡＰＬ１を実行し、OSに接続されたDevice driverを介してＨＷのNIC１１とパケット処理ＡＰＬ１との間でパケット転送を行う。
なお、図２に示すように、Device driverには、hardIRQ８１、ＨＷ割込処理部１８２、receive list１８６、Ring_Buffer７２が配置される。
Device driverは、ハードウェアの監視を行うためのドライバである。

本発明を、ＮＡＰＩやＫＢＰのように、kernel内部にpolling threadがある場合に適用することができる。

・polling threadのUser space配置
図３は、図１のpolling thread（サーバ内遅延制御装置１００）をUser spaceに配置した構成例である。
図３に示すサーバ内遅延制御システム１０００は、User spaceにpolling thread（サーバ内遅延制御装置１００）、プロトコル処理部７４が配置される。このpolling thread（サーバ内遅延制御装置１００）は、Kernel space内ではなく、User spaceで動作する。
図３に示すサーバ内遅延制御システム１０００は、polling thread（サーバ内遅延制御装置１００）が、kernel spaceをバイパスして、Device driverおよびNIC１１とパケット処理ＡＰＬ１との間でパケット転送を行う。

本発明を、ＤＰＤＫのように、user spaceにpolling threadがある場合に適用することができる。

以下、サーバ内遅延制御システム１０００の動作を説明する。
［本発明によるＲｘ側パケット処理動作］
図１～図３の矢印（符号）ａａ～ｊｊは、Ｒｘ側パケット処理の流れを示している。
NIC１１が、対向装置からフレーム内にパケット（またはフレーム）を受信すると、ＤＭＡ転送によりＣＰＵを使用せずに、Ring Buffer７２へ到着したパケットをコピーする（図１～図３の符号ａａ参照）。このRing Buffer７２は、<Device driver>で管理している。

NIC１１は、パケットが到着すると、ハードウェア割込（hardIRQ）をhardIRQ８１（ハンドラ）に立ち上げ（図１～図３の符号ｂｂ参照）、ＨＷ割込処理部１８２が下記の処理を実行することで、当該パケットを認知する。

ＨＷ割込処理部１８２は、hardwire８１（ハンドラ）が立ち上がると（図１～図３の符号ｃｃ参照）、receive list１８６に、ハードウェア割込（hardIRQ）の中身の情報の１つである、ＮＩＣ１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を保存して、キューの刈取り情報を登録する。具体的には、ＨＷ割込処理部１８２は、Ring Buffer７２にパケットが詰め込まれたことを受けて、NIC１１のドライバを使って、以後のキューの刈取りをreceive list１８６に登録する（図１～図３の符号ｄｄ参照）。これにより、receive list１８６には、Ring Buffer７２にパケットが詰め込まれたことによる、キューの刈取りが登録される。

ＨＷ割込処理部１８２は、receive list１８６にnet_deviceを登録するが、図１４のnetif_rx８２とは異なり、ソフトウェア割込（softIRQ）のスケジューリングは行わない。すなわち、ＨＷ割込処理部１８２は、ソフトウェア割込（softIRQ）のスケジューリングは行わない点で、図１４のnetif_rx８２とは異なる。

また、ＨＷ割込処理部１８２は、sleepしているpolling threadを呼び起こすsleep解除を行う（図１～図３の符号ｅｅ参照）。
ここまでで、図１～図３の<Device driver>におけるハードウェア割込の処理は停止する。

本実施形態では、図１４に示す<Networking layer>において、softIRQ８３およびdo_softirq８４が削除され、これに伴い、図１４に示すnetif_rx８２が、softIRQ８３（ハンドラ）を立ち上げる通知（図１４の符号ｆ参照）も行わない。

本実施形態では、サーバ内遅延制御システム１０００は、図１４に示すsoftIRQ８３およびdo_softirq８４を削除し、代わりに<kernel space>にpolling thread（サーバ内遅延制御装置１００）設ける（図２参照）。あるいは、サーバ内遅延制御システム１０００は、<User space>にpolling thread（サーバ内遅延制御装置１００）設ける（図３参照）。

図２に示す<kernel space>または図３に示す<User space>において、サーバ内遅延制御装置１００のＨＷ割込頻度制御部１５０は、ＨＷ割込頻度を管理し、ＨＷ割込頻度に応じて、polling threadのsleepやＨＷ割込許可／禁止を制御する（図１～図３の符号ｆｆ参照）。

パケット到着監視部１１０は、receive list１８６を監視（polling）し（図１～図３の符号ｇｇ参照）、パケット到着有無を確認する。

パケット到着監視部１１０は、receive list１８６から、Ring_Buffer７２にパケットが存在するポインタ情報と、net_device情報とを取得し、パケット刈取部１２０へ当該情報（ポインタ情報およびnet_device情報）を伝達する（図１～図３の符号ｈｈ参照）。ここで、receive list１８６に複数パケット情報が存在する場合は、複数分当該情報を伝達する。

サーバ内遅延制御装置１００のパケット刈取部１２０は、パケットが到着している場合は、Ring Buffer７２からパケットを刈取る（図１～図３の符号ｉｉ参照）。
パケット刈取部１２０は、受信した情報をもとにRing_Buffer７２からパケットを取り出し、プロトコル処理部７４へパケットを伝達する（図１～図３の符号ｊｊ参照）。

［polling threadのsleep動作］
サーバ内遅延制御システム１０００は、ＮＷ遅延発生の主要因であるパケット処理のsoftIRQを停止し、サーバ内遅延制御装置１００のパケット到着監視部１１０がパケット到着を監視するpolling threadを実行する。そして、パケット刈取部１２０が、パケット到着時に、pollingモデル（softIRQなし）によりパケット処理を行う。

パケット到着時は、ハード割込ハンドラでpolling threadを起こすことで、softIRQ競合を回避して、即時にパケット転送処理が可能となる。言い換えれば、パケット到着監視機能を待機させておき、ハード割込で起こすことで、NAPI等のソフト割込によるパケット転送処理よりも低遅延化が可能になる。

パケット到着を監視するpolling thread（サーバ内遅延制御装置１００）は、パケット到着がない間はsleep可能とする。
polling thread（サーバ内遅延制御装置１００）は、パケット到着有無に応じてsleepし、パケット到着時はhardIRQ８１によりsleep解除を行う。具体的には、サーバ内遅延制御装置１００のsleep管理部１３０は、パケット到着有無に応じて、すなわち所定期間パケットの到着がないと、polling threadをsleepさせる。sleep管理部１３０は、パケット到着時はhardIRQ８１によりsleep解除を行う。これにより、softIRQ競合を回避して、低遅延化を実現する。

サーバ内遅延制御装置１００のCPU周波数/CPU idle設定部１４０は、パケット到着有無に応じてＣＰＵ動作周波数やidle設定を変更する。具体的には、CPU周波数/CPU idle設定部１４０は、sleep時はＣＰＵ周波数を下げ、再度起動時はＣＰＵ周波数を高める（ＣＰＵ動作周波数をもとに戻す）。また、CPU周波数/CPU idle設定部１４０は、sleep時はCPU idle設定を省電力に変更する。sleep時にＣＰＵ動作周波数を低く変更する、また、CPU idle設定を省電力に変更することで省電力化も達成する。

図４は、サーバ内遅延制御装置１００のpolling thread動作例を示す図である。縦軸は、polling threadが使用するＣＰＵコアのＣＰＵ使用率[％]を示し、横軸は、時間を示す。なお、図４は、図１５に示す間欠的にパケットが受信される映像（３０ＦＰＳ）のデータ転送例に対応するパケット到着によるpolling thread動作例を示している。
図４に示すように、サーバ内遅延制御装置１００のsleep管理部１３０は、所定期間パケットの到着がない場合（より詳細には、あるパケット到着してから、保守・運用者があらかじめ定めた固定値（一定期間）を経過しても次のパケット到着がない場合）に、polling threadをsleepさせる（図４の符号ｐ参照）。そして、sleep管理部１３０は、パケット到着のhardIRQ８１でpolling threadを起動させる（図４の符号ｑ参照）。
なお、sleep 時には、kernelthreadがＣＰＵコアを専有していないため、polling threadが使用する以外にも、システム安定動作のためのタイマの割込みが該当ＣＰＵコアに入ったり、エラー処理等のためのmigration threadが該当ＣＰＵコアに入ったりすることで、polling threadが使用するＣＰＵコアのＣＰＵ使用率が変動する場合がある（図４の符号ｒ参照）。

［パケット到着速度とパケット受信速度の関係］
上述したように、polling thread（サーバ内遅延制御装置１００）は、Ring Buffer７２に未受信のパケットがある場合は、ハードウェア割込要求（hardIRQ）を禁止しpollingによるパケット受信を行う。
ここで、パケット到着速度とパケット受信速度が同等である等の所定の条件を満たすと、パケット到着によるhardIRQ回数が多くなり、hardIRQオーバーヘッドにより、パケット転送遅延時間と消費電力が増大する場合がある。hardIRQオーバーヘッドについて述べる。ハードウェア割込は極めて高い優先度の処理であり、割り込まれたプロセスは処理を中断して、途中処理をメモリに退避する必要がある。hardIRQ回数が増えると、パケット受信処理（プロトコル処理等）がhardIRQにCPUタイムを奪われて中断されるため、パケット受信処理効率が下がってしまう。以下、パケット到着速度とパケット受信速度の関係について説明する。

図５は、パケットが１秒間にどけだけ到着するかを示すパケット到着速度（Packets per second）とhardIRQ回数（Number of hardIRQ）の関係を表わすグラフである。
・パケット到着頻度が低い「疎」の場合（図５の中段に示す短い双方向矢印参照）
図５の下図左に示すように、Ring Buffer７２にパケットが貯まる速度（図５の白抜き矢印ｔ参照）と、Ring Buffer７２から１パケットずつパケットを受信する速度（図５の白抜き矢印ｕ参照）とが同等である（拮抗している）場合、パケット到着頻度が低いため、Ring Buffer７２にパケットが貯まらず、パケット到着の度にhardIRQが発動される。

・パケット到着頻度が高い「密」の場合（図５の中段に示す長い双方向矢印参照）
図５の下図右に示すように、Ring Buffer７２にパケットが貯まる速度（図５の白抜き矢印ｖ参照）が大きく、Ring Buffer７２からある程度貯まったらバッチ処理で複数受信する速度（図５の白抜き矢印ｗ参照）が小さい場合、パケット到着頻度が高く、Ring Buffer７２にパケットが貯まるため、hardIRQ禁止時間が長く、hardIRQ回数は小さくなる。

図５の上図の破線楕円囲みｓに示すように、パケット到着速度とパケット受信速度が所定の条件を満たす際に、hardIRQ回数が多くなり、遅延時間と電力消費を増大させる。上記パケット到着速度とパケット受信速度が所定の条件を満たす場合は、図５の下図左に示すパケットが貯まる速度とパケットを受信する速度とが同等である場合である。パケット到着頻度が低いため、Ring Buffer７２にパケットが貯まらず、パケット到着の度にhardIRQが発動され、遅延時間と電力消費を増大させる。

［パケット到着頻度の補足説明］
パケット到着頻度について補足して説明する。
パケット到着頻度が低い状態は、それだけsleepできるチャンスが多く省電力効果が期待できる。
ところが、パケット到着頻度がそこそこ低く、しかしハードウェア割込は都度発生してしまうような、Sleepと起床を繰り返す場合、パケット到着の度にhardIRQが発動され、遅延時間が増大させる。
本実施形態は、パケット到着速度とパケット受信速度が拮抗するような状況において、polling threadをsleepさせることによるＨＷ割込の過剰な発生を抑制する技術を提供する。

［polling thread（サーバ内遅延制御装置１００）動作の基本的な考え方］
図６および図７を参照して、polling thread（サーバ内遅延制御装置１００）動作の基本的な考え方について説明する。図６は、比較例のパケット到着によるＨＷ割込と、ＨＷ割込で立ち上がるpolling threadを示す図である。図７は、本実施形態のパケット到着によるＨＷ割込と、ＨＷ割込で立ち上がるpolling threadを示す図である。図中、「●」はパケット到着を示し、「↑」はＨＷ割込を示し、網掛けブロックはpolling状態を示す。
図６の比較例において、パケット到着が中程度の場合、ＨＷ割込が大量に発生し（図６の符号ｘ参照）、大量に発生したＨＷ割込によりpolling threadはpolling状態となる。ＨＷ割込が過剰になり、オーバーヘッドによる遅延時間が増加する。なお、パケット到着が疎の場合やパケット到着が密の場合には、ＨＷ割込の発生が少なく、オーバーヘッドによる遅延時間は小さい。

そこで、本実施形態では、polling thread（サーバ内遅延制御装置１００）が、単一時間当たりのＨＷ割込頻度ｆを計算し、計算したＨＷ割込頻度ｆを運用者が予め設定した閾値と比較評価する。そして、polling threadをsleepさせ、後続のＨＷ割込を許可してよいか判断するロジックを導入する。図７のパケット到着が中程度の場合を例にとる。図７の符号ｙに示すように、polling thread（サーバ内遅延制御装置１００）は、単一時間当たりのＨＷ割込回数を考慮し、ＨＷ割込頻度に応じて割込禁止／許可を制御する（図７の破線囲みｚ参照）。これにより、過度なＨＷ割込を抑止し、ＨＷ割込が過剰になり、オーバーヘッドによる遅延時間の増加する事象を抑制する。

［polling thread（サーバ内遅延制御装置１００）の動作フロー］
図８は、polling thread（サーバ内遅延制御装置１００）のＮＩＣおよびＨＷ割込処理を示すフローチャートである。
polling threadが起動している間は、本動作フローをループして実行する。
NIC１１にパケットが到着すると、本フローがスタートする。ステップＳ１でNIC１１は、DMA(Direct Memory Access)により到着したパケットデータをメモリ領域へコピーする。

ステップＳ２でpolling thread（サーバ内遅延制御装置１００）は、ＨＷ割込が許可されているか否かを判別する。ＨＷ割込が許可されている場合（Ｓ２：Ｙｅｓ）、ステップＳ３に進み、ＨＷ割込が許可されていない場合（Ｓ２：Ｎｏ）には本フローの処理を終了する。
ステップＳ３でNIC１１は、ＨＷ割込（hardIRQ）をhardIRQ８１（ハンドラ）に立ち上げてＨＷ割込を起動し、receive list１８６にパケット到着情報（ＮＩＣデバイス情報等）を登録する。
ステップＳ４でNIC１１は、polling thread（サーバ内遅延制御装置１００）がsleepしている場合、polling threadを起こして本フローの処理を終了する。

図９は、polling thread（サーバ内遅延制御装置１００）のＨＷ割込頻度制御処理を示すフローチャートである。
polling threadがsleepしているときに、パケットが到着し、ＨＷ割込により起こされ、本フローがスタートする。
ステップＳ１１でＨＷ割込頻度制御部１５０は、NIC１１によるＨＷ割込を禁止する。処理している最中にＨＷ割込されると、処理が中断されてしまうので、ＨＷ割込頻度制御部１５０は、NIC１１によるＨＷ割込を一旦禁止する。

ステップＳ１２でCPU周波数/CPU idle設定部１４０は、polling threadが動作するＣＰＵコアのCPU周波数を高く設定し、該当ＣＰＵをidle stateにしていた場合はidle stateを解除する。

ステップＳ１３でＨＷ割込頻度制御部１５０は、ＨＷ割込が発生したタイムスタンプを、ＨＷ割込回数管理テーブル１５０ａに記録する。

ステップＳ１４でpolling threadは、receive list１８６を参照する。polling threadは、どこのデバイスからＨＷ割込が起ったかを知り、次のステップＳ１５でreceive list１８６のパケット到着情報を確認する。
なお、receive list１８６というControl Planeのlistを参照するのではなく、直接Ring Buffer７２を参照し、パケットの到着有無を確認してもよい。例えば、Linux kernelに実装されたNAPIでは、poll_listというControl Planeのlistを監視する。

ステップＳ１５でパケット到着監視部１１０は、receive list１８６にパケット到着情報が存在するか否かを判別する。receive list１８６にパケット到着情報が存在しない場合（Ｓ１５：Ｎｏ）、すなわち、処理すべきパケットがない場合には、以下の処理をスキップしてステップＳ２０に進む。

receive list１８６にパケット到着情報が存在する場合（Ｓ１５：Ｙｅｓ）、ステップＳ１６でpolling threadは、ring buffer７２からパケットデータを参照し、該当データを後続のプロトコル処理部７４へ転送する。ここで、複数のデータがある時は、一括で受信処理してもよい。

ステップＳ１７でパケット刈取部１２０は、ring buffer７２に未受信のパケットが存在する否かを判別する。ring buffer７２に未受信のパケットが存在する場合（Ｓ１７：Ｙｅｓ）、上記ステップＳ１６に戻る。

ring buffer７２に未受信のパケットが存在しない場合（Ｓ１７：Ｎｏ）、ステップＳ１８でＨＷ割込頻度制御部１５０は、ＨＷ割込回数管理テーブル１５０ａを参照し、単位時間当たりのＨＷ割込頻度ｆを計算する。ＨＷ割込回数管理テーブル１５０ａには、ＨＷ割込が発生したタイムスタンプが記録されている。ＨＷ割込頻度制御部１５０は、ＨＷ割込回数管理テーブル１５０ａに記録されたタイムスタンプの回数をもとに、単位時間当たりのＨＷ割込頻度ｆを計算する。
ちなみに、ＨＷ割込を禁止している間にpollingループを回すことで、計算する毎にＨＷ割込頻度ｆは小さくなる。

ステップＳ１９でＨＷ割込頻度制御部１５０は、ＨＷ割込頻度ｆが、運用者が設定した閾値よりも小さいか否かを判別する。ＨＷ割込頻度ｆが閾値以上（例えば、５０μｓでＨＷ割込が２回以上）の場合（Ｓ１９：Ｎｏ）、ステップＳ２４に進む。
なお、ＨＷ割込頻度ｆによる判定は、運用者が設定する固定的な閾値でなく、流入トラヒックの特徴に応じて学習して動的に閾値を決定してもよい。

ＨＷ割込頻度ｆが、運用者が設定した閾値よりも小さい場合（Ｓ１９：Ｙｅｓ）、ステップＳ２０以降のsleep制御に進む。ＨＷ割込頻度ｆが閾値よりも小さい場合は、図７に示すパケット到着が「疎」のときに該当する。

ステップＳ２０でCPU周波数/CPU idle設定部１４０は、polling threadが動作するＣＰＵコアのCPU周波数を低く設定し、該当ＣＰＵをidle stateにする。

ステップＳ２１でパケット到着監視部１１０は、receive list１８６から該当ＮＩＣ情報を削除する。
ステップＳ２２でＨＷ割込頻度制御部１５０は、該当NICによるＨＷ割込を許可する。
ステップＳ２３でsleep管理部１３０は、polling threadをsleepさせて本フローの処理を終了する。

一方、上記ステップＳ１９でＨＷ割込頻度ｆが閾値以上の場合、ステップＳ２４に進む。ＨＷ割込頻度ｆが閾値以上の場合は、図７に示すパケット到着が「中」のときに該当し、ステップＳ２４の実行結果は、図７の破線囲みｚに示す割込禁止に対応する。
ステップＳ２４で所定時間（例えば、一定時間ｔの経過後）polling threadをsleepさせて、ステップＳ１６に進む。

上記一定時間ｔの間polling threadをsleepさせることについて説明する。図７のパケット到着が「中」の事例で述べたように、ＨＷ割込頻度ｆが閾値以上の場合は、polling threadをsleepしたとしても直ぐに、パケットが到着し、ＨＷ割込により起こされる。すなわち、polling threadでsleepしていなかったのであれば、ＨＷ割込により起こされることがなかった事象が発生し、過剰なＨＷ割込が生じる。そこで、本実施形態では、ＨＷ割込頻度ｆが閾値以上の場合、一定時間ｔが経過してから、polling threadをsleepさせる。換言すれば、本来、polling threadをsleepする条件になったとしてもＨＷ割込頻度ｆが閾値以上の場合は、sleepするまでに時間を置く（一定時間ｔが経過するまで待ってからsleepする）。これにより、図７に示すパケット到着が「中」のときのように、パケット到着速度とパケット受信速度が一定の条件を満たす場合（パケットがRing Buffer７２に貯まる速度とパケットを受信する速度とが同等である場合）に、過剰なＨＷ割込を抑制することができる。

ここで、本来はsleepしていた場合に、一定時間ｔ経過後polling threadをsleepさせることで、sleepする時間が短くなる。しかしながら、ＨＷ割込は、遅延が大きいので、毎回、sleepからＨＷ割込により起こされることを考慮すれば、sleepに入るまでに猶予を持たせることの方がトータルの効率はよい。

なお、一定時間ｔは、ゼロでもよい。一定時間ｔをゼロにすると、本実施形態が有する過剰なＨＷ割込の抑制効果は得られないものの、図９のフローを常に実行しておくことができる。すなわち、一定時間ｔをゼロにすると、本システムを適用しない場合と事実上同等の効果となる。これにより、図９のフローを実行する／実行しないの判断処理が不要となる。つまり、ｔの設定を変えるだけで済むので、既存のシステムを改変することなく、汎用的に実施が可能である。

また、説明の便宜上、上記ｔを一定時間と呼称したが、ｔは一定時間に限らず、可変時間（所定時間）であってもよい。例えば、入力されるトラヒック特性から学習してｔを決定してもよいし、図９のフローのループを繰り返す毎（例えば、１μｓ毎）にｔの値を少しずつ増やしていってもよい。ｔの値を少しずつ増やす態様を採ると、ＨＷ割込頻度ｆが閾値以上の場合において、バケット到着の現況に合わせてsleepするまでの時間をより大きくすることができ、過剰なＨＷ割込抑制の実効を図ることができる。

ちなみに、図９のsleep制御のフローを実行することによる遅延時間の悪化は、本発明者らの実測によれば、平均数マイクロ秒程度の遅延時間の悪化にとどまることが確認されており、ハードウェア割込による起床程度の単体で見れば小さなオーバーヘッドである。

なお、図７のパケット到着が「中」の場合に効果を発揮する例について説明したが、図７のパケット到着が「密」の場合も同様に、sleepしてhardIRQで起床させる機会がある。このため、パケット到着が「密」の場合もhardIRQの頻度制御による本発明の効果が期待できる。

［ハードウェア構成］
上記実施形態に係るサーバ内遅延制御装置１００は、例えば図１０に示すような構成のコンピュータ９００によって実現される。
図１０は、サーバ内遅延制御装置１００の機能を実現するコンピュータ９００の一例を示すハードウェア構成図である。
コンピュータ９００は、ＣＰＵ９０１、ＲＯＭ９０２、ＲＡＭ９０３、ＨＤＤ９０４、通信インターフェイス（Ｉ／Ｆ：Interface）９０６、入出力インターフェイス（Ｉ／Ｆ）９０５、およびメディアインターフェイス（Ｉ／Ｆ）９０７を有する。

ＣＰＵ９０１は、ＲＯＭ９０２またはＨＤＤ９０４に格納されたプログラムに基づいて動作し、図１乃至図３に示すサーバ内遅延制御装置１００の各部の制御を行う。ＲＯＭ９０２は、コンピュータ９００の起動時にＣＰＵ９０１によって実行されるブートプログラムや、コンピュータ９００のハードウェアに依存するプログラム等を格納する。

ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、マウスやキーボード等の入力装置９１０、および、ディスプレイ等の出力装置９１１を制御する。ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、入力装置９１０からデータを取得するともに、生成したデータを出力装置９１１へ出力する。なお、プロセッサとしてＣＰＵ９０１とともに、ＧＰＵ（Graphics Processing Unit）等を用いてもよい。

ＨＤＤ９０４は、ＣＰＵ９０１により実行されるプログラムおよび当該プログラムによって使用されるデータ等を記憶する。通信Ｉ／Ｆ９０６は、通信網（例えば、ＮＷ（Network）９２０）を介して他の装置からデータを受信してＣＰＵ９０１へ出力し、また、ＣＰＵ９０１が生成したデータを、通信網を介して他の装置へ送信する。

メディアＩ／Ｆ９０７は、記録媒体９１２に格納されたプログラムまたはデータを読み取り、ＲＡＭ９０３を介してＣＰＵ９０１へ出力する。ＣＰＵ９０１は、目的の処理に係るプログラムを、メディアＩ／Ｆ９０７を介して記録媒体９１２からＲＡＭ９０３上にロードし、ロードしたプログラムを実行する。記録媒体９１２は、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto Optical disk）等の光磁気記録媒体、磁気記録媒体、導体メモリテープ媒体又は半導体メモリ等である。

例えば、コンピュータ９００が本実施形態に係る一装置として構成されるサーバ内遅延制御装置１００として機能する場合、コンピュータ９００のＣＰＵ９０１は、ＲＡＭ９０３上にロードされたプログラムを実行することによりサーバ内遅延制御装置１００の機能を実現する。また、ＨＤＤ９０４には、ＲＡＭ９０３内のデータが記憶される。ＣＰＵ９０１は、目的の処理に係るプログラムを記録媒体９１２から読み取って実行する。この他、ＣＰＵ９０１は、他の装置から通信網（ＮＷ９２０）を介して目的の処理に係るプログラムを読み込んでもよい。

［適用例］
図２に示すpolling thread（サーバ内遅延制御装置１００）のように、Kernel内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置に適用できる。この場合、ＯＳは限定されない。また、サーバ仮想化環境下であることも限定されない。したがって、サーバ内遅延制御システム１０００は、図１１および図１２に示す各構成に適用が可能である。

<ＶＭ構成への適用例>
図１１は、汎用Linux kernel（登録商標）およびＶＭ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システム１０００Ａを適用した例を示す図である。図１と同一構成部分には、同一符号を付している。
図１１に示すように、サーバ内遅延制御システム１０００Ａは、Guest OS７０のKernel１７１内にサーバ内遅延制御装置１００が配置され、Host OS９０のKernel９１内にサーバ内遅延制御装置１００が配置される。

詳細には、サーバは、仮想マシンおよび仮想マシン外に形成された外部プロセスが動作可能なHost OS９０と、仮想マシン内で動作するGuest OS７０と、を備える。
HostOS９０は、Kernel９１と、HostOS９０を備えるサーバ中のメモリ空間で、Kernel９１が管理するRing Buffer２２と、NIC11からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するreceive list１８６（図２）と、kernel threadであるvhost-netモジュール２２１と、Kernel９１により作成される仮想インターフェイスであるtapデバイス２２２と、仮想スイッチ(br)２２３と、を有する。

Kernel９１は、サーバ内遅延制御装置１００を備える。
Kernel９１は、tapデバイス２２２を介して、仮想マシン３０へパケットを伝達する。

一方、GuestOS７０は、Kernel１７１と、GuestOS７０を備えるサーバ中のメモリ空間で、Kernel１７１が管理するRing Buffer５２と、NIC１１からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するreceive list１８６（図２）と、Kernel１７１が、プロセス間通信を行うためのインターフェイスであるSocket７５と、を備える。

Kernel１７１は、サーバ内遅延制御装置１００と、刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部７４と、を備える。
Kernel１７１は、プロトコル処理部７４を介して、パケット処理ＡＰＬ１へパケットを伝達する。

このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、HostOS９０とGuestOS７０とのいずれのOSにおいても、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。

<コンテナ構成への適用例>
図１２は、コンテナ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システム１０００Ｂを適用した例を示す図である。図１と同一構成部分には、同一符号を付している。
図１２に示すように、サーバ内遅延制御システム１０００Ｂは、Guest OS１８０と、OSをContainer２１０に代えた、コンテナ構成を備える。Container２１０は、vNIC（仮想NIC）２１１を有する。Guest OS１８０のKernel１８１内にサーバ内遅延制御装置１００が配置される。

コンテナなどの仮想サーバ構成のシステムにおいて、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。

<ベアメタル構成（非仮想化構成）への適用例>
本発明は、ベアメタル構成のように非仮想化構成のシステムに適用できる。非仮想化構成のシステムにおいて、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。

<スケールイン／アウト>
トラヒック量が多く、複数のNICデバイスやNICポートを使用する場合に、これらと関連付けて複数のpolling threadを動作させることで、ＨＷ割込頻度制御を行いつつ、polling threadをスケールイン／アウトすることができる。

<拡張技術>
本発明は、トラヒックフロー数が増えた場合に、インバウンドのネットワークトラフィックを複数ＣＰＵで処理可能なＲＳＳ（Receive-Side Scaling）と連携して、パケット到着監視threadに割り当てるＣＰＵ数を増やすことで、ネットワーク負荷に対するスケールアウトが可能になる。

［効果］
以上説明したように、OSのカーネル空間（kernel space）に配置され、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００（図１および図２参照）であって、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（receive list１８６）を監視（polling）するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファ（Ring Buffer７２）に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファから削除する刈取りを実行するパケット刈取部１２０と、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はハードウェア割込（hardIRQ）によりこのスレッド（polling thread）のスリープ解除を行うsleep管理部１３０と、ハードウェア割込回数を記憶するＨＷ割込回数記憶部（ＨＷ割込回数管理テーブル１５０ａ）と、ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出したＨＷ割込頻度に基づいてsleep管理部１３０のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部１５０と、を備える。

このようにすることで、サーバ内遅延制御装置１００は、ＮＷ遅延発生の主要因であるパケット処理のソフトウェア割込（softIRQ）を停止し、サーバ内遅延制御装置１００のパケット到着監視部１１０がパケット到着を監視するthreadを実行し、パケット刈取部１２０が、パケット到着時に、pollingモデル（softIRQなし）によりパケット処理を行う。そして、sleep管理部１３０が、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させることで、スレッド（polling thread）はパケット未到着時にsleepする。sleep管理部１３０は、パケット到着時はハードウェア割込（hardIRQ）によりスリープ解除を行う。さらに、ＨＷ割込頻度制御部１５０は、ＨＷ割込回数記憶部（ＨＷ割込回数管理テーブル１５０ａ）に記憶したＨＷ割込回数をもとにＨＷ割込頻度を算出し、算出したＨＷ割込頻度に基づいてsleep管理部１３０のスリープ（sleep）による、ＨＷ割込許可または禁止を制御する。
これにより、下記（１）～（４）の効果を奏する。

（１）遅延発生の原因となるパケット到着時のソフトウェア割込（softIRQ）を停止し、カーネル（Kernel１７１）内でpollingモデルを実現する。すなわち、サーバ内遅延制御システム１０００は、既存技術のNAPIと異なり、ＮＷ遅延の主要因となる割込モデルではなく、pollingモデルを実現する。パケット到着時は、待合せなく即時に刈り取られるため、低遅延なパケット処理を実現することができる。

（２）サーバ内遅延制御装置１００におけるpolling threadは、kernel threadとして動作し、pollingモードでパケット到着を監視している。パケット到着を監視するkernel thread（polling thread）は、パケット到着がない間はsleepする。パケット到着がない場合は、sleepによってＣＰＵを使用しないので、省電力の効果を得ることができる。

そして、パケット到着時には、sleep中のpolling threadは、パケット到着時のhardIRQハンドラで起こされる（sleep解除される）。hardIRQハンドラでsleep解除されることで、softIRQ競合を回避しながら、polling threadを即時起動させることができる。ここで、sleep解除は、タイマを持っていてこのタイマにより起こすものではなく、hardIRQハンドラで起こす点に特徴がある。なお、あらかじめトラヒックロードが分かっている場合、例えば図１５に示すワークロード転送レートのように３０ｍｓsleepが分かっている場合は、このタイミング合わせてhardIRQハンドラで起こすようにしてもよい。

（３）さらに、算出したＨＷ割込頻度に基づいてsleep管理部１３０のスリープによる、ＨＷ割込許可または禁止を制御する。これにより、polling threadをsleepさせることによるオーバーヘッドの一つであるＨＷ割込が過剰に発生することによる遅延時間の増加を抑制することができ、より一層低遅延を達成することができる。

（４）本発明を、ＮＡＰＩやＫＢＰのように、kernel内部にpolling threadがある場合に適用することができる。

このように、サーバ内遅延制御装置１００（図２参照）は、kernel内部にpolling threadがある場合において、パケット転送処理を行うpolling threadのsleep管理を行うことで、低遅延と省電力を両立させることができる。さらに、パケット到着速度とパケット受信速度が同等である等の所定の条件を満たした場合に、パケット到着によるＨＷ割込回数が多くなり、パケット転送遅延時間が増大することを未然に防ぐことができる。

また、ユーザ空間（User space）に配置され、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００（図１および図３参照）であって、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（receive list１８６）を監視（polling）するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファ（Ring Buffer７２）に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部１２０と、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はハードウェア割込（hardIRQ）によりこのスレッド（polling thread）のスリープ解除を行うsleep管理部１３０と、ハードウェア割込回数を記憶するＨＷ割込回数記憶部（ＨＷ割込回数管理テーブル１５０ａ）と、ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出したＨＷ割込頻度に基づいてsleep管理部１３０のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部１５０と、を備える。

このようにすることで、サーバ内遅延制御装置１００（図３参照）は、ＤＰＤＫのように、user spaceにpolling threadがある場合において、パケット転送処理を行うpolling threadのsleep管理を行うことで、低遅延と省電力を両立させることができる。さらに、パケット到着速度とパケット受信速度が同等である等の所定の条件を満たした場合に、ＨＷ割込が過剰に発生することによる遅延時間の増加を抑制することができ、より一層低遅延を達成することができる。

また、仮想マシン内で動作するGuest OS（GuestOS７０）が、カーネル（Kernel１７１）と、Guest OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファ（Ring Buffer７２）と、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（poll_list１８６）と、刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部７４と、を有し、カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００を備えており、サーバ内遅延制御装置１００は、ポールリストを監視（polling）するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファから削除する刈取りを実行するパケット刈取部１２０と、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はこのスレッド（polling thread）のハードウェア割込（hardIRQ）によりスリープ解除を行うsleep管理部１３０と、ハードウェア割込回数を記憶するＨＷ割込回数記憶部（ＨＷ割込回数管理テーブル１５０ａ）と、ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出したＨＷ割込頻度に基づいてsleep管理部１３０のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部１５０と、を備えることを特徴とする。

このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、Guest OS（GuestOS７０）を備えるサーバについて、消費電力の低減を図りつつ、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。さらに、パケット到着速度とパケット受信速度が同等である等の所定の条件を満たした場合に、ＨＷ割込が過剰に発生することによる遅延時間の増加を抑制することができ、より一層低遅延を達成することができる。

また、仮想マシンおよび仮想マシン外に形成された外部プロセスが動作可能な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管理部１３０と、ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出したＨＷ割込頻度に基づいてsleep管理部１３０のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部１５０と、を備えることを特徴とする。

このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、カーネル（Kernel１７１）とHost OS（HostOS９０）とを備えるサーバについて、消費電力の低減を図りつつ、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。さらに、パケット到着速度とパケット受信速度が同等である等の所定の条件を満たした場合に、ＨＷ割込が過剰に発生することによる遅延時間の増加を抑制することができ、より一層低遅延を達成することができる。

サーバ内遅延制御装置１００において、ＨＷ割込頻度制御部１５０は、算出したＨＷ割込頻度と所定閾値とを比較し、このＨＷ割込頻度が所定閾値以上の場合、sleep管理部１３０によるスリープを一定時間実行させることを特徴とする。

このようにすることにより、パケット到着速度とパケット受信速度が同等である等の所定の条件を満たした場合に、ＨＷ割込が過剰に発生することによる遅延時間の増加を抑制することができ、より一層低遅延を達成することができる。

<その他の効果>
サーバ内遅延制御装置１００を含むサーバ内遅延制御システムにおいて、インターフェイス部（NIC１１）は、ハードウェア割込を割込ハンドラ（hardIRQ８１）に立ち上げてポールリストにデバイスを登録する場合、ソフトウェア割込によるスケジューリングを停止する。

このようにすることにより、遅延発生要因となるsoftIRQを停止し、その代わり、タイマ契機で、高い優先度であるhardIRQのコンテキストでパケット処理を行うことで、softIRQ競合を回避することができる。

本実施形態では、サーバ内遅延制御装置１００において、スリープ中に、スレッドが使用するＣＰＵコアのＣＰＵ動作周波数を低く設定するＣＰＵ周波数設定部（CPU周波数/CPU idle設定部１４０）を備える。

このように、サーバ内遅延制御装置１００は、ＣＰＵ動作周波数をトラヒックに合わせて動的に変動させる、すなわち、スリープによりＣＰＵを使わないのであれば、スリープ中におけるＣＰＵ動作周波数を低く設定することで、より省電力の効果を高めることができる。

本実施形態では、サーバ内遅延制御装置１００において、スリープ中に、スレッドが使用するＣＰＵコアのＣＰＵアイドル状態を省電力モードに設定するＣＰＵアイドル設定部（CPU周波数/CPU idle設定部１４０）を備える。

このようにすることにより、サーバ内遅延制御装置１００は、CPU idle状態（動作電圧を変更するなど、ＣＰＵ機種に応じた省電力機能）をトラヒックに合わせて動的に変動させることで、より省電力の効果を高めることができる。

なお、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。

１ パケット処理ＡＰＬ（アプリケーション）
１０ ＨＷ
１１ NIC（物理NIC）(インターフェイス部)
７０ Guest OS
７４ プロトコル処理部
６０ user space（ユーザスペース）
７２ Ring Buffer（リングバッファ）
９０ Host OS（OS）
９１，１７１，１８１ Kernel（カーネル）
１００ サーバ内遅延制御装置（polling thread）
１１０ パケット到着監視部
１２０ パケット刈取部
１３０ sleep管理部
１４０ CPU周波数/CPU idle設定部
１５０ ＨＷ割込頻度制御部
１５０ａ ＨＷ割込回数管理テーブル（ＨＷ割込回数記憶部）
１８０ Guest OS（OS）
１８６ receive list（ポールリスト）
２１０ Container
１０００，１０００Ａ，１０００Ｂ サーバ内遅延制御システム

Claims (7)

1. OSのカーネル空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置であって、
   インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストを監視するパケット到着監視部と、
   パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、
   パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、
   ハードウェア割込回数を記憶するＨＷ割込回数記憶部と、
   前記ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出した前記ＨＷ割込頻度に基づいて前記スリープ管理部のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部と、を備える
   ことを特徴とするサーバ内遅延制御装置。
2. ユーザ空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置であって、
   インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストを監視するパケット到着監視部と、
   パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、
   パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、
   ハードウェア割込回数を記憶するＨＷ割込回数記憶部と、
   前記ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出した前記ＨＷ割込頻度に基づいて前記スリープ管理部のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部と、を備える
   ことを特徴とするサーバ内遅延制御装置。
3. サーバ内遅延制御装置であって、
   仮想マシン内で動作するGuest OSが、
   カーネルと、
   前記Guest OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
   インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、
   刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部と、を有し、
   前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
   前記サーバ内遅延制御装置は、
   前記ポールリストによりパケット到着を監視するパケット到着監視部と、
   パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、
   パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、
   ハードウェア割込回数を記憶するＨＷ割込回数記憶部と、
   前記ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出した前記ＨＷ割込頻度に基づいて前記スリープ管理部のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部と、を備える
   ことを特徴とするサーバ内遅延制御装置。
4. サーバ内遅延制御装置であって、
   仮想マシンおよび前記仮想マシン外に形成された外部プロセスが動作可能なHost OSが、
   カーネルと、
   前記Host OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
   インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、
   前記カーネルにより作成される仮想インターフェイスであるtapデバイスと、を備え、
   前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
   前記サーバ内遅延制御装置は、
   前記ポールリストによりパケット到着を監視するパケット到着監視部と、
   パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、
   パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、
   ハードウェア割込回数を記憶するＨＷ割込回数記憶部と、
   前記ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出した前記ＨＷ割込頻度に基づいて前記スリープ管理部のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部と、を備える
   ことを特徴とするサーバ内遅延制御装置。
5. 前記ＨＷ割込頻度制御部は、算出した前記ＨＷ割込頻度と所定閾値とを比較し、当該ＨＷ割込頻度が所定閾値以上の場合、前記スリープ管理部によるスリープを一定時間実行させる
   ことを特徴とする請求項１乃至４のいずれか一項に記載のサーバ内遅延制御装置。
6. OSのカーネル空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置のサーバ内遅延制御方法であって、
   前記サーバ内遅延制御装置は、
   インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストを監視するステップと、
   パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するステップと、
   パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理ステップと、
   ハードウェア割込回数を記憶するステップと、
   前記ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出した前記ＨＷ割込頻度に基づいて前記スリープ管理ステップのスリープによる、ＨＷ割込許可または禁止を制御するステップと、を実行する
   ことを特徴とするサーバ内遅延制御方法。
7. コンピュータを、請求項１乃至５のいずれか１項に記載のサーバ内遅延制御装置として機能させるためのプログラム。

Images