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

［割込モデルによるパケット転送（汎用VM構成の例）］
特許文献１には、仮想マシン内で動作する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)２を具備させて、パケット処理ＡＰＬ１を改変したＡＰＬである。

ポーリングモデルによるパケット転送は、DPDKの拡張として、共有メモリを介してゼロコピーで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７１は、当該パケットを認知する。なお、図１０の楕円で囲んで示すhardIRQ８１は、機能部ではなくハンドラを表記する。

netif_rx８２は、実際に処理をする機能であり、hardIRQ８１（ハンドラ）が立ち上がると（図１０の符号ｆ参照）、poll_list８６に、ハードウェア割込（hardIRQ）の中身の情報の１つである、ＮＩＣ１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（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を備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を有し、前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、前記サーバ内遅延制御装置は、前記ポールリストを監視するパケット到着監視部と、前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、を備えることを特徴とするサーバ内遅延制御装置とした。

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

本発明の実施形態に係るサーバ内遅延制御システムの概略構成図である。 本発明の実施形態に係るサーバ内遅延制御システムのNew API(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１７０に接続されたＨＷ１０のＮＩＣ１１とパケット処理ＡＰＬ１との間でパケット転送を行う。

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

本実施形態では、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１７１でハードウェアの監視を行うためデバイスドライバである。

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

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

<サーバ内遅延制御装置>
サーバ内遅延制御装置１００は、パケット到着監視部１１０と、パケット刈取部１２０と、を備える。
パケット到着監視部１１０は、パケットが到着していないかを監視するためのthreadである。パケット到着監視部１１０は、poll_list１８６（図２参照）を常に監視（busy poll）する。

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

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

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

<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１８２、do_softirq８４、net_rx_action８５、netif_receive_skb８７、ip_rcv８８、およびarp_rcv８９は、Kernel１７１の中でパケット処理のために呼ばれるプログラムの部品（関数の名称）である。

以下、サーバ内遅延制御システム１０００の動作を説明する。
［New API(NAPI)によるＲｘ側パケット処理動作］
図２の矢印（符号）ｄ～ｇ，ｋ～ｏは、Ｒｘ側パケット処理の流れを示している。
NIC１１が、対向装置からフレーム内にパケット（またはフレーム）を受信すると、ＤＭＡ転送によりＣＰＵを使用せずに、Ring Buffer７２へ到着したパケットをコピーする（図２の符号ｄ参照）。このRing Buffer７２は、サーバ中のメモリ空間で、Kernel１７１（図１参照）が管理している。

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

netif_rx１８２は、hardIRQ８１（ハンドラ）が立ち上がると（図２の符号ｆ参照）、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>におけるハードウェア割込の処理は停止する。

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

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

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

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

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

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

netif_receive_skb８７は、sk_buff構造体を作り、パケットの内容を解析し、タイプ毎に後段のプロトコル処理部７４（図９参照）へ処理をまわす。すなわち、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１８６（図２参照）を割り当てる。これにより、トラヒックフロー（トラヒック量）に応じたスケールアウトが可能になる。
以降、図２に示すパケット処理の動作が実行される。

［サーバ内遅延制御装置１００のＲｘ側パケット処理動作フロー］
図３は、サーバ内遅延制御装置１００（図２参照）のＲｘ側動作を示すフローチャートである。図２を参照してＲｘ側動作を説明する。
ステップＳ１１では、サーバ内遅延制御装置１００のパケット到着監視部１１０（図２参照）は、poll_list１８６（図２参照）をＣＰＵを専有して常に監視（busy poll）し（図２の符号ｋ参照）、パケット到着有無を確認する。

ステップＳ１２では、パケット到着監視部１１０（図２参照）は、poll list１８６にパケット到着を意味するポインタ情報があるか否かを判別する。
poll list１８６にパケット到着を意味するポインタ情報がある場合（Ｓ１２：Ｙｅｓ）、ステップＳ１３に進み、poll list１８６にパケット到着を意味するポインタ情報がない場合（Ｓ１２：Ｎｏ）、本フローの処理を終了する。

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

ステップＳ１４では、サーバ内遅延制御装置１００のパケット刈取部１２０（図２参照）は、パケットが到着している場合は、Ring Buffer７２に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをRing Buffer７２から削除する刈取りを実行する（図２の符号ｌ参照）。

ステップＳ１５では、パケット刈取部１２０は、受信した情報をもとにRing_Buffer７２からパケットを取り出し、netif_receive_skb８７へパケットを伝達して（図２の符号ｍ参照）、本フローの処理を終了する。

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

<背景>
一般に、ハードウェア割込（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）のスケジューリングは行わない（「変更点１」）。

図２に示すように、サーバ内遅延制御システム１０００は、<Networking layer>のサーバの中にあるメモリ空間に、サーバ内遅延制御装置１００を設ける（「変更点２」）。
サーバ内遅延制御装置１００のパケット到着監視部１１０は、poll_list１８６を常に監視（busy poll）し（図２の符号ｋ参照）、パケット到着有無を確認する。

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

サーバ内遅延制御装置１００のパケット刈取部１２０は、パケットが到着している場合は、Ring Buffer７２からパケットを刈取る（図２の符号ｌ参照）。

パケット刈取部１２０は、受信した情報をもとにRing_Buffer７２からパケットを取り出し、netif_receive_skb８７へパケットを伝達する（図２の符号ｍ参照）。

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

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

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

また、前述threadが他のsoftIRQなどにＣＰＵタイムを奪われないようにするために、上記［live patchによる登録］で述べたように、thread起動時にＣＰＵコアを専有し、高優先設定を行うことで、pollingの邪魔をさせない。

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

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

ＨＤＤ９４０は、ＣＰＵ９１０によって実行されるプログラム、および、かかるプログラムによって使用されるデータ等を格納する。通信インターフェイス９５０は、通信網８０を介して他の機器からデータを受信してＣＰＵ９１０へ送り、ＣＰＵ９１０が生成したデータを通信網８０を介して他の機器へ送信する。

ＣＰＵ９１０は、入出力インターフェイス９６０を介して、ディスプレイやプリンタ等の出力装置、および、キーボードやマウス等の入力装置を制御する。ＣＰＵ９１０は、入出力インターフェイス９６０を介して、入力装置からデータを取得する。また、ＣＰＵ９１０は、生成したデータを入出力インターフェイス９６０を介して出力装置へ出力する。

メディアインターフェイス９７０は、記録媒体９８０に格納されたプログラムまたはデータを読み取り、ＲＡＭ９２０を介してＣＰＵ９１０に提供する。ＣＰＵ９１０は、かかるプログラムを、メディアインターフェイス９７０を介して記録媒体９８０からＲＡＭ９２０上にロードし、ロードしたプログラムを実行する。記録媒体９８０は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phasechangerewritable 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）を立ち上げるサーバ内遅延制御装置１００を備えており、サーバ内遅延制御装置１００は、ポールリストを監視（busy poll）するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファから削除する刈取りを実行するパケット刈取部１２０と、を備える。

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

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

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

（３）同様の理由で、独自のkernelを作る必要がなく、実現が可能である。

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

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

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

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

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

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

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

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

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

Claims (15)

1. サーバ内遅延制御装置であって、
   OSが、
   カーネルと、
   前記OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
   インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を有し、
   前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
   前記サーバ内遅延制御装置は、
   前記ポールリストを監視するパケット到着監視部と、
   前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、を備える
   ことを特徴とするサーバ内遅延制御装置。
2. サーバ内遅延制御装置であって、
   仮想マシン内で動作するOSである Guest OSが、
   カーネルと、
   前記Guest OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
   インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、
   刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部と、を有し、
   前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
   前記サーバ内遅延制御装置は、
   前記ポールリストを監視するパケット到着監視部と、
   前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、を備える
   ことを特徴とするサーバ内遅延制御装置。
3. サーバ内遅延制御装置であって、
   仮想マシンおよび前記仮想マシン外に形成された外部プロセスが動作可能なOSであるHost OSが、
   カーネルと、
   前記Host OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
   インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、
   前記カーネルにより作成される仮想インターフェイスであるtapデバイスと、を備え、
   前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
   前記サーバ内遅延制御装置は、
   前記ポールリストを監視するパケット到着監視部と、
   前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、を備える
   ことを特徴とするサーバ内遅延制御装置。
4. 前記カーネルは、当該カーネルを起動させたまま、処理動作を変更可能なパッチを有する
   ことを特徴とする請求項１乃至請求項３のいずれか一項に記載のサーバ内遅延制御装置。
5. ポーリングモデルによりパケットの到着を監視するパケット到着監視部と、
   リングバッファに保持したパケットを参照し、前記リングバッファへの到着が検知された前記パケットを取得するパケット刈取部と、
   前記パケット到着監視部と前記パケット刈取部とを含むカーネルと、を備え、
   前記パケット到着監視部は、
   当該カーネル内で、前記ポーリングモデルによりパケット到着を監視するスレッドを起動させる
   ことを特徴とするサーバ。
6. 仮想マシン内で動作するOSであるGuest OSが、
   前記Guest OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファと、
   ポーリングモデルによりパケットの到着を監視するパケット到着監視部と、
   リングバッファに保持したパケットを参照し、前記リングバッファへの到着が検知された前記パケットを取得するパケット刈取部と、を備える
   ことを特徴とするサーバ。
7. 仮想マシンおよび前記仮想マシン外に形成された外部プロセスが動作可能なOSであるHost OSが、
   前記Host OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファと、
   ポーリングモデルによりパケットの到着を監視するパケット到着監視部と、
   リングバッファに保持したパケットを参照し、前記リングバッファへの到着が検知された前記パケットを取得するパケット刈取部と、を備える
   ことを特徴とするサーバ。
8. 前記カーネルは、当該カーネルを起動させたまま、処理動作を変更可能なパッチを有する
   ことを特徴とする請求項５乃至請求項７のいずれか一項に記載のサーバ。
9. 前記パケット到着監視部が監視する対象は、インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストである
   ことを特徴とする請求項５乃至請求項８のいずれか一項に記載のサーバ。
10. 前記カーネルは、流入するパケット量に応じて、スレッドに割り当てるＣＰＵの数を増減する
    ことを特徴とする請求項５または請求項６に記載のサーバ。
11. 前記パケット刈取部は、
    パケットが到着している場合、前記リングバッファに保持したパケットを参照する
    ことを特徴とする請求項５乃至請求項８のいずれか一項に記載のサーバ。
12. サーバ内遅延制御装置のサーバ内遅延制御方法であって、
    OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファと、
    インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を前記サーバが有し、前記カーネル内に前記サーバ内遅延制御装置を備え、
    前記サーバ内遅延制御装置は、前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御ステップを実行し、
    前記サーバ内遅延制御ステップは、
    前記ポールリストを監視するステップと、
    前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するステップと、を含む
    ことを特徴とするサーバ内遅延制御方法。
13. サーバのサーバ内遅延制御方法であって、
    前記サーバは、
    ポーリングモデルによりパケットの到着を監視するパケット到着監視ステップと、
    リングバッファに保持したパケットを参照し、前記リングバッファへの到着が検知された前記パケットを取得するパケット取得ステップと、を実行するとともに、
    前記パケット到着監視ステップでは、
    前記サーバのカーネル内で、前記ポーリングモデルによりパケット到着を監視するスレッドを起動させる
    ことを特徴とするサーバ内遅延制御方法。
14. OSが、
    カーネルと、
    前記OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
    インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を有し、
    前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置を備えており、前記サーバ内遅延制御装置としてのコンピュータに、
    前記ポールリストを監視するパケット到着監視手順、
    前記リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取手順、
    を実行させるためのプログラム。
15. カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバとしてのコンピュータに、
    ポーリングモデルによりパケットの到着を監視するパケット到着監視手順、
    リングバッファに保持したパケットを参照し、前記リングバッファへの到着が検知された前記パケットを取得する手順、
    を実行させるためのプログラム。

Images