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

［割込モデルによるパケット転送（汎用ＶＭ構成の例）］
特許文献１には、仮想マシン内で動作するGuest OSが自仮想マシン外に存在する、外部プロセスとの専用仮想通信路を構築する仮想通信路構築システムが記載されている。特許文献１に記載の技術は、virtioで接続されたHost OSとGuest OSにおいて、virtio-net関連のメモリコピー回数を減らすことにより、パケット転送処理を高速化する。

図９は、汎用Linux kernel（登録商標）およびＶＭ構成のサーバ仮想化環境における、割込モデルによるパケット転送を説明する図である。
ＨＷ１０は、NIC（Network Interface Card）１１（物理NIC）(インターフェイス部)を有し、Host OS２０、仮想マシンを構築するハイパーバイザーであるＫＶＭ３０、仮想マシン（ＶＭ１，ＶＭ２）４０、およびGuest OS５０により構築された仮想通信路を経由してuser space（ユーザスペース）６０上のパケット処理ＡＰＬ（Application）１との間でデータ送受信の通信を行う。以下の説明において、図９の太矢印に示すように、パケット処理ＡＰＬ１が、ＨＷ１０からのパケットを受け取るデータの流れをＲｘ側受信と称し、パケット処理ＡＰＬ１が、ＨＷ１０にパケットを送信するデータの流れをＴｘ側送信と称する。

Host OS２０は、kernel２１、Ring Buffer２２、およびDriver２３を有し、kernel２１は、kernel threadであるvhost-netモジュール２２１と、tapデバイス２２２と、仮想スイッチ(br)２２３と、を有する。

tapデバイス２２２は、仮想ネットワークのカーネルデバイスであり、ソフトウェアでサポートされている。仮想マシン（ＶＭ１）４０は、仮想ブリッジ(bridge)に作成される仮想スイッチ(br)２２３を介してGuest OS５０とHost OS２０が通信できる。tapデバイス２２２は、この仮想ブリッジに作成されるGuest OS５０の仮想NIC（vNIC）と繋がるデバイスである。

Host OS２０は、Guest OS５０の仮想マシン内で構築された構成情報（共有バッファキューの大きさ、キューの数、識別子、リングバッファへアクセスするための先頭アドレス情報など）をvhost-netモジュール２２１にコピーし、仮想マシン側の端点の情報をHost OS２０内部に構築する。このvhost-netモジュール２２１は、virtioネットワーキング用のカーネルレベルのバックエンドであり、virtioパケット処理タスクをユーザ領域（ユーザ空間）からkernel２１のvhost-netモジュール２２１に移すことで仮想化のオーバーヘッドを低減できる。

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５３１を備える。

具体的には、ＰＣＩ（Peripheral Component Interconnect）デバイスとして仮想マシン内にコンソール、ファイル入出力、ネットワーク通信それぞれに対しvirtioデバイスが存在し（コンソールはvirtio-console、ファイル入出力はvirtio-blk、ネットワークはvirtio-netと呼ばれるデバイスとそれに対応するＯＳが持つドライバがvirtioキューで定義されている）、Guest OS起動時に、Guest OSと相手側とのデータの受け渡し端点（送受信端点）を２つ作り、データ送受信の親子関係を構築する。多くの場合、親子関係は仮想マシン側（子側）とGuest OS（親側）で構成する。

子側は仮想マシン内のデバイスの構成情報として存在し、それぞれのデータ領域のサイズと必要とする端点の組み合わせの個数、デバイスの種別を親側に要求する。親側は子側の要求に従い、必要な分のデータを貯蓄し受け渡すための共有バッファキューのためのメモリを割り当て確保し、子側がアクセスできるようにそのアドレス番地を子側に返す。データの受け渡しに必要とされる共有バッファキューのオペレーションについては、virtioではすべて共通であり、親側、子側両方合意済みとして実行される。さらに共有バッファキューの大きさも両方合意済みとする（つまりデバイスごとに決まっている）。これにより、子側にアドレスを伝えるだけで、親側、子側の双方が共有するキューを操作することが可能となる。

virtioにおいて用意する共有バッファキューは単一方向用として用意されるため、例えば、virtio-netデバイスと呼ばれる仮想ネットワークデバイスでは送信用、受信用、コントロール用の３つのRing Buffer５２で構成される。親と子の通信は、共有バッファキューへの書き込みとバッファ更新通知により実現し、Ring Buffer５２に書き込んだ後、相手側に通知する。相手側は通知を受けると、どの共有バッファキューにどの程度新規のデータが入っているのかをvirtioの共通オペレーションを利用して確認し、新規のバッファ領域を取り出す。これにより、親から子または子から親へのデータの受け渡しが成立する。

以上のように、親子でお互いデータ交換用のRing Buffer５２とそれぞれのリングバッファ用のオペレーション方法（virtioで共通）を共有することにより、ハードウェアエミュレーションを必要としない、Guest OS５０と外部との通信を実現する。これにより、従来のハードウェアエミュレーションに比べ、Guest OS５０と外部とのデータの送受信を高速に実現することが可能である。

仮想マシン内のGuest OS５０が外部と通信する場合は、子側が外部と接続し、子側が外部と親側の中継役としてデータを送受信する必要がある。例えば、Guest OS５０とHost OS２０間の通信がその例の１つである。ここで、外部をHost OS２０とした場合、既存の通信方法として２パターン存在する。

第１の方法（以下、外部通信方式１と呼ぶ）は、仮想マシン内に子側の端点を構築し、Guest OS５０と仮想マシン間の通信と、Host OS２０が提供する通信端点（通常、tap／tunデバイスと呼ばれる）を、仮想マシン内で接続する。この接続により以下のとおりの接続を構築し、Guest OS５０からHost OS２０への通信を実現する。

このとき、Guest OS５０はtapドライバやHost OS２０が動作するカーネル空間というメモリ領域とは異なる権限を持つユーザ空間であるメモリ領域で動作している。このため、Guest OS５０からHost OS２０への通信には最低１回メモリコピーが発生してしまう。

第２の方法（以下、外部通信方式２と呼ぶ）は、これを解決する手段として、vhost-netという技術が存在する。vhost-netでは一度仮想マシン内で構築された親側の構成情報（共有バッファキューの大きさ、キューの数、識別子、リングバッファへアクセスするための先頭アドレス情報など）をHost OS２０内部のvhost-netモジュール２２１にコピーし、子側の端点の情報をホスト内部に構築する。この構築により、共有バッファキューの操作をGuest OS５０とHost OS２０間で直接実施することを可能とする技術である。これにより、コピーは実質０回で済むようになり、virtio-netに比べ、コピー回数が１回少ない分、外部通信方式１と比較し、より高速にデータ転送が実現できる。

このように、virtioで接続されたHost OS２０とGuest OS５０において、virtio-net関連のメモリコピー回数を減らすことにより、パケット転送処理を高速化することができる。

なお、kernel v4.10(2017.2～)以降、tapインターフェイスの仕様変更があり、tapデバイスから挿入されたパケットは、tapデバイスへパケットコピーを行った処理と同一コンテキスト内で完結されるようになった。これにより、ソフトウェア割込（softIRQ）の発生がなくなった。

［ポーリングモデルによるパケット転送（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）がある。ＳＰＰは、ＶＭ間に共有メモリを用意し、各ＶＭが同じメモリ空間を直接参照できる構成にすることで、仮想化層でのパケットコピーを省略する。また、物理ＮＩＣと共有メモリ間のパケットのやり取りには、ＤＰＤＫを用いて高速化を実現する。ＳＰＰは、各ＶＭのメモリ交換の参照先を制御することで、パケットの入力先、出力先をソフトウェア的に変更することができる。この処理によって、ＳＰＰは、ＶＭ間やＶＭと物理ＮＩＣ間の動的な接続切替を実現する。

特許文献２には、複数の仮想マシンを動作させる仮想マシンの接続制御システムが記載されている。すなわち、仮想マシンを含むリソースを管理するＳＰＰ（Soft Patch Panel）を備えるＳＰＰサーバと、ＳＰＰサーバと連携し、前記仮想マシンを接続するためのリソース割り当ておよび経路設定をＧＵＩ（Graphical User Interface）操作により行うＧＵＩ端末と、を備えるサーバ内遅延制御システムが記載されている。特許文献２に記載の技術は、ＳＰＰの操作を抽象化し、ＧＵＩにより直感的に操作することができる仮想マシンの接続制御システムを提供する。

図１０は、OvS-DPDK（Open vSwitch with DPDK）の構成における、ポーリングモデルによるパケット転送を説明する図である。図９と同一構成部分には、同一符号を付して重複箇所の説明を省略する。
図１０に示すように、Host OS２０は、パケット処理のためのソフトウェアであるOvS-DPDK７０を備え、OvS-DPDK７０は、仮想マシン（ここではＶＭ１）に接続するための機能部であるvhost-user７１と、ＮＩＣ（ＤＰＤＫ）１１（物理ＮＩＣ）に接続するための機能部であるdpdk(PMD)７２と、を有する。
また、パケット処理ＡＰＬ１Ａは、Guest OS５０区間においてポーリングを行う機能部であるdpdk(PMD)２を具備する。すなわち、パケット処理ＡＰＬ１Ａは、図９のパケット処理ＡＰＬ１にdpdk(PMD)２を具備させて、パケット処理ＡＰＬ１を改変したＡＰＬである。

ポーリングモデルによるパケット転送は、ＤＰＤＫの拡張として、共有メモリを介してゼロコピーでHost OS２０とGuest OS５０間、および、Guest OS５０間のパケットコピーを高速に行うＳＰＰにおいて、ＧＵＩにより経路操作を可能とする。

［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７１は、当該パケットを認知する。なお、図１２の楕円で囲んで示すhardwire８１は、機能部ではなくハンドラを表記する。

netif_rx８２は、実際に処理をする機能であり、hardwire８１（ハンドラ）が立ち上がると（図１２の符号ｆ参照）、poll_list８６に、ハードウェア割込（hardIRQ）の中身の情報の１つである、NIC１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を保存して、キューの刈取り（バッファに溜まっているパケットの中身を参照して、そのパケットの処理を、次に行う処理を考慮してバッファから該当するキューのエントリを削除する）を登録する（図１２の符号ｇ参照）。具体的には、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８９に処理をまわす（図１２の符号ｏ）。

特開２０１５－１９７８７４９号公報 特開２０１８－３２１５６号公報

Soft Patch Panel, ［online］,［令和３年２月４日検索］,インターネット 〈 URL : http://dpdk.org/browse/apps/spp/〉 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）の競合に起因し、ｍｓオーダのＮＷ遅延が発生する。

一方、ポーリングモデルは、ＣＰＵを占有して通信キューをポーリングし、パケット到着時に即時刈取る。ポーリングモデルは、転送遅延を小さくすることが可能であるものの、ＡＰＬにポーリング機能を具備させる必要が生じるので、ＡＰＬに改変が必要である。
例えば、図１０に示すように、ポーリングモデルによるパケット転送は、パケット処理ＡＰＬ１にGuest OS５０区間においてポーリングを行う機能部であるdpdk(PMD)２を具備させる必要があり、パケット処理ＡＰＬ１の改変が必要となる。

このような背景を鑑みて本発明がなされたのであり、本発明は、低遅延なパケット処理を実現することができ、かつ、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことを課題とする。

前記した課題を解決するため、本発明は、サーバ内遅延制御装置であって、OSが、カーネルと、前記OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を有し、前記カーネル内に、所定指定間隔のタイマ割込を受付けるとともに、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、前記サーバ内遅延制御装置は、前記タイマ割込をハードウェア割込とし、当該タイマ割込を契機に前記ポールリストのパケットの有無を確認して当該ポールリストを監視するパケット到着監視部と、パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、を備えることを特徴とするサーバ内遅延制御装置とした。

本発明によれば、低遅延なパケット処理を実現することができ、かつ、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。

本発明の第１実施形態に係るサーバ内遅延制御システムの概略構成図である。 本発明の第１実施形態に係るサーバ内遅延制御システムのパケット処理概要を説明する図である。 本発明の第１実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のＲｘ側動作を示すフローチャートである。 本発明の第２実施形態に係るサーバ内遅延制御システムのパケット処理の詳細を説明する図である。 本発明の第２実施形態に係るサーバ内遅延制御システムのNAPIによる処理を示すフローチャートである。 本発明の各実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。 汎用Linux kernelおよびＶＭ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システムを適用した例を示す図である。 コンテナ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システムを適用した例を示す図である。 汎用Linux kernelおよびＶＭ構成のサーバ仮想化環境における、割込モデルによるパケット転送を説明する図である。 OvS-DPDKの構成における、ポーリングモデルによるパケット転送を説明する図である。 Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理の概略図である。 図１１の破線で囲んだ箇所におけるNew API(NAPI)によるＲｘ側パケット処理の概要を説明する図である。

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

<ＨＷ１０Ａ>
ＨＷ１０Ａは、NIC１１（物理NIC）(インターフェイス部)と、timer１２と、を有する。
timer１２は、所定のタイマ間隔でハードウェア割込によるタイマ割込を発生する。timer１２は、指定した間隔で処理を実行することが可能なタイマ割込を発生する。例えば、kernelにはhrtimersという仕組みがあり、このhrtimersを用いてもよい。

<OS７０>
OS７０は、kernel１７１、Ring Buffer７２、およびDriver７３を有し、kernel１７１は、サーバ内遅延制御装置１００、poll_list１８６、およびプロトコル処理部７４を有する。

本実施形態では、kernel１７１が、サーバ内遅延制御装置１００を備える関係で、図１１に示すkernel７１と区別して新たな番号を付している。kernel１７１は、サーバ内遅延制御装置１００が設置されている以外は、図１１に示すkernel７１（図１１参照）と同一機能である。ただし、kernel１７１は、livepatch（後記）を用いることで、既存のkernel７１（図１１参照）を改造（新しくビルド）することなく、実現が可能である。

kernel１７１は、OS７０（例えば、Host OS）の基幹部分の機能であり、ハードウェアの監視やプログラムの実行状態をプロセス単位で管理する。ここでは、kernel１７１は、パケット処理ＡＰＬ１からの要求に応えるとともに、ＨＷ１０Ａからの要求をパケット処理ＡＰＬ１に伝える。kernel１７１は、パケット処理ＡＰＬ１からの要求に対して、システムコールを介することで処理する。
kernel１７１は、Socket７５を介して、パケット処理ＡＰＬ１へパケットを送信する。Kernel７１は、Socket７５を介してパケット処理ＡＰＬ１からパケットを受信する。

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

Driver７３は、kernel１７１でハードウェアの監視を行うためデバイスドライバである。

poll_list１８６は、ハードウェア割込（hardIRQ）の中身の情報の１つである、NIC１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を保存する。

プロトコル処理部７４は、ＯＳＩ参照モデルが定義するＬ２／Ｌ３／Ｌ４のプロトコル処理を行う。

Socket７５は、kernel１７１がプロセス間通信を行うためのインターフェイスである。Socket７５は、ソケットバッファを有し、データのコピー処理を頻繁に発生させない。

<サーバ内遅延制御装置>
サーバ内遅延制御装置１００は、所定指定間隔のタイマ割込を受付けるとともに、タイマ割込（ハードウェア割込）契機で、ハードウェア割込のコンテキストでパケットの到着を確認し、パケット到着時の刈り取り処理を行う。
サーバ内遅延制御装置１００は、パケット到着監視部１１０と、パケット刈取部１２０と、を備える。

パケット到着監視部１１０は、パケットが到着していないかを監視するためのthreadである。
パケット到着監視部１１０は、タイマ割込をハードウェア割込とし、当該タイマ割込を契機にpoll_list１８６（図２参照）のパケットの有無を確認してpoll_list１８６を監視（poll）する。
パケット到着監視部１１０は、poll_list１８６からRing_Buff７２（図２参照）にパケットが存在するポインタ情報と、NET_DEVICE情報を取得し、パケット刈取部１２０へ当該情報（ポインタ情報およびnet_device情報）を伝達する。パケット到着監視部１１０は、poll_list１８６に複数パケット情報が存在する場合は、複数分伝達する。

パケット刈取部１２０は、パケットが到着している場合は、Ring Buffer７２に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをRing Buffer７２から削除する刈取りを実行する（以下、単にRing Buffer７２からパケットを刈取るという場合がある）。パケット刈取部１２０は、受信した情報をもとにRing_Buff７２からパケットを取り出し、netif_receive_skb８７（図２参照）へパケットを伝達する。
パケット刈取部１２０は、予め保守運用者が設定した期間、受信した情報をもとにRing_Buff７２からパケットを取り出し、netif_receive_skb８７へパケットを伝達する。

図２は、図１のサーバ内遅延制御システム１０００のNew API(NAPI)によるＲｘ側パケット処理の詳細を説明する図である。図１および図１２と同一構成部分には、同一符号を付している。
<Device driver>
図２に示すように、Device driverには、ネットワークインターフェースカードであるNIC１１、NIC１１の処理要求の発生によって呼び出され要求された処理（ハードウェア割込）を実行するハンドラであるhardIRQ８１、およびソフトウェア割込の処理機能部であるnetif_rx１８２が配置される。
また、Device driverには、timer１２を構成するhw_clock１２ａ、hw_clock１２ａの発生によって呼び出され要求された処理（ハードウェア割込）を実行するハンドラであるhardIRQ９１が配置される。

<Networking layer>
Networking layerには、NIC１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を登録するpoll_list１８６、サーバ内遅延制御装置１００、キューを刈取ったパケットを、割込の発生しないソケット通信のためのsk_buff構造体（kernel１７１が、パケットの状態を示す構造体）を作成するnetif_receive_skb８７、およびRing Buffer７２が配置される。

<Protocol layer>
Protocol layerには、パケット処理機能部であるip_rcv８８、arp_rcv８９等が配置される。なお、プロトコル処理は、ip_rcv８８、arp_rcv８９以外にもある。

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

以下、サーバ内遅延制御システム１０００の動作を説明する。
［本発明によるパケット処理概要］
図２の矢印（符号）ｄ～ｇ，ｐ～ｕは、Ｒｘ側パケット処理の流れを示している。
サーバ内遅延制御システム１０００は、<NIC１１契機>によるハードウェア割込と<タイマ割込契機>によるハードウェア割込とを有する。以下、順に説明する。

<NIC１１契機>
NIC１１が、対向装置からフレーム内にパケット（またはフレーム）を受信すると、ＤＭＡ（Direct Memory Access）転送によりＣＰＵを介さずに、Ring Buffer７２に到着したパケットをコピーする（図２の符号ｄ参照）。このRing Buffer７２は、サーバ中のメモリ空間で、Kernel１７１（図１参照）が管理している。

NIC１１は、ハードウェア割込を起動し、poll_list１８６に、Ring Buffer７２に格納したデータのポインタ情報、および、NIC driver情報を登録する。このとき、ソフトウェア割込（NEX_RX_SOFTIRQ）の登録は行わない。これにより、パケット転送処理のソフトウェア割込機能を停止させる。

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

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

netif_rx１８２は、poll_list１８６にnet_deviceを登録するが、図１２のnetif_rx８２とは異なり、ソフトウェア割込（softIRQ）のスケジューリングは行わない。すなわち、netif_rx１８２は、ソフトウェア割込（softIRQ）のスケジューリングは行わない点で、図１２のnetif_rx８２とは異なる。
ここまでで、図２の<Device driver>における、<NIC１１契機>によるハードウェア割込の処理は停止する。

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

本実施形態では、サーバ内遅延制御システム１０００は、図１２に示すsoftIRQ８３およびdo_softirq８４を削除し、代わりに図２に示す<Networking layer>のサーバの中にあるメモリ空間に、サーバ内遅延制御装置１００を設ける。

図２に示す<Networking layer>において、サーバ内遅延制御装置１００のパケット到着監視部１１０は、poll_list１８６を監視（poll）し（図２の符号ｐ参照）、パケット到着有無を確認する。

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

サーバ内遅延制御装置１００のパケット刈取部１２０は、パケットが到着している場合は、Ring Buffer７２からパケットを刈取る（図２の符号ｒ参照）。
パケット刈取部１２０は、受信した情報をもとにRing_Buff７２からパケットを取り出し、netif_receive_skb８７へパケットを伝達する（図２の符号ｕ参照）。

<タイマ割込契機>
クロックデバイスであるtimer１２（通常はＣＰＵに搭載）は、hw_clock１２ａを用いて指定時間を計時し、ハードウェア割込（hardIRQ）をhardIRQ９１（ハンドラ）に立ち上げる（図２の符号ｓ参照）。この指定時間は、予め運用者が指定した時間間隔であり、指定時間が経過するとタイマ割込（ハードウェア割込）が起動する（図２の符号ｔ参照）。運用者は、指定時間としてパケット処理に適する間隔（例えば、１μｓなど）を指定する。サーバ内遅延制御装置１００は、timer１２による指定した間隔のタイマ割込を受け付けることで、ハードウェア割込による実行権を得る。
上記指定間隔は、ハードウェア割込によるパケット処理が、システム動作に必要なＣＰＵタイムであり、かつ、所定時間（運用者が設定；例えば、１μｓ）以上はＣＰＵタイムを専有しないような時間間隔である。
なお、kernel（登録商標）には、タイマに関して、hrtimersという既存の仕組みがある。

タイマ割込のハードウェア割込において、パケット到着監視部１１０は、poll_list１８６にパケットのポインタが格納されているかを確認（poll）する（図２の符号ｐ参照）。poll_list１８６にパケットのポインタが格納されている場合は、パケット刈取部１２０へ、該当ポインタ情報とdevice driver情報を伝達する。

ここで、ハードウェア割込は極めて優先度が高い処理であり、ハードウェア割込が起動されると、該当ＣＰＵは他の処理を実行することができない。本実施形態では、タイマ割込により間隔を空けてハードウェア割込を実行させる。このため、ハードウェア割込がＣＰＵを専有してシステムが不安定になることを回避することが可能になる。
また、NIC１１へのパケット到着の度に、全てハードウェア割込を起動して、ハードウェア割込コンテキストで処理を実行すると、システムがＣＰＵを使用できず、不安定動作となる。本実施形態では、NIC１１へのパケット到着の度のハードウェア割込を起動は行わず、タイマ割込によりハードウェア割込を実行させることで、システムが不安定になることを回避する。

パケット刈取部１２０は、受信したポインタ情報とdevice driver情報をもとに、Ring Buffer７２からパケットを刈り取る。すなわち、パケット刈取部１２０は、タイマ割込契機で、poll_list１８６のパケット有無を確認し、パケットが到着している場合は、Ring Buffer７２からパケットを刈り取る。その後、パケット刈取部１２０は、netif_receive_skb８７へ該当データを伝達する。

このように、サーバ内遅延制御システム１０００は、<Device driver>において、ＮＷ遅延発生の主要因であるパケット処理のsoftIRQを停止し、タイマ契機で、高い優先度であるhardIRQのコンテキストでパケット処理を行うことで、softIRQ競合を回避する。また、高い優先度であるhardIRQによるパケット処理がＣＰＵタイムを専有する場合、システム動作が不安定になる。サーバ内遅延制御装置１００は、タイマ契機に細切れに動作するようにすることで、システム動作に必要なＣＰＵタイムを捻出して、上記hardIRQによるパケット処理がＣＰＵタイムを専有してシステム動作が不安定になることを回避し、安定動作を実現する。

<ハードウェア割込のコンテキスト処理>
netif_receive_skb８７は、受信したデータからsk_buff構造体を作成する。以降、kernel１７１（図１参照）によるプロトコル処理へ続く。具体的には、kernel１７１は、パケットの内容を解析し、タイプ毎に後段のプロトコル処理部７４（図１１参照）へ処理をまわす。すなわち、netif_receive_skb８７は、パケットの中身を解析し、パケットの中身に応じて処理をする場合には、<Protocol layer>のip_rcv８８に処理を回し、また、例えばＬ２であればarp_rcv８９に処理をまわす。

［live patchによる登録動作］
次に、live patchによる登録動作について説明する。
サーバ内遅延制御システム１０００（図１参照）は、図１に示すOS７０のkernel１７１が、サーバ内遅延制御装置１００を備える。kernel１７１は、livepatchを用いることで、既存のkernel７１（図１１参照）を改造（新しくビルド）することなく、実現が可能になる。以下、kernel１７１に適用されるlivepatchについて説明する。

livepatchは、Linux（登録商標）kernelに適用されるカーネルパッチ機能である。livepatchを使うことで、システムを再起動することなくカーネル空間に即座に修正を適用することができる。すなわち、
（１）livepatchは、netif_rx１８２（図２参照）のsoftIRQスケジューリング機能を抑制する。

（２）livepatchは、パケット到着監視を行うthread（パケット到着監視部１１０、具体的にはisol_net_rx）を起動する。起動する際、他プロセスやkernel threadにbusy poll（図２の符号ｐ参照）の邪魔をされないように、thread（パケット到着監視部１１０）は、ＣＰＵコアを専有する。そのために、当該threadはリアルタイムプロセス等の高優先設定を割り当てる。トラヒックフロー数（または、トラヒック量）に応じて、複数ＣＰＵコア上でthreadを起動し、監視するpoll_list１８６（図２参照）を割り当てる。これにより、トラヒックフロー（トラヒック量）に応じたスケールアウトが可能になる。
以降、図２に示すパケット処理の動作が実行される。

［サーバ内遅延制御装置１００のＲｘ側パケット処理動作フロー］
図３は、本実施形態のサーバ内遅延制御装置１００（図２参照）のタイマ割込による救済処理を示すフローチャートである。図２を参照してＲｘ側動作を例に採り説明する。
ステップＳ１１でtimer１２による指定時間が経過すると（図２の符号ｓ参照）、ステップＳ１２でkernel１７１（図１参照）が具備するタイマ割込機能によりハードウェア割込を起動する（図２の符号ｔ参照）。

ステップＳ１３では、パケット到着監視部１１０（図２参照）は、poll_list１８６（図２参照）を確認し（図２の符号ｐ参照）、パケット到着有無を判断する。

ステップＳ１４では、パケット到着監視部１１０は、poll_list１８６にバケット到着を意味するポインタ情報があるか否かを判別する。ポインタ情報がない場合は（Ｓ１４：Ｎｏ）、ステップＳ１３に戻り、ポインタ情報がある場合は（Ｓ１４：Ｙｅｓ）、ステップＳ１５に進む。

ステップＳ１５では、パケット到着監視部１１０は、poll_list１８６からRing_Buffer７２（図２参照）に格納されているパケットが存在するポインタ情報と、NET_DEVICE情報とを取得し、パケット刈取部１２０（図２参照）へ該当するポインタ情報およびNET_DEVICE情報を伝達する（図２の符号ｑ参照）。ここで、パケット到着監視部１１０は、poll_list１８６に複数パケット情報が存在する場合は、複数分伝達する。

ステップＳ１６では、パケット刈取部１２０は、予め保守運用者が設定した期間、受信した情報をもとに、Ring_Buffer７２からパケットを取り出し（図２の符号ｒ参照）、netif_receive_skb８７へパケットを伝達する（図２の符号ｕ参照）。

ステップＳ１７では、パケット刈取部１２０は、パケットの取り出しが完了したか否かを判別する。

パケットの取り出しが完了していない場合（Ｓ１７：Ｎｏ）、ステップＳ１６に戻る。
パケットの取り出しが完了した場合（Ｓ１７：Ｙｅｓ）、ステップＳ１８でパケット刈取部１２０は、poll_list１８６から該当キュー情報を削除する。

ステップＳ１９では、サーバ内遅延制御装置１００（図２参照）は、poll_list１８６が空になる、または、予め保守運用者が設定した期間が経過したか否かを判別する。

poll_list１８６が空になる、または、予め保守運用者が設定した期間が経過していない場合（Ｓ１９：Ｎｏ）、ステップＳ１８に戻る。
poll_list１８６が空になる、または、予め保守運用者が設定した期間が経過した場合（Ｓ１９：Ｙｅｓ）、本フローの処理を終了する。

［本実施形態と既存技術との差異］
次に、本実施形態と既存技術（図１２参照）との差異について説明する。

<背景>
一般に、ハードウェア割込（hardIRQ）は、優先度が高く、該当ＣＰＵの処理を中断し、hardIRQの処理を最優先で処理する必要がある。このため、オーバーヘッドが大きい。そのため、hardIRQでは、パケット到着を知らせるのみとし、パケット処理は、softIRQで処理する設計思想となっている（「kernelの原則」という）。ここで、softIRQは、他のsoftIRQと競合し、待たされる事象が発生する（遅延発生の要因となる）。
従来技術が割込モデルにしている理由は、かつてはＣＰＵリソースが限られていた（または、Raspberry PiのようなSingle board ComputerのようにＣＰＵコアが少ないデバイスでも動作させる）ために、１つのＣＰＵコアを他の処理と共有して使用する設計思想になっていたためである。この場合、通常の処理や割込処理等でＣＰＵタイムを切り替えながら処理を行う。上記割込処理であっても、softIRQは競合することになり、待ち時間が発生する。
なお、softIRQのスケジューリングを行うスケジューラであるksoftirqdは、softIRQの種別に応じて優先度を付与する機能を具備しておらず、この競合による遅延発生は抑制できない。

<既存技術（図１２参照）>
図１２に示すように、kernel７１（図１１）は、NIC１１からのパケット到着の知らせを、hardIRQにより受け取り（図１２の符号ｈ参照）、パケット処理のためのsoftIRQをスケジューリングする（図１２の破線囲み参照）。この際、他の割込処理と競合すると待合せが発生し、ｍｓオーダのＮＷ遅延が発生する。

<サーバ内遅延制御システム１０００（図２参照）>
図２に示すように、サーバ内遅延制御システム１０００は、<Networking layer>において、netif_rx１１８２は、poll_list１８６にnet_deviceを登録するが、既存技術（図１２参照）のnetif_rx８２とは異なり、ソフトウェア割込（softIRQ）のスケジューリングは行わない（「変更点１」）。

図２に示すように、<Device driver>において、timer１２は、hw_clock１２ａを用いて指定時間を計時し、ハードウェア割込（hardIRQ）をhardIRQ９１（ハンドラ）に立ち上げる（図２の符号ｓ参照）（「変更点２」）。

図２に示すように、サーバ内遅延制御システム１０００は、<Networking layer>のサーバの中にあるメモリ空間に、サーバ内遅延制御装置１００を設ける（「変更点３」）。

サーバ内遅延制御装置１００のパケット到着監視部１１０は、タイマ割込契機（図２の符号ｔ参照）で、poll_list１８６のパケット有無を確認する（図２の符号ｐ参照）。

サーバ内遅延制御装置１００のパケット刈取部１２０は、パケットが到着している場合（図２の符号ｑ参照）は、Ring Buffer７２からパケットを刈り取る（図２の符号ｒ参照）。
パケット刈取部１２０は、受信した情報をもとにRing_Buff７２からパケットを取り出し、netif_receive_skb８７へパケットを伝達する（図２の符号ｕ参照）。

<既存技術（図１２参照）とサーバ内遅延制御システム１０００（図２参照）との比較>
・低遅延なパケット処理
タイマ割込（ハードウェア割込）を契機に、パケット到着を確認することで、最低でもタイマ間隔でのパケット転送処理を可能とし、遅延時間の保証が可能である。すなわち、ハードウェア割込のコンテキストでパケット刈り取り処理を行うため、ソフトウェア割込競合の問題は発生しない。

・ＡＰＬの改変が不要
本実施形態では、ハードウェア割込（hardIRQ）によるパケット到着の通知については、NAPIを踏襲する。softIRQは、ＣＰＵリソースを有効活用する点では便利であるが、パケットの即時転送の観点では適さない。そのため、本実施形態では、softIRQの機能を停止し、kernelの中でpollingモデルを実現する点が新しい。具体的には、図２に示すnetif_rx１８２が、図１２に示すnetif_rx８２のように、softIRQ８３（ハンドラ）を立ち上げる通知（図１２の符号ｈ参照）を行わないことに示されている。

なお、pollingモデルについては、ユーザスペースからpollingを行うＤＰＤＫが既存技術としてある（図１０参照）。しかしながら、ＤＰＤＫは、ＡＰＬからpollingを行うため、ＡＰＬに改変が必要である。

本実施形態は、図１に示すkernel１７１の中でpolling専用のthread（サーバ内遅延制御装置１００のパケット到着監視部１１０）を起動し、サーバ内遅延制御装置１００のパケット刈取部１２０が、パケット到着時に、pollingモデル（softIRQなし）によりパケット処理を行う。本実施形態は、Linux上で動作するＡＰＬの開発者が利用するPOSIX socket APIを利用可能な実現方式であるため、ＡＰＬの改変不要になる、換言すれば、既存のPOSIX socket APIを利用することが可能になる。

・kernelセキュリティアップデートの度に再開発が不要
本実施形態は、kernelを起動させたまま処理を変更可能なlivepatchにより、本発明を有効化可能である。このため、kernelのセキュリティアップデートの度にソフトウェアを再開発する必要がない（関連するkernel機能に変更があった場合のみでよい）。

・その他
本実施形態は、既存技術のNAPIと異なり、タイマ割込契機のハードウェア割込コンテキストでパケット処理を行うためソフトウェア割込み競合は発生しない。
本実施形態は、既存技術のＤＰＤＫと異なり、kernel内でパケット処理は完結するため、ＡＰＬに改変が不要である。

<<Networking layer>に、サーバ内遅延制御装置１００を備える特有の効果>
サーバ内遅延制御装置１００は、遅延発生要因となるsoftIRQを停止し、タイマ契機で、高い優先度であるhardIRQのコンテキストでパケット処理を行う。これにより、softIRQ競合を回避する。

サーバ内遅延制御装置１００は、高い優先度であるhardIRQによるパケット処理がＣＰＵタイムを専有して、システム動作が不安定になることを、タイマ契機に細切れに動作するようにする。これにより、システム動作に必要なＣＰＵタイムを捻出し、安定動作を実現する。

サーバ内遅延制御装置１００は、タイマ割込（ハードウェア割込）契機で、ハードウェア割込のコンテキストでパケットの到着を確認し、パケット到着時の刈り取り処理を行う。これにより、ｍｓオーダ遅延の原因であるソフトウェア割込の競合を回避し、低遅延にパケット処理を実現することができる（ハードウェア割込は最も優先度が高いため、他の処理に邪魔をされない）。

（第２実施形態）
本発明の第２実施形態に係るサーバ内遅延制御システム１０００Ａの概略構成は、図１に示すサーバ内遅延制御システム１０００と同様である。
図４は、本発明の第２実施形態に係るサーバ内遅延制御システム１０００Ａのパケット処理の詳細を説明する図である。図２および図１２と同一構成部分には、同一符号を付して重複箇所の説明を省略する。

第２実施形態に係るサーバ内遅延制御システム１０００Ａは、NAPIとタイマ割込によるサーバ内遅延制御システム１０００とのハイブリッド方式である。
サーバ内遅延制御システム１０００Ａは、既存のNAPIのソフトウェア割込競合時の遅延（パケット刈り取り遅れ）を救済するために、既存NAPIによるパケット受信処理（図１２に対応する符号部分参照）はそのまま活かし、NAPIに重畳する形で、タイマ割込によるパケット受信処理（図２に対応する符号部分参照）を行う。
これにより、NAPIによるパケット刈り取り遅れを、タイマ割込によるパケット受信処理により救済が可能となる。その結果、パケット受信処理の低遅延化の実現が可能になる。

次に、サーバ内遅延制御システム１０００Ａの動作について説明する。
サーバ内遅延制御システム１０００Ａは、既存のNAPIが図４に示すNAPIによる処理を有する。なお、図５に示す「NAPIによる処理」と、図３に示す「タイマ割込による救済処理」とは、独立して動作する。このため、両者間のタイミング制御を行う管理機能部は不要である。また、両者が独立して動作することは、実装により確認している。

図５は、第２実施形態に係るサーバ内遅延制御システム１０００Ａ（図４参照）のNAPIによる処理を示すフローチャートである。図４を参照してＲｘ側動作を例に採り説明する。
ステップＳ２１でNIC１１は、パケットを受信し、ＤＭＡ処理後か否かを判別する。
パケットを受信し、ＤＭＡ処理後の場合は（Ｓ２１：Ｙｅｓ）、ステップＳ２２でNIC１１は、ハードウェア割込を起動し、poll_list１８６にRing Buffer７２に格納したパケットのポインタ情報とNET_DEVICE（ドライバ）情報とを登録する。
ステップＳ２３でNIC１１は、後段のパケットプロトコル処理のために、ソフトウェア割込をスケジューリングする。

ステップＳ２４で、ソフトウェア割込ハンドラは、poll_list１８６からRing_Buffer７２にパケットが存在するポインタ情報と、NET_DEVICE情報を取得する。
ステップＳ２５で、ソフトウェア割込ハンドラは、取得した情報をもとにRing_Buffer７２からパケットを取り出し、netif_receive_skb８７へパケットを伝達する。

ステップＳ２６で、パケットの取り出しが完了したか否かを判別する。パケットの取り出しが完了していない場合（Ｓ２６：Ｎｏ）、ステップＳ２６に戻る。
パケットの取り出しが完了した場合（Ｓ２６：Ｙｅｓ）、ステップＳ２７で、poll_list１８６から当該キュー情報は削除する。
ステップＳ２８で、poll_list１８６が空になったか否かを判別する。poll_list１８６が空になっていない場合（Ｓ２８：Ｎｏ）、ステップＳ２６に戻る。
poll_list１８６が空になった場合（Ｓ２８：Ｙｅｓ）、本フローの処理を終了する。本フローの処理は、poll_list１８６が空になるまで繰り返し実行される。

本実施形態のサーバ内遅延制御システム１０００Ａは、既存技術（例えば、NAPI）のソフトウェア割込競合などにより、poll_list１８６からのパケット到着確認が遅れる場合を救済する。すなわち、タイマ割込契機によって、図３に示す「タイマ割込による救済処理」からの定期的に取りこぼしをパケット到着監視部１１０が確認して、取りこぼしを救済する。これにより、低遅延性を担保する。

タイマ割込による救済処理について補足して説明する。
本実施形態では、poll_list１８６からのパケット到着確認が遅れる場合の救済として、タイマ割込契機で、図３に示す「タイマ割込による救済処理」によって定期的に取りこぼしを確認して、取りこぼしを救済する。
具体的には、パケット到着監視部１１０が、poll_list１８６を確認し、poll_list１８６にパケットの有無を確認することで、NAPIによる刈り取り漏れを検知する。この際、NAPIが特に遅れていなくても、タイミングによっては、図３に示す「タイマ割込による救済処理」によりpoll_list１８６からパケットが刈り取られることもある。

図５に示す「NAPIによる処理」と、図３に示す「タイマ割込による救済処理」とは、独立して動作する。このため、NAPIのソフトウェア割込競合が発生したことを、図３に示す「タイマ割込による救済処理」に通知する必要はなく、NAPIが遅れた場合は、事象としてpoll_list１８６にパケットが残ることになるので、図３に示す「タイマ割込による救済処理」は定期的に立ち上がってpoll_list１８６を確認するだけで、救済することが可能となる。図５に示す「NAPIによる処理」と、図３に示す「タイマ割込による救済処理」とは、独立して動作し、poll_list１８６が空になるまで繰り返すことが、end条件なるため、相互の依存（調整）は、不要である。

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

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

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

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

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

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

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

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

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

Kernel９１は、poll_list１８６を常に監視（busy poll）するパケット到着監視部１１０と、パケットが到着している場合は、Ring Buffer７２に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをRing Buffer７２から削除する刈取りを実行するパケット刈取部１２０と、を備える。
Kernel９１は、tapデバイス２２２を介して、ＶＭ４０仮想マシン３０へパケットを伝達する。

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

Kernel１７１は、poll_list１８６を常に監視（busy poll）するパケット到着監視部１１０と、パケットが到着している場合は、Ring Buffer７２に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをRing Buffer７２から削除する刈取りを実行するパケット刈取部１２０と、刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部７４と、を備える。
Kernel１７１は、プロトコル処理部７４を介して、パケット処理ＡＰＬ１へパケットを伝達する。

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

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

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

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

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

［効果］
以上説明したように、OS（OS７０）が、カーネル（Kernel１７１）と、OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファ（Ring Buffer７２)と、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（poll_list１８６）と、を有し、カーネル内に、所定指定間隔のタイマ割込を受付けるとともに、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００を備えており、サーバ内遅延制御装置１００は、タイマ割込をハードウェア割込とし、当該タイマ割込を契機にポールリストのパケットの有無を確認して当該ポールリストを監視（poll）するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファから削除する刈取りを実行するパケット刈取部１２０と、を備える。

このようにすることで、サーバ内遅延制御装置１００は、ＮＷ遅延発生の主要因であるパケット処理のソフトウェア割込（softIRQ）を停止し、サーバ内遅延制御装置１００のパケット到着監視部１１０がタイマ割込（ハードウェア割込）契機で、ハードウェア割込のコンテキストでパケットの到着を確認し、パケット刈取部１２０が、パケット到着時に、pollingモデル（softIRQなし）によりパケット処理を行う。これにより、下記（１）～（４）の効果を奏する。

（１）遅延発生の原因となるパケット到着時のソフトウェア割込（softIRQ）を停止し、その代わり、タイマ契機で、高い優先度であるhardIRQのコンテキストでパケット処理を行うことで、softIRQ競合を回避する。すなわち、サーバ内遅延制御システム１０００は、タイマ割込（ハードウェア割込）を契機に、パケット到着を確認することで、最低でもタイマ間隔でのパケット転送処理を可能とし、遅延時間の保証が可能となる（ハードウェア割込のコンテキストでパケット刈り取り処理を行うため、ソフトウェア割込競合の問題は発生しない）。パケット到着時は、待合せなく即時に刈り取られるため、低遅延なパケット処理を実現することができる。

（２）ＡＰＬにパケット高速転送のための機能を具備させる必要がなく、ＡＰＬはカーネル（Kernel１７１）が持つ既存POSIX socket APIとのインタワークを行うだけでよい。すなわち、サーバ内遅延制御システム１０００は、既存技術のＤＰＤＫと異なり、kernel内でpollingモデルを実現するため（既存技術のＤＰＤＫと異なり、kernel内でパケット処理は完結するため）、ＡＰＬに改変が不要である。具体的には、図１０に示すように、パケット高速転送のための機能（図１０のdpdk(PMD)２参照）を、パケット処理ＡＰＬ１Ａ（図１０参照）具備させる必要がなく、本サーバ内遅延制御システム１０００のパケット処理ＡＰＬ１（図１参照）は、kernelが持つ既存POSIX socket APIとのインタワークを行うだけでよい。このため、ＡＰＬを改変することなく、実現が可能である。例えば、Linux上で動作するＡＰＬの開発者が利用するPOSIX socket APIを利用可能であるため、ＡＰＬの改変不要で、本発明を利用することが可能である。

（３）kernelセキュリティアップデートの度に再開発が不要である。また、kernelを起動させたまま、処理動作を変更可能なlivepatchでパッチを適用することで有効化可能である。このため、kernelのセキュリティアップデートの度に、ソフトウェアを再開発する必要がない（関連するkernel機能に変更があった場合のみでよい）。

（４）既存技術のNAPIと異なり、タイマ割込契機のハードウェア割込コンテキストでパケット処理を行うため、ソフトウェア割込み競合は発生しない。

また、仮想マシン内で動作するGuest OS（GuestOS７０）が、カーネル（Kernel１７１）と、Guest OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファ（Ring Buffer７２）と、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（poll_list１８６）と、刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部７４と、を有し、カーネル内に、所定指定間隔のタイマ割込を受付けるとともに、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００を備えており、サーバ内遅延制御装置１００は、前記タイマ割込をハードウェア割込とし、当該タイマ割込を契機に前記ポールリストのパケットの有無を確認して当該ポールリストを監視（poll）するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファから削除する刈取りを実行するパケット刈取部１２０と、を備えることを特徴とする。

このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、Guest OS（GuestOS７０）を備えるサーバについて、低遅延なパケット処理を実現することができ、かつ、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。

また、仮想マシンおよび仮想マシン外に形成された外部プロセスが動作可能なHost OS（HostOS９０）が、カーネル（Kernel９１）と、Host OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファ（Ring Buffer２２）と、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（poll_list１８６）と、カーネル（Kernel９１）により作成される仮想インターフェイスであるtapデバイス２２２と、を備え、カーネル内に、所定指定間隔のタイマ割込を受付けるとともに、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００を備えており、サーバ内遅延制御装置１００は、前記タイマ割込をハードウェア割込とし、当該タイマ割込を契機に前記ポールリストのパケットの有無を確認して当該ポールリストを監視（poll）するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファ（Ring Buffer７２）に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファ（Ring Buffer７２）から削除する刈取りを実行するパケット刈取部１２０と、を備えることを特徴とする。

このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、カーネル（Kernel９１）とHost OS（HostOS９０）とを備えるサーバについて、低遅延なパケット処理を実現することができ、かつ、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。

サーバ内遅延制御装置１００において、前記インターフェイス部は、ハードウェア割込を割込ハンドラ（hardIRQ８１）に立ち上げて前記ポールリストにデバイスを登録する場合、ソフトウェア割込によるスケジューリングを停止することを特徴とする。

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

サーバ内遅延制御装置１００において、前記所定指定間隔は、ハードウェア割込によるパケット処理が、システム動作に必要なＣＰＵタイムであり、かつ、所定時間（運用者が設定；例えば、１μｓ）以上は前記ＣＰＵタイムを専有しないような時間間隔であることを特徴とする。

このようにすることにより、高い優先度であるhardIRQによるパケット処理がＣＰＵタイムを専有して、システム動作が不安定になることを抑制することができる。また、タイマ契機に細切れに動作するようにすることで、システム動作に必要なＣＰＵタイムを捻出して、安定動作を実現することができる。

サーバ内遅延制御装置１００において、カーネル（Kernel１７１）は、当該カーネル(Kernel171)を起動させたまま、処理動作を変更可能なパッチ（livepatch）を有することを特徴とする。

このようにすることにより、livepatchを用いて、（Kernel１７１）を起動させたまま、処理動作が変更可能になるので、kernelの改造が不要である。このため、例えばkernelのセキュリティアップデートの度に、開発し直す必要がなく、関連するkernel機能に変更があった場合のみ、処理動作を変更すればよい。

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

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

１ パケット処理ＡＰＬ（アプリケーション）
１０，１０Ａ ＨＷ
１１ NIC（物理NIC）(インターフェイス部)
１２ timer（タイマ）
６０ user space（ユーザスペース）
７０ OS
７２ Ring Buffer（リングバッファ）
７４ プロトコル処理部
８１ hardIRQ（割込ハンドラ）
９０ Host OS（OS）
９１，１７１，１８１ Kernel（カーネル）
１００ サーバ内遅延制御装置
１１０ パケット到着監視部
１２０ パケット刈取部
１８０ Guest OS（OS）
１８６ poll_list（ポールリスト）
２１０ Container
１０００，１０００Ａ，１０００Ｂ，１０００Ｃ サーバ内遅延制御システム

Claims (8)

1. サーバ内遅延制御装置であって、
   OSが、
   カーネルと、
   前記OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
   インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を有し、
   前記カーネル内に、所定指定間隔のタイマ割込を受付けるとともに、
   ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
   前記サーバ内遅延制御装置は、
   前記タイマ割込をハードウェア割込とし、当該タイマ割込を契機に前記ポールリストのパケットの有無を確認して当該ポールリストを監視するパケット到着監視部と、
   パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、を備える
   ことを特徴とするサーバ内遅延制御装置。
2. サーバ内遅延制御装置であって、
   仮想マシン内で動作するGuest OSが、
   カーネルと、
   前記Guest OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
   インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、
   刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部と、を有し、
   前記カーネル内に、所定指定間隔のタイマ割込を受付けるとともに、
   ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
   前記サーバ内遅延制御装置は、
   前記タイマ割込をハードウェア割込とし、当該タイマ割込を契機に前記ポールリストのパケットの有無を確認して当該ポールリストを監視するパケット到着監視部と、
   パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、を備える
   ことを特徴とするサーバ内遅延制御装置。
3. サーバ内遅延制御装置であって、
   仮想マシンおよび前記仮想マシン外に形成された外部プロセスが動作可能なHost OSが、
   カーネルと、
   前記Host OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
   インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、
   前記カーネルにより作成される仮想インターフェイスであるtapデバイスと、を備え、
   前記カーネル内に、所定指定間隔のタイマ割込を受付けるとともに、
   ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
   前記サーバ内遅延制御装置は、
   前記タイマ割込をハードウェア割込とし、当該タイマ割込を契機に前記ポールリストのパケットの有無を確認して当該ポールリストを監視するパケット到着監視部と、
   パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、を備える
   ことを特徴とするサーバ内遅延制御装置。
4. 前記インターフェイス部は、ハードウェア割込を割込ハンドラに立ち上げて前記ポールリストにデバイスを登録する場合、ソフトウェア割込によるスケジューリングを停止する
   ことを特徴とする請求項１乃至３のいずれか一項に記載のサーバ内遅延制御装置。
5. 前記所定指定間隔は、ハードウェア割込によるパケット処理が、システム動作に必要なＣＰＵタイムであり、かつ、所定時間以上は前記ＣＰＵタイムを専有しないような時間間隔である
   ことを特徴とする請求項１乃至３のいずれか一項に記載のサーバ内遅延制御装置。
6. 前記カーネルは、当該カーネルを起動させたまま、処理動作を変更可能なパッチを有する
   ことを特徴とする請求項１乃至３のいずれか一項に記載のサーバ内遅延制御装置。
7. サーバ内遅延制御装置のサーバ内遅延制御方法であって、
   OSが、
   カーネルと、
   前記OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
   インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を有し、
   前記カーネル内に、所定指定間隔のタイマ割込を受付けるとともに、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置を備えており、
   前記サーバ内遅延制御装置は、
   前記タイマ割込をハードウェア割込とし、当該タイマ割込を契機に前は記ポールリストのパケットの有無を確認して当該ポールリストを監視するステップと、
   パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するステップと、を実行する
   ことを特徴とするサーバ内遅延制御方法。
8. OSが、
   カーネルと、
   前記OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
   インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を有し、
   前記カーネル内に、所定指定間隔のタイマ割込を受付けるとともに、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置を備えており、前記サーバ内遅延制御装置としてのコンピュータに、
   前記タイマ割込をハードウェア割込とし、当該タイマ割込を契機に前記ポールリストのパケットの有無を確認して当該ポールリストを監視するパケット到着監視手順、
   パケットが到着している場合は、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取手順、
   を実行させるためのプログラム。

Images