JP7574902B2 - サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム - 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と自仮想マシン外部との通信を、ハードウェアエミュレーションを実行せずにキューによるオペレーションだけで実現することができる。

サーバ内のデータ転送技術としてNew API(NAPI)、ＤＰＤＫ（Data Plane Development Kit）、ＫＢＰ（Kernel Busy Poll）がある。

New API(NAPI)は、パケットが到着するとハードウェア割込要求の後、ソフトウェア割込要求によりパケット処理を行う（非特許文献１参照）（後記図１９参照）。

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

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

［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７１は、ＮＩＣ１１からのパケット到着の知らせを、ハードウェア割込（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８９に処理をまわす（図２０の符号ｍ）。

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

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

次に、ＤＰＤＫシステムについて説明する。
［ＤＰＤＫシステム構成］
図２３は、アクセラレータ１２０を備えるＨＷ１１０の制御を行うＤＰＤＫシステムの構成を示す図である。
ＤＰＤＫシステムは、ＨＷ１１０、ＯＳ１４０、user space（ユーザ空間）１６０上に配置されたデータ高速転送ミドルウェアであるＤＰＤＫ１５０、データ処理ＡＰＬ１を有する。
データ処理ＡＰＬ１は、ＡＰＬの実行に先立って行われるパケット処理である。
ＨＷ１１０は、データ処理ＡＰＬ１との間でデータ送受信の通信を行う。以下の説明において、図２３に示すように、データ処理ＡＰＬ１が、ＨＷ１１０からのパケットを受け取るデータの流れをＲｘ側受信と称し、データ処理ＡＰＬ１が、ＨＷ１１０にパケットを送信するデータの流れをＴｘ側送信と称する。

ＨＷ１１０は、アクセラレータ１２０と、通信ネットワークに接続するためのＮＩＣ１３０（物理NIC）と、を備える。
アクセラレータ１２０は、ＣＰＵからの入力をもとに、特定の演算を高速に行う計算ユニットハードウェアである。アクセラレータ１２０は、具体的には、ＧＰＵ（Graphics Processing Unit）やＦＰＧＡ（Field Programmable Gate Array）等のＰＬＤ（Programmable Logic Device）である。図２３では、アクセラレータ１２０は、複数のＣｏｒｅ（Ｃｏｒｅプロセッサ）１２１、データを先入れ先出しのリスト構造で保持するＲｘキュー（queue：待ち行列）１２２およびＴｘキュー１２３を備える。

アクセラレータ１２０にデータ処理ＡＰＬ１の処理の一部をオフロードし、ソフトウェア（ＣＰＵ処理）のみでは到達できない性能や電力効率を実現する。
ＮＦＶ（Network Functions Virtualization）やＳＤＮ（Software Defined Network）を構成するデータセンタなど、大規模なサーバクラスタにおいて、上記のようなアクセラレータ１２０を適用するケースが想定される。

ＮＩＣ１３０は、ＮＷインターフェイスを実現するＮＩＣハードウェアであり、データを先入れ先出しのリスト構造で保持するＲｘキュー１３１およびＴｘキュー１３２を備える。ＮＩＣ１３０は、例えば通信ネットワークを介して対向装置１７０に接続され、パケット送受信を行う。
なお、ＮＩＣ１３０は、例えばアクセラレータ付きのＮＩＣであるＳｍａｒｔＮＩＣであってもよい。ＳｍａｒｔＮＩＣは、処理能力が落ちる原因となるＩＰパケット処理など、負荷のかかる処理をオフロードしてＣＰＵの負荷を軽減することができるＮＩＣである。

ＤＰＤＫ１５０は、ＮＩＣの制御をuser space１６０で行うためのフレームワークであり、具体的にはデータ高速転送ミドルウェアからなる。ＤＰＤＫ１５０は、ポーリングベースの受信機構であるＰＭＤ（Poll Mode Driver）１５１（データ到着をポーリングモードまたは割込モードで選択可能なドライバ）を有する。ＰＭＤ１５１は、データ到達の確認や受信処理を専用のスレッドが継続的に行う。

ＤＰＤＫ１５０は、ＡＰＬが動作するuser space１６０でパケット処理機能を実現し、user space１６０からpollingモデルでパケット到着時に即時刈取りを行うことで、パケット転送遅延を小さくすることを可能にする。すなわち、ＤＰＤＫ１５０は、polling（ＣＰＵでキューをbusy poll）によりパケットの刈取りを行うため、待ち合わせがなく遅延小である。

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

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

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

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

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

特許文献１に記載のサーバ内ネットワーク遅延制御装置（ＫＢＰ）のように、カーネル内に受信用Polling Threadを配備した場合には、汎用性を志向するため、各アプリケーションの特性を意識した受信処理を行うことが難しい。結果的に、受信処理における低遅延性や省電力性を損なう場合がある。例えば、上記省電力サーバ内ネットワーク遅延制御装置では、受信処理が終了し、次のデータ到着がない（poll_listが空になった）場合、Polling Threadを即時Sleepする機能がある。この機能は、一般には省電力性を高める効果が見込める。一方で、アプリケーションが「カーネル内プロトコル処理を必要とせず、カーネルから即時にデータを受け取る」という特性を持つ場合には、受信処理が直ちに完了しpoll_listが空になりやすいため、連続的にデータを受信していてもSleepに入る場合がある。その結果として、ハードウェア割り込みによる起床が多発し、省電力性・低遅延性を損なうことがある。

このような背景を鑑みて本発明がなされたのであり、本発明は、アプリケーションの特性がそれぞれ異なるアプリケーションに対しても、消費電力の低減を図りつつ、サーバ内の遅延を小さくしてパケット転送を行うことを課題とする。

前記した課題を解決するため、ユーザ空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置であって、デバイスの受信キューをポーリングにより監視し、パケットが到着している場合は、データを取得するデータ到着監視部と、前記データ到着監視部が取得したデータをアプリケーションプログラムに通知して受け渡すデータ到着通知部と、パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うSleep管理部と、を備え、前記Sleep管理部は、アプリケーションプログラムの特性に基づいて、前記ハードウェア割込を許可して前記スリープするタイミングを制御することを特徴とするサーバ内遅延制御装置とした。

本発明によれば、アプリケーションの特性がそれぞれ異なるアプリケーションに対しても、消費電力の低減を図りつつ、サーバ内の遅延を小さくしてパケット転送を行うことができる。

本発明の第１実施形態に係るサーバ内遅延制御システムの概略構成図である。 本発明の第１実施形態に係るサーバ内遅延制御システムの動作を説明するための図である。 本発明の第１実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のPolling Thread動作中の転送処理（データ到着通知部がパケットを処理しない場合）のフローチャートである。 本発明の第１実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のPolling Thread動作中の転送処理（データ到着通知部がパケットを処理しない場合）の動作を説明する図である。 本発明の第１実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のPolling Thread動作中の転送処理（データ到着通知部がパケットを処理する場合）のフローチャートである。 本発明の第１実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のPolling Thread動作中の転送処理（データ到着通知部がパケットを処理する場合）の動作を説明する図である。 本発明の第１実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のPolling ThreadがSleep状態から起床するまでの処理フローチャートである。 本発明の第１実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のPolling ThreadがSleep状態から起床するまでの動作説明図である。 本発明の第２実施形態に係るサーバ内遅延制御システムの概略構成図である。 本発明の第２実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置の特性情報収集部の動作説明図である。 本発明の第２実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のロジック配信部の動作説明図である。 本発明の第２実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置におけるデータ到着監視部へのロジック変更の処理フローチャートである。 本発明の第２実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置におけるデータ到着監視部へのロジック変更の動作説明図である。 本発明の第２実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置におけるデータ到着通知部へのロジック変更の処理フローチャートである。 本発明の第２実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置におけるデータ到着通知部へのロジック変更の動作説明図である。 本発明の第２実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置におけるSleep管理部へのロジック変更の処理フローチャートである。 本発明の第２実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置におけるSleep管理部へのロジック変更の動作説明図である。 本発明の第１および第２実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。 Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理の概略図である。 図１９の破線で囲んだ箇所におけるNew API(NAPI)によるＲｘ側パケット処理の概要を説明する図である。 映像（３０ＦＰＳ）のデータ転送例を示す図である。 特許文献１に記載のＫＢＰにおける、busy poll threadが使用するＣＰＵ使用率を示す図である。 アクセラレータを備えるＨＷの制御を行うＤＰＤＫシステムの構成を示す図である。

以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるサーバ内遅延制御システム等について説明する。
（第１実施形態）
図１は、本発明の第１実施形態に係るサーバ内遅延制御システムの概略構成図である。図２３と同一構成部分には、同一符号を付している。
図１に示すように、サーバ内遅延制御システム１０００は、ＯＳ（例えば、Host OS）１４０を備えるサーバ上で、ユーザが使用可能なUser space１６０（ユーザ空間）に配置されたデータ処理ＡＰＬ（Application）１（アプリケーションプログラム。以下、適宜、アプリケーションという）を実行し、OSに接続されたＨＷ１１０のＮＩＣ１３０（デバイス）とデータ処理ＡＰＬ１との間でパケット転送を行う。
サーバ内遅延制御システム１０００は、ＨＷ１１０、ＯＳ１４０、user space１６０上に配置されたサーバ内遅延制御装置２００、データ処理ＡＰＬ１を有する。
データ処理ＡＰＬ１は、ＡＰＬの実行に先立って行われるパケット処理である。
ＨＷ１１０は、データ処理ＡＰＬ１との間でデータ送受信の通信を行う。
ＨＷ１１０は、通信ネットワークに接続するためのＮＩＣ１３０（デバイス）を備える。ＨＷ１１０は、図２３に示すアクセラレータ１２０を備えていてもよい。

［サーバ内遅延制御装置］
サーバ内遅延制御装置２００は、User space（ユーザ空間）に配置されるPolling Threadである。Polling Thread（サーバ内遅延制御装置２００）がOSカーネル内ではなく、ユーザ空間に備わることを特徴とする。Polling Thread（サーバ内遅延制御装置２００）は、ユーザ空間でデータ受信処理が定義されるため、アプリケーション特性（アプリケーションプログラムの特性）に合わせて受信処理の方式を変更することができる。

サーバ内遅延制御装置２００は、データ到着監視部２１０と、データ到着通知部２２０と、Sleep管理部２３０と、を備える。

<データ到着監視部２１０>
データ到着監視部２１０は、デバイスの受信キューをpollingによって監視し、パケットが到着した場合にはデータを取得してデータ到着通知部２２０に受け渡す。
具体的には、データ到着監視部２１０は、デバイスの受信キューをポーリングにより監視し、パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファから削除する刈取りを行う。すなわち、データ到着監視部２１０は、デバイスの受信キューをpollingによって監視し、即時刈取を行う。
データ到着監視部２１０は、アプリケーションの特性に基づく所定のタイミングで、デバイスの受信キューにデータが到着しているかを確認する。

データ到着監視部２１０は、所定時間の停止後、デバイスの受信キューにデータが到着しているかを確認する。すなわち、データ到着監視部２１０は、アプリケーションの特性に応じて、pollingに一時停止を挟むことでＣＰＵサイクル数を抑えて監視する。

<データ到着通知部２２０>
データ到着通知部２２０は、データ到着監視部２１０が取得したデータをアプリケーションに通知して受け渡す。

データ到着通知部２２０は、アプリケーションの特性が、パケットを逐次処理する特性の場合には、パケット到着時に直ちに通知する。一方、データ到着通知部２２０は、パケットをバッチ処理する特性の場合には、所定数のパケットが到着した際に通知する。

データ到着通知部２２０は、パケット処理機能を有し、アプリケーションプログラムの特性をもとに、パケット処理機能を実行し、当該パケット処理機能を実行した場合、アプリケーションプログラムに通知しない。このように、データ到着通知部２２０は、アプリケーションの特性に合わせて、バッチして通知する方式や逐次通知する方式を選択でき、更にこの機能部にパケットを処理させることもできる。

<Sleep管理部２３０>
Sleep管理部２３０は、アプリケーションの特性に基づいて、ハードウェア割込を許可してスリープするタイミングを制御する。
Sleep管理部２３０は、Polling ThreadをSleepさせてＨＷ割り込みを許可したり、ＨＷ割り込みを禁止してPolling Threadを起床させたりする。この際、アプリケーションの特性に合わせて、Sleepするタイミングを制御できる。

Sleep管理部２３０は、パケット未着時にPolling ThreadをSleepさせ、再びパケットが届いた際にはHardIRQから起こされ、Pollingを開始させる。

Sleep管理部２３０は、Polling時には、Sleepを開始する際に、Polling Threadを停止させ、ＨＷ割り込みを許可してSleepする。この際、ＣＰＵ動作周波数や動作電圧を下げることで、Sleep中の消費電力を更に削減する。

Sleep管理部２３０は、アプリケーションの特性に応じ、ＨＷ割り込みを許可してSleepするタイミングを制御する機構を持つ。例えば、ドライバの受信キューが空になっても、直ちにパケットが到着するようなアプリケーションの場合にはPollingを続けることもできる。

Sleep管理部２３０は、Sleep時には、パケット到着時に発生するＨＷ割り込みによって起こされ、ＨＷ割り込みを禁止したままPollingを開始する。この際、ＣＰＵ動作周波数や電圧を高く設定しなおす。

Sleep管理部２３０は、パケットが未着になってからの経過時間とアプリケーションの特性に適した時間とを比較し、パケットが未着になってからの経過時間がアプリケーションの特性に適した時間以上の場合、ハードウェア割り込みを有効化し、スレッドをスリープさせる。

以下、上述のように構成されたサーバ内遅延制御システム１０００の動作を説明する。
［サーバ内遅延制御システム１０００の全体動作］
図２は、図１のサーバ内遅延制御システム１０００の動作を説明するための図である。
図２の矢印（符号）ａａ～ｇｇは、Ｒｘ側パケット処理の流れを示している。
ＮＩＣ１３０が、対向装置からフレーム内にパケット（またはフレーム）を受信すると、ＯＳ１４０をバイパスしてパケットをPolling Thread（サーバ内遅延制御装置２００）のデータ到着監視部２１０に送信する。

<データ到着監視部２１０の動作>
データ到着監視部２１０は、デバイスの受信キューをpollingによって監視し（図２の<Polling>；符号ａａ参照）、パケットが到着した場合には刈り取ってデータ到着通知部２２０に受け渡す（図２の符号ｂｂ参照）。アプリケーションの遅延要件が厳しくない場合や、パケットの到着間隔が短くない場合に、Pollingに一時停止を挟むことで、ＣＰＵサイクル数を削減しながら受信監視を行うことができる（省電力化）。

データ到着監視部２１０は、パケット到着を監視するPolling Threadを立ち上げ、ネットワークデバイスの受信キューを直接監視する。パケット到着時は、待合せなく即時に刈り取られるため、低遅延なパケット処理を実現することができる（「特徴１：低遅延なパケット転送」）。

<データ到着通知部２２０の動作>
データ到着通知部２２０は、データ到着監視部２１０が刈り取ったデータをデータ処理ＡＰＬ（Application）１に通知して受け渡す（図２の<notify>；符号ｃｃ参照）。

ここで、「パケットを逐次処理するアプリケーションには、データ到着時に直ちに通知する」または「パケットをバッチ処理するアプリケーションには、一定数のデータが到着した際に通知する」というように、アプリケーションの特性に合わせて到着通知方式を選択することができる。
更に、アプリケーションが単純である場合、通知するのではなく、パケット処理をする機能を具備することで、到着通知のオーバーヘッドを削減してパケットを処理することもできる。

Polling Thread（サーバ内遅延制御装置２００）は、アプリケーションの特性やトラフィック情報に応じて、Pollingによって刈取を行う頻度の制御や、到着したデータをアプリケーションに通知する方式の制御や、Polling ThreadをSleepさせるタイミングの制御を行うことで、アプリケーションの特性やトラフィック情報に応じた更なる低遅延化・省電力化を実現できる（「特徴２：アプリケーション特性やトラフィック情報を意識した受信処理」）。

<Sleep管理部２３０の動作>
ＮＩＣ１３０は、パケットが到着すると、ＨＷ割込（hardIRQ）をhardIRQ８１（ハンドラ）に立ち上げる（図２の<Interrupt>；符号ｄｄ参照）。hardwire８１（ハンドラ）が立ち上がると、Sleep管理部２３０は、Sleep時には、パケット到着時に発生するＨＷ割り込みによって起こされ（図２の<Wakeup>；符号ｅｅ参照）、ＨＷ割り込みを禁止したままPollingを開始する。言い換えれば、Sleep管理部２３０は、パケット未着時にPolling ThreadをSleepさせ、再びパケットが届いた際にはHardIRQ８１から起こされ、Pollingを開始させる。

Sleep管理部２３０は、Polling ThreadをSleepさせてＨＷ割り込みを許可したり、ＨＷ割り込みを禁止してPolling Threadを起床させたりする（図２の<Enable/Disable>；符号ｆｆ参照）。この際、アプリケーションの特性に合わせて、Sleepするタイミングを制御できる。

Sleep管理部２３０は、Polling時には、Sleepを開始する際に、Polling Threadを停止させ、ＨＷ割り込みを許可してSleepする（図２の<Polling Start/stop>；符号ｇｇ参照）。この際、ＣＰＵ動作周波数や動作電圧を下げることで、Sleep中の消費電力を更に削減する。

Sleep管理部２３０は、アプリケーションの特性に応じ、ＨＷ割り込みを許可してSleepするタイミングを制御する機構を持つ。例えば、ドライバの受信キューが空になっても、直ちにパケットが到着するようなアプリケーションの場合にはPollingを続けることもできる。

Sleep管理部２３０は、パケット未到着時にPolling ThreadをSleepさせる。これにより、不要なＣＰＵ使用を削減し、省電力化を実現する。Sleepする際にＣＰＵ動作電圧や動作周波数を下げることで、更に省電力化することができる（「特徴３：省電力」）。
また、sleep中のPolling Threadは、パケット到着時のHardIRQハンドラ８１で起こすことで、softIRQ競合を回避しながら即時起動が可能である。

<パラメータＵ，Ｔ，Ｋの決定方法>
後記図３および図５のフローチャートで用いるパラメータＵ，Ｔ，Ｋの決定方法について説明する。
Polling Thread（サーバ内遅延制御装置２００）は、データ到着監視間隔Ｕ（データ到着監視部２１０のパラメータ）、パケット未着になってからSleepに入るまでの時間Ｔ（Sleep管理部２３０のパラメータ）、パケットを通知または処理するバッチ数Ｋ（データ到着通知部２２０のパラメータ）を用いる。第１実施形態では、パラメータＵ，Ｔ，Ｋは運用者が事前に設定した固定値である。後記第２実施形態では、パラメータＵ，Ｔ，Ｋはロジック管理部３１０を介して動的に設定される（説明の便宜上、ここでまとめて述べる）。

・データ到着監視間隔Ｕの決定例
運用者が事前に設定した固定値と、ロジック管理部３１０（後記）を介した動的な設定とがある。
ロジック管理部３１０（後記）を介した動的な設定の場合、次の２例がある。
例１：データ到着監視部２１０でパケット到着頻度を取得し、それに近い頻度で到着監視ができるようにＵを設定する。
例２：アプリケーションやサーバ外部のコントローラから、許容される最大遅延を取得し、それを保てる頻度で到着監視ができるようにＵを設定する。

・パケット未着になってからSleepに入るまでの時間Ｔの決定例
運用者が事前に設定した固定値と、ロジック管理部３１０（後記）を介した動的な設定とがある。
ロジック管理部３１０を介した動的な設定の場合、次の２例がある。
例１：Sleep管理部２３０で、Sleepに入ってから起床するまでの時間を取得し、その間隔が遅延時間や省電力性に悪影響を与えるほど短い場合、Ｔを大きくする。
例２：データ到着監視部２１０やアプリケーションやサーバ外部のコントローラからパケット到着頻度を取得し、それが大きい場合、可能な限りSleepができるようにＴを小さくする。

・パケットを通知・または処理するバッチ数Ｋの決定例
バッチ数Ｋについて述べる。すなわち、データ到着監視部２１０は、Ring_Buffer領域に複数のパケットが貯まっているときは、複数パケットをまとめて刈り取って、後続のプロトコル処理部（図示省略）へ渡す。このまとめて刈り取る数をquotaと言い、バッチ処理という呼び方をし、その処理数をバッチ数（バッチ処理数）という。
運用者が事前に設定した固定値と、ロジック管理部３１０（後記）を介した動的な設定とがある。
ロジック管理部３１０（後記）を介した動的な設定の場合、次の例がある。
例１：アプリケーションから、アプリケーション内のバッチ処理情報を取得し、それに合わせてＫを設定する。

次に、図３乃至図６を参照して、Polling Thread動作中の転送処理について説明する。Polling Thread動作中の転送処理は、データ到着通知部２２０がパケットを処理しない場合（図３および図４参照）と、データ到着通知部２２０がパケットを処理する場合（図５および図６参照）とがあり、それぞれについて述べる。

［Polling Thread動作中の転送処理（データ到着通知部２２０がパケットを処理しない場合）］
<フローチャート>
図３は、Polling Thread動作中の転送処理（データ到着通知部２２０がパケットを処理しない場合）のフローチャートである。

ステップＳ１１でデータ到着監視部２１０は、アプリケーション特性に適した間隔をあけて、ＮＩＣ１３０の受信キューにデータが到着しているかを確認する。データ到着監視部２１０は、例えば、時間Ｕだけ一時停止してから確認する。
ステップＳ１２でデータ到着監視部２１０は、受信キューにデータが到着しているか否かを判別する。受信キューにデータが到着していない場合（Ｓ１２：Ｎｏ）、ステップＳ１７に進む。

受信キューにデータが到着している場合（Ｓ１２：Ｙｅｓ）、ステップＳ１３でデータ到着監視部２１０は、受信キューからデータを取得し、データ到着通知部２２０へ該当情報を伝達する（受信キューに複数データが到着している場合は、複数分伝達する）。また、このとき、Sleep管理部２３０は、パケットが未着になってからの経過時間Ｓを０に戻す。

ステップＳ１４でデータ到着通知部２２０は、これまで到達したパケット数Ｎを加算し、アプリケーション特性に適したバッチ数Ｋと比較する。

ステップＳ１５でデータ到着通知部２２０は、Ｎ≧Ｋとなっているか否かを判別する。Ｎ＜Ｋの場合（Ｓ１５：Ｎｏ）、上記ステップＳ１１に戻る。

Ｎ≧Ｋとなっている場合（Ｓ１５：Ｙｅｓ）、ステップＳ１６でデータ到着通知部２２０は、アプリケーションにデータ到着を通知してデータを受け渡し、これまで到達したパケット数Ｎを０にして上記ステップＳ１１に戻る。

ステップＳ１７では、Sleep管理部２３０は、パケットが未着になってからの経過時間Ｓとアプリケーション特性に適した時間Ｔを比較する。

ステップＳ１８でSleep管理部２３０は、Ｓ≧Ｔとなっているか否かを判別する。Ｓ＜Ｔの場合（Ｓ１８：Ｎｏ）、上記ステップＳ１１に戻る。

Ｓ≧Ｔとなっている場合（Ｓ１８：Ｙｅｓ）、ステップＳ１９でSleep管理部２３０は、ＨＷ割り込みを有効化し、ＣＰＵ動作周波数や動作電圧を低くして、Polling ThreadをSleepに落として本フローの処理を終了する。

上記バッチ数Ｋ（≧1）、アプリケーション特性に適した時間Ｔ（≧０）、一時停止時間Ｕ（≧０）について述べる。Ｋ，Ｔ，Ｕは、事前に運用者が設定する。また、Ｋ，Ｔ，Ｕは、後記するロジック管理部３１０（第２実施形態で、Ｋ，Ｔ，Ｕの決定例について後記する）によって動的に変更される。

<動作説明図>
図４は、Polling Thread動作中の転送処理（データ到着通知部２２０がパケットを処理しない場合）の動作を説明する図である。
ＮＩＣ１３０は、パケットを受信した際、ＤＭＡ（Direct Memory Access）によりＣＰＵを介さずに、直接Ring Buffer（メインメモリ上のバッファ）にパケットをコピーする（図４の<Polling>；符号ａａ参照）。なお、このRing Bufferは、User Space１６０のPolling Threadから、OSカーネルを介さずに直接アクセスが可能であるよう、あらかじめ設定する。

ＮＩＣ１３０は、Polling Threadが駆動するＣＰＵに対して割込を起こし、そのＣＰＵはハードウェア割り込みのコンテキストでPolling Threadに対して起床の通知を行い、Sleep管理部２３０を起床させる。以降、ＣＰＵではPolling Threadが動作する。

Sleep管理部２３０は、ＣＰＵの周波数を高く設定し、当該ＣＰＵへの割り込みを禁止する（図４の<Enable>；符号ｆｆ参照）。ＣＰＵ周波数は、CPUgovernorの設定によりUser Space１６０からでも変更が可能である。

Sleep管理部２３０は、データ到着監視部２１０にPollingの開始を指示する（図４の<Polling stop>；符号ｇｇ参照）。上記Pollingの開始指示は、具体的には、Sleep管理部２３０から、データ到着監視部２１０の処理にあたる関数を呼び出す、ことである。

データ到着監視部２１０は、事前に運用者が決定した到着確認間隔で、パケットがＤＭＡされるRing Buffer領域に対して到着確認を行い、パケットが届いている場合にはそのパケットのアドレス情報（ポインタ）をデータ到着通知部２２０に伝達する（図４の符号ｂｂ参照）。

データ到着通知部２２０は、データ到着監視部２１０から伝達されたポインタ情報の数が、運用者が事前に決定したパケットを通知するバッチ数に達しているかを確認する（図３のステップＳ１４～ステップＳ１５）。

伝達されたポインタ情報の数が、決定したパケットを通知するバッチ数に達している場合、下記の処理に進む。そうでない場合、上記データ到着監視部２１０による、パケット到着確認に戻る。

データ到着通知部２２０は、アプリケーションとPolling Threadの共有メモリにアドレス情報を格納し、アプリケーションが動作するスレッドを起こし、そのスレッド内で処理を実行する（図４の<notify>；符号ｃｃ参照）。

上記、パケットが届いていない時間が運用者が事前に決定した時間続いた場合、データ到着監視部２１０は、Sleep管理部２３０を呼び出す（図３のステップＳ１２）。データ到着監視部２１０がreturnを行うことで、Sleep管理部２３０に処理が戻る。

Sleep管理部２３０は、ＣＰＵ周波数を落とし、ＣＰＵへの割り込みを有効化して、Polling ThreadをSleep状態に落とす（図３のステップＳ１９）。

［Polling Thread動作中の転送処理（データ到着通知部２２０がパケットを処理する場合）］
アプリケーションロジックが、同一スレッドで実行されるように運用者が設定していた場合、Polling Thread内で処理を行う。

<フローチャート>
図５は、Polling Thread動作中の転送処理（データ到着通知部２２０がパケットを処理する場合）のフローチャートである。図３のフローの同一処理を行うステップには同一番号を付して説明を省略する。
ステップＳ１５でデータ到着通知部２２０は、Ｎ≧Ｋとなっているか否かを判別し、Ｎ≧Ｋとなっている場合（Ｓ１５：Ｙｅｓ）、ステップＳ２１に進む。
ステップＳ２１でデータ到着通知部２２０は、パケットを処理（例えば、別サーバに向けての転送処理）してステップＳ１１に戻る。また、データ到着通知部２２０は、これまで到達したパケット数Ｎを０にする。データ到着通知部２２０がパケットを処理するので、図３のステップＳ１６のデータ到着通知部２２０のように、アプリケーションにデータ到着を通知してデータを受け渡す処理がない。

<動作説明図>
図６は、Polling Thread動作中の転送処理（データ到着通知部２２０がパケットを処理する場合）の動作を説明する図である。図４の動作説明図と同一構成部分には同一番号を付して説明を省略する。

データ到着通知部２２０は、パケットを処理する。データ到着通知部２２０が、Polling Thread内で行うパケット処理は、比較的負荷の少ない、別サーバに向けての転送処理などである。

［Polling ThreadがSleep状態から起床するまでの処理］
図７は、Polling ThreadがSleep状態から起床するまでの処理フローチャートである。図８は、その動作説明図である。図２の動作説明図と同一構成部分には同一番号を付している。
ステップＳ３１でＮＩＣ１３０にデータが到着し、ＮＩＣ１３０からＣＰＵに割り込みが上がる。
ステップＳ３２で該当ＣＰＵにおいてＨＷ割り込みのコンテキストが立ち上がる。
ステップＳ３３でＨＷ割り込みのコンテキストで、Polling ThreadのSleep管理部２３０が起床される。

具体的には、図８に示すように、ＮＩＣ１３０は、パケットが到着すると、ＨＷ割込（hardIRQ）をhardIRQ８１（ハンドラ）に立ち上げる（図８の<Interrupt>；符号ｄｄ参照）。hardwire８１（ハンドラ）が立ち上がると、Sleep管理部２３０は、Sleep時には、パケット到着時に発生するＨＷ割り込みによって起こされ（図８の<Wakeup>；符号ｅｅ参照）、ＨＷ割り込みを禁止したままPollingを開始する。

ステップＳ３４でSleep管理部は、ＮＩＣ１３０からの割り込みを無効化し（図８の<Enable>；符号ｆｆ参照）、ＣＰＵ動作周波数や動作電圧を高く設定し、データ到着監視部２１０の PollingをStartさせる。Sleep管理部２３０は、Polling時には、Sleepを開始する際に、Polling Threadを停止させ、ＨＷ割り込みを許可してSleepする（図８の<Polling Start >；符号ｇｇ参照）。

（第２実施形態）
図９は、本発明の第２実施形態に係るサーバ内遅延制御システムの概略構成図である。図１と同一構成部分には、同一符号を付して重複箇所の説明を省略する。
図９に示すように、サーバ内遅延制御システム１０００Ａは、ＨＷ１１０、ＯＳ１４０、user space１６０上に配置されたサーバ内遅延制御装置３００、データ処理ＡＰＬ１を有する。

サーバ内遅延制御装置３００は、図１のサーバ内遅延制御装置２００のデータ到着監視部２１０、データ到着通知部２２０およびSleep管理部２３０の各機能部（以下、各機能部という）に加えて、ロジック管理部３１０を備える。
ロジック管理部３１０は、アプリケーションの特性情報およびスレッドの処理情報を収集し、収集した情報をもとに、時間帯によって負荷が変動し、処理方法および処理速度が変動するようなアプリケーションの場合に、データ到着監視部２１０、データ到着通知部２２０、Sleep管理部２３０のうち、少なくともいずれか一つの機能部の処理ロジックを変更する。

<ロジック管理部３１０>
ロジック管理部３１０は、図１のサーバ内遅延制御装置２００の各機能部について複数の処理ロジックが考えられる場合、動的に処理ロジックを選択して各機能部に通知する。
ロジック管理部３１０は、時間帯によって負荷が変動し、処理方法や処理速度が変動するようなアプリケーションの場合に、Polling Thread内の各機能部の処理ロジックを変更して受信処理方法を変えることで、低遅延性および省電力性を保つ。

ロジック管理部３１０は、特性情報収集部３１１と、ロジック配信部３１２の２つの機能部からなる。
特性情報収集部３１１は、アプリケーションやPolling Threadから、アプリケーションやトラフィックの特性を収集する。特性情報収集部３１１は、時間的に変動する特性に適したロジックを適宜決定するために必要な情報を収集する。

ロジック配信部３１２は、特性情報収集部３１１が収集したアプリケーションやトラフィックの特性情報をもとに、各機能部に適したロジックを適宜決定し、各機能部に配信する。ロジック配信部３１２は、各機能部を、時間的に変動する特性に適したロジックで動作するように命令する。
以下、特性情報収集部３１１およびロジック配信部３１２について動作説明図を参照して詳細に説明する。

<特性情報収集部３１１>
まず、特性情報収集部３１１について説明する。
図１０は、特性情報収集部３１１の動作説明図である。
特性情報収集部３１１は、アプリケーションやPolling Threadから特性情報を収集する。
特性情報収集部３１１は、アプリケーションの特性情報やPolling Threadの処理情報を収集してロジック配信部３１２に受け渡す。アプリケーションの特性情報やPolling Threadの処理情報は、各機能部のロジックを決定するための情報である。収集した情報は、各機能部に適したロジックを決定するために利用される。

アプリケーションの特性情報例について説明する。
アプリケーションの特性情報例として、「アプリケーション内パケット処理方法の変化」があげられる。
例えば、Application Logicの負荷が大きくなり、パケット処理方法が逐次処理からバッチ処理に変更された場合に、特性情報収集部３１１は、その情報を収集する（図１０の符号ｈｈ参照）。この情報は、例えばデータ到着通知部２２０の処理ロジックを「データ到着時に逐次アプリケーションに通知」から「データがＫ個到着してからアプリケーションに通知」に変更するために使われる。

Polling Threadの処理情報例について説明する。
Polling Threadの処理情報例として、「Sleepに入ってから、起床されるまでの時間の統計情報」があげられる。
例えば、Sleepに入ってから即起床されるケースが増えた場合、その情報を収集する（図１０の符号ｉｉ参照）。この情報は、例えばSleep管理部２３０がSleepを開始するロジックを「パケット未着時に即Sleep」から「パケット未着になってから一定時間後にSleep」に変更するために使われる。

上記、各機能部のロジックを決定するための情報として、アプリケーションの特性情報やPolling Threadの処理情報について例示したが、アプリケーションや Polling Threadなどの同一サーバ内からの特性情報にとどまらず、別システムから、情報を受け取ってロジックの選択に活用してもよい。
例えば、サーバ内遅延制御装置３００がｖＲＡＮ（virtualized Radio Access Network）におけるｖＤＵ（virtualized Distributed Unit）サーバやｖＣＵ（virtualized Centralized Unit）サーバに搭載された場合、上位のコントローラであるＲＩＣ（RAN Intelligent Controller）からサービス提供状況の情報を受け取って、ロジックの選択に役立てることができる。

<ロジック配信部３１２>
次に、ロジック配信部３１２について説明する。
図１１は、ロジック配信部３１２の動作説明図である。
ロジック配信部３１２は、特性情報収集部３１１が収集した情報をもとに、各機能部に適したロジックを決定して配信し、各機能部のロジックを変更させる。

・データ到着監視ロジックの配信例
アプリケーションの遅延要件が弱くなった場合や、データの到着頻度が低くなった場合に、省電力性のためにデータ到着監視頻度を落としてもよい場合がある。この時、「busy loopによるデータ到着監視」から、例えば「１μｓに１回データ到着監視」に変更させる（図１１の符号ｊｊ参照）。

・データ到着通知ロジックの配信例
アプリケーションの処理が逐次処理からバッチ処理に変更された場合、低遅延性および省電力性のために、データ到着通知もバッチして行った方がよい場合がある。この時、「データ到着をアプリケーションに逐次通知」というロジックから「Ｋ個のデータが到着してからアプリケーションにデータ到着を通知」というロジックに変更させる（図１１の符号ｋｋ参照）。

・Sleep開始ロジックの配信例
Sleepしてから即割り込みによって起床することが多くなってきた場合、割り込み過多による遅延増大・消費電力上昇を防ぐために「データ未着時に即sleep」というロジックから「データ未着になってＴμｓ後にSleep」というロジックに変更させる（図１１の符号ｌｌ参照）。

以下、上述のように構成されたサーバ内遅延制御システム１０００Ａの動作を説明する。
［サーバ内遅延制御システム１０００Ａの全体動作］

<設定事項>
ロジック管理部３１０は、Polling Threadとは別のＣＰＵ上で動作する。
Polling Thread内の各機能部とロジック管理部３１０の間には、それぞれ共有メモリが存在する。

<動作１>
ＮＩＣ１３０は、パケットを受信した際、ＤＭＡ（Direct Memory Access）によりＣＰＵを介さずに、直接Ring Buffer（メインメモリ上のバッファ）にパケットをコピーする。なお、このRing Bufferは、User SpaceのPolling Threadから、OSカーネルを介さずに直接アクセスが可能であるよう、あらかじめ設定する。

ＮＩＣ１３０は、Polling Threadが駆動するＣＰＵに対して割込を起こし、そのＣＰＵはハードウェア割り込みのコンテキストでPolling Threadに対して起床の通知を行い、Sleep管理部２３０を起床させる。
以降、当該ＣＰＵではPolling Threadが動作する。

Sleep管理部２３０は、ＣＰＵの周波数を高く設定し、当該ＣＰＵへの割り込みを禁止する。ＣＰＵ周波数は、ＣＰＵgovernorの設定によりUser Spaceからでも変更が可能である。

Sleep管理部２３０は、Sleepに入ってから起床するまでの時間を記録し、ロジック管理部３１０との共有メモリに格納する。

Sleep管理部２３０は、データ到着監視部２１０にPollingの開始を指示する（Sleep管理部２３０から、データ到着監視部２１０の処理にあたる関数を呼び出す）。この時、Sleep管理部２３０は、パケット未着になってからSleepするまでの時間情報をロジック管理部３１０との共有メモリ領域から読み出し、その値を引数として指定して、データ到着監視部２１０の処理にあたる関数を呼び出す。

データ到着監視部２１０は、ロジック管理部３１０との共有メモリを参照し、到着確認間隔を読み出す。この到着確認間隔で、パケットがＤＭＡされるRing Buffer領域に対して到着確認を行い、パケットが届いている場合にはそのパケットのアドレス情報（ポインタ）をデータ到着通知部２２０に伝達する。

データ到着通知部２２０は、データ到着監視部２１０から伝達されたポインタ情報の数が、ロジック管理部３１０との共有メモリに書かれているバッチ数に達しているかを確認する。ポインタ情報の数が、ロジック管理部３１０との共有メモリに書かれているバッチ数に達している場合、下記の動作に移る。そうでない場合、上記、データ到着監視部２１０の到着確認動作に戻りループで処理が実行される。

データ到着通知部２２０は、アプリケーションとPolling Threadの共有メモリにアドレス情報を格納し、アプリケーションが動作するスレッドを起こし、そのスレッド内で処理を実行する。
アプリケーションロジック（データ処理ＡＰＬ１）が、同一スレッドで実行されるように運用者が設定していた場合、Polling Thread内で処理を行う。

上記において、パケット未着の状態で、引数として指定された時間が経過した場合、データ到着監視部２１０は、Sleep管理部２３０を呼び出す。すなわち、データ到着監視部２１０がreturnを行うことで、Sleep管理部２３０に処理が戻る。データ到着監視部２１０は、関数をreturnする直前、Polling Thread動作中の平均パケット到着頻度をロジック管理部３１０との共有メモリに書き込む。

Sleep管理部２３０は、ＣＰＵ周波数を下げ、当該ＣＰＵへの割り込みを有効化して、Polling ThreadをSleep状態に落とす。

アプリケーション（データ処理ＡＰＬ１）は、負荷などに応じてバッチ処理数の変更をした場合、ロジック管理部３１０との共有メモリに適宜書き込む。アプリケーションがPolling Threadと別スレッドで動作する場合、アプリケーションとロジック管理部３１０の間にも別途共有メモリを事前に設定しておく。

<動作２>
以下はPolling Threadとは別ＣＰＵ上で動作し、時間的に独立して動作する。
以下の<動作２>と、上記<動作１>は並列して発生しうる。
特性情報収集部３１１は、Polling Thread内機能部との各共有メモリを巡回して監視し、共有メモリに書き込みが行われていた場合には、以下の処理を実行する。

データ到着監視部２１０との共有メモリに、データ到着頻度が書き込まれていて、その値が現在のデータ到着確認間隔よりも小さかった場合、そのデータ到着頻度を新しいデータ到着確認間隔として設定し、ロジック配信部３１２を呼び出す（ロジック配信部３１２にあたる関数を呼び出す）。

ロジック配信部３１２は、データ到着監視部２１０との共有メモリに、新たなデータ到着確認間隔を書き込む。

アプリケーションとの共有メモリに、バッチ数が書き込まれていた場合、そのバッチ数を新たなデータ到着通知バッチ数として設定し、ロジック配信部３１２を呼び出す（ロジック配信部３１２にあたる関数を呼び出す）。

ロジック配信部３１２は、データ到着通知部２２０との共有メモリに、新たなデータ到着通知バッチ数を書き込む。

Sleep管理部２３０との共有メモリに、Sleepしてから起床するまでの時間が書き込まれていて、その値が所定閾値（例えば５μｓ）よりも小さかった場合（閾値はシステムによって異なるため、事前の設定などが必要）、パケット未着になってからSleepに入るまでの時間を５μｓ伸ばすことを決定し、ロジック配信部３１２を呼び出す（ロジック配信部３１２にあたる関数を呼び出す）。

ロジック配信部３１２は、Sleep管理部２３０との共有メモリに新たな「パケット未着になってからSleepに入るまでの時間」を書き込む。
以上でサーバ内遅延制御システム１０００Ａの全体動作の説明を終了する。

［ロジック管理部３１０の動作］
次に、図１２乃至図１７に示すフローチャートおよび動作説明図を参照してロジック管理部３１０の処理例について説明する。

<データ到着監視部２１０へのロジック変更例>
まず、ロジック管理部３１０の処理例として、データ到着監視部２１０へのロジック変更例について説明する。
図１２は、データ到着監視部２１０へのロジック変更の処理フローチャートである。図１３は、その動作説明図である。図１１と同一構成部分には同一番号を付している。
図１２のフローにおいて、ステップＳ４１でデータ到着監視部２１０は、パケット到着頻度を取得し、定期的に特性情報収集部３１１に通知する（図１３の符号ｍｍ参照）。例えば、データ到着監視部２１０は、PollingをSleepさせるタイミングで特性情報収集部３１１にパケット到着頻度を伝達する。

ステップＳ４２で特性情報収集部３１１は、パケット到着頻度と現在の到着監視間隔を比較する。パケット到着頻度＜到着監視間隔の場合（Ｓ４３：Ｎｏ）、ステップＳ４６に進む。

ステップＳ４３で特性情報収集部３１１は、パケット到着頻度≧到着監視間隔の場合（Ｓ４３：Ｙｅｓ）、ステップＳ４４で特性情報収集部３１１は、到着監視間隔を広げること（例えば、１μｓ広げること）を決定し、ロジック配信部３１２にロジックの変更を伝達する（図１３の符号ｎｎ参照）。

ステップＳ４５でロジック配信部３１２は、データ到着監視部２１０にロジックを配信し、到着監視間隔を広くさせて本フローの処理を終了する。

一方、上記ステップＳ４３でパケット到着頻度＜到着監視間隔の場合（Ｓ４３：Ｎｏ）、ステップＳ４６で特性情報収集部３１１は、到着監視間隔を狭くすることを決定し、ロジック配信部３１２にロジックの変更を伝達する。例えば、特性情報収集部３１１は、到着監視間隔を、１μｓ狭くすることを伝達する（図１３の符号ｎｎ参照）。

ステップＳ４７でロジック配信部３１２は、データ到着監視部２１０にロジックを配信し、到着監視間隔を狭くさせて本フローの処理を終了する。

<データ到着通知部２２０へのロジック変更例>
次に、ロジック管理部３１０の処理例として、データ到着通知部２２０へのロジック変更例について説明する。
図１４は、データ到着通知部２２０へのロジック変更の処理フローチャートである。図１５は、その動作説明図である。図１１と同一構成部分には同一番号を付している。
図１４のフローにおいて、ステップＳ５１でデータ処理ＡＰＬ１（アプリケーション）は、バッチ処理数を変更した場合、そのバッチ処理数をロジック管理部３１０に通知する（図１５の符号ｏｏ参照）。

ステップＳ５２で特性情報収集部３１１は、変更したバッチ処理数でデータ到着を通知することを決定し、ロジックの変更をロジック配信部３１２に伝達する。

ステップＳ５３でロジック配信部３１２は、バッチ処理数をデータ到着通知部２２０に配信し（図１５の符号ｐｐ参照）、変更させて本フローの処理を終了する。

<Sleep管理部２３０へのロジック変更例>
次に、ロジック管理部３１０の処理例として、Sleep管理部２３０へのロジック変更例について説明する。
図１６は、Sleep管理部２３０へのロジック変更の処理フローチャートである。図１７は、その動作説明図である。図１１と同一構成部分には同一番号を付している。
図１６のフローにおいて、ステップＳ６１でSleep管理部２３０は、Sleepに入ってからHardIRQによって起床されるまでの時間を記録し、その情報を特性情報収集部３１１に伝達する（図１７の符号ｑｑ参照）。例えば、Sleep管理部２３０は、起床したタイミングで共有メモリを介して伝達する。

ステップＳ６２で特性情報収集部３１１は、Polling ThreadがSleepに入ってから起床されるまでの平均時間を算出し、性能に悪影響が出ているか判定する。性能に悪影響が出ているか否かの判断は、システムによって異なるが、例えば５μｓをSleepに入ってから起床されるまでの平均時間とする。

ステップＳ６３で特性情報収集部３１１は、Sleepに入ってから起床されるまでの平均時間５μｓであるか否かを判別する。
Sleepに入ってから起床されるまでの平均時間５μｓの場合（Ｓ６３：Ｙｅｓ）、ステップＳ６４で特性情報収集部３１１は、パケット未着になってからSleepに入るまでの時間を長くすること（例えば５μｓ長くすること）を決定し、ロジック配信部３１２にロジックの変更を伝達する（図１７の符号ｒｒ参照）。

ステップＳ６５でロジック配信部３１２は、データ到着通知部２２０にロジックを配信し、パケット未着になってからSleepに入るまでの時間を変更させて本フローの処理を終了する。

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

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

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

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

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

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

［適用例］
<ＶＭ構成への適用例>
本発明は、ＶＭ（Virtual Machine）構成におけるhost、および、guestに配置されたPolling Threadのそれぞれに適用することができる。
このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、HostOSとGuestOSとのいずれのOSにおいても、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。

<コンテナ構成への適用例>
本発明は、コンテナ構成において配置されたPolling Threadにも適用することができる。
コンテナなどの仮想サーバ構成のシステムにおいて、アプリケーションを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。

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

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

［効果］
以上説明したように、第１実施形態に係るサーバ内遅延制御装置は、ユーザ空間（User space）に配置され、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置２００（図１参照）であって、デバイス（ＮＩＣ１３０）の受信キューをポーリングにより監視し、パケットが到着している場合は、データを取得するデータ到着監視部２１０と、データ到着監視部２１０が取得したデータをアプリケーションプログラム（データ処理ＡＰＬ１）に通知して受け渡すデータ到着通知部２２０と、パケットが所定期間到着しない場合はスレッド（Polling Thread）をスリープ（Sleep）させ、かつ、パケット到着時はハードウェア割込（hardIRQ）により当該スレッド（Polling Thread）のスリープ解除を行うSleep管理部２３０と、を備え、Sleep管理部２３０は、アプリケーションプログラムの特性に基づいて、ハードウェア割込（hardIRQ）を許可してスリープ（Sleep）するタイミングを制御することを特徴とする。

このようにすることで、サーバ内遅延制御装置２００は、ＮＷ遅延発生の主要因であるパケット処理のソフトウェア割込（softIRQ）を停止し、サーバ内遅延制御装置２００のデータ到着監視部２１０がパケット到着を監視するthreadを実行し、パケット到着時に、pollingモデル（softIRQなし）によりパケット処理を行う。そして、Sleep管理部２３０が、パケットが所定期間到着しない場合はスレッド（Polling Thread）をスリープ（Sleep）させることで、スレッド（Polling Thread）はパケット未到着時にスリープ（Sleep）する。Sleep管理部２３０は、パケット到着時はハードウェア割込（hardIRQ）によりスリープ解除を行う。さらに、Sleep管理部２３０は、アプリケーションプログラムの特性に基づいて、ハードウェア割込（hardIRQ）を許可してスリープ（Sleep）するタイミングを制御する。
これにより、下記（１）～（４）の効果を奏する。

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

（２）サーバ内遅延制御装置２００におけるPolling Threadは、pollingモードでパケット到着を監視している。パケット到着を監視するPolling Threadは、パケット到着がない間はスリープ（Sleep）する。パケット到着がない場合は、スリープによってＣＰＵを使用しないので、省電力の効果を得ることができる（「Polling Threadのスリープ管理による、不要なＣＰＵ使用を削減と省電力化の達成」）。

（３）さらに、アプリケーションプログラムの特性に合わせて受信処理の方式を変更することができ、特性がそれぞれ異なるアプリケーションプログラムに対しても低遅延性および省電力性を両立することができる（「アプリケーションプログラムに合わせた低遅延性および省電力性の達成」）。

（４）ユーザ空間（User space）でデータ受信処理が定義されるため、アプリケーションプログラムの特性に合わせて受信処理の方式を変更することができる。
本発明を、ＤＰＤＫのように、ユーザ空間（User space）にPolling Threadがある場合に適用することができる。

このように、サーバ内遅延制御装置２００（図１参照）は、ユーザ空間（User space）にPolling Threadがある場合において、パケット転送処理を行うPolling Threadのスリープ管理を行うことで、低遅延と省電力を両立させることができる。さらに、アプリケーションプログラムの特性が異なるアプリケーションに対しても低遅延性・省電力性を両立することができる。

サーバ内遅延制御装置２００において、Sleep管理部２３０は、パケットが未着になってからの経過時間とアプリケーションプログラムの特性に適した所定の時間とを比較し、パケットが未着になってからの経過時間がアプリケーションプログラムの特性に適した時間以上の場合、ハードウェア割り込みを有効化し、スレッドをスリープさせることを特徴とする。

このようにすることにより、Sleep管理部２３０は、アプリケーションプログラムの特性に応じ、ＨＷ割り込みを許可してSleepするタイミングを制御する。例えば、Sleep管理部２３０は、Polling時に、ドライバの受信キューが空になっても、直ちにパケットが到着するようなアプリケーションプログラムの場合にはPollingを続けることもできる。アプリケーションプログラムの特性やトラフィック特性に応じた更なる低遅延化・省電力化を実現できる。

サーバ内遅延制御装置２００において、データ到着監視部２１０は、アプリケーションプログラムの特性に基づく所定のタイミングで、デバイスの受信キューにデータが到着しているかを確認することを特徴とする。

このようにすることにより、アプリケーションプログラムの特性やトラフィック情報に応じて、Pollingによって刈取を行う頻度の制御を行うことで、アプリケーションプログラムの特性やトラフィックに応じた更なる低遅延化および省電力化を実現できる。

サーバ内遅延制御装置２００において、データ到着監視部２１０は、所定時間の停止後、デバイスの受信キューにデータが到着しているかを確認することを特徴とする。

このようにすることにより、データ到着監視部２１０は、アプリケーションプログラムの遅延要件が厳しくない場合や、パケットの到着間隔が短くない場合に、Pollingに一時停止を挟む（例えば、所定時間の停止後、デバイスの受信キューにデータが到着しているかを確認する）ことで、ＣＰＵサイクル数を削減しながら受信監視を行うことができ、省電力化を図ることができる。

サーバ内遅延制御装置２００において、データ到着通知部２２０は、アプリケーションプログラムの特性が、パケットを逐次処理する特性の場合には、パケット到着時に直ちに通知し、パケットをバッチ処理する特性の場合には、所定数のパケットが到着した際に通知することを特徴とする。

このようにすることにより、アプリケーションプログラムの特性に合わせて到着通知方式を選択することができ、アプリケーションプログラムの特性に応じた更なる低遅延化を実現できる。

サーバ内遅延制御装置２００において、データ到着通知部２２０は、パケット処理機能を有し、アプリケーションプログラムの特性に応じて、パケット処理機能を実行し、当該パケット処理機能を実行した場合、アプリケーションプログラムに通知しないことを特徴とする。

このようにすることにより、アプリケーションプログラムが単純である場合、通知するのではなく、パケット処理をする機能を具備することで、到着通知のオーバーヘッドを削減してパケットを処理することもできる。アプリケーションプログラムの特性に応じた更なる低遅延化を実現できる。

第２実施形態に係るサーバ内遅延制御装置３００（図９参照）において、アプリケーションプログラムの特性情報およびスレッドの処理情報を収集し、収集した情報をもとに、時間帯によって負荷が変動し、処理方法および処理速度が変動するようなアプリケーションプログラムの場合に、データ到着監視部２１０、データ到着通知部２２０、Sleep管理部２３０のうち、少なくともいずれか一つの機能部の処理ロジックを変更するロジック管理部３１０を備えることを特徴とする。

このようにすることにより、ロジック管理部３１０は、アプリケーションプログラムの特性およびスレッドの処理に合わせてPolling Threadの各機能部（データ到着監視部２１０、データ到着通知部２２０、Sleep管理部２３０）の処理ロジックを動的に決定し、各機能部に配信する。これにより、特性が動的に変動するアプリケーションに対しても、変動する特性に合わせた処理ロジックで各機能部を動作させることで、受信処理の低遅延性および省電力性を保つことができる。

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

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

１ データ処理ＡＰＬ（アプリケーションプログラム）
１０ ＨＷ
７０ Guest OS
７２ Ring Buffer（リングバッファ）
７４ プロトコル処理部
１１０ ＨＷ
１３０ ＮＩＣ（物理NIC）(デバイス)
１４０ ＯＳ
１６０ user space（ユーザ空間）
２００，３００ サーバ内遅延制御装置（Polling Thread）
２１０ データ到着監視部（各機能部）
２２０ データ到着通知部（各機能部）
２３０ Sleep管理部（各機能部）
３１０ ロジック管理部
３１１ 特性情報収集部
３１２ ロジック配信部
１０００ サーバ内遅延制御システム

Claims (3)

1. ユーザ空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置であって、
   デバイスの受信キューをポーリングにより監視し、パケットが到着している場合は、データを取得するデータ到着監視部と、
   前記データ到着監視部が取得したデータをアプリケーションプログラムに通知して受け渡すデータ到着通知部と、
   パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、を備え、
   前記スリープ管理部は、アプリケーションプログラムの特性に基づいて、前記ハードウェア割込を許可して前記スリープするタイミングを制御する
   ことを特徴とするサーバ内遅延制御装置。
2. ユーザ空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置のサーバ内遅延制御方法であって、
   前記サーバ内遅延制御装置は、
   デバイスの受信キューをポーリングにより監視し、パケットが到着している場合は、データを取得するステップと、
   取得したデータをアプリケーションプログラムに通知して受け渡すステップと、
   パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うとともに、
   前記アプリケーションプログラムの特性に基づいて、前記ハードウェア割込を許可して前記スリープするタイミングを制御するステップと、を実行する
   ことを特徴とするサーバ内遅延制御方法。
3. コンピュータを、請求項１に記載のサーバ内遅延制御装置として機能させるためのプログラム。
   

Images