JP7709645B2

JP7709645B2 - サーバ内データ転送装置、サーバ内データ転送方法およびプログラム

Info

Publication number: JP7709645B2
Application number: JP2023565786A
Authority: JP
Inventors: 育生大谷; 圭藤本; 奨悟斎藤
Original assignee: Nippon Telegraph and Telephone Corp; NTT Inc USA
Current assignee: NTT Inc; NTT Inc USA
Priority date: 2021-12-08
Filing date: 2021-12-08
Publication date: 2025-07-17
Anticipated expiration: 2041-12-08
Also published as: WO2023105692A1; EP4447395A1; EP4447395A4; JPWO2023105692A1; CN118355641A; JP2025133855A

Description

本発明は、サーバ内データ転送装置、サーバ内データ転送方法およびプログラムに関する。

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

仮想マシンを構成する技術として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を抑止し、低遅延なパケット処理を実現する。

次に、ＤＰＤＫシステムについて説明する。
［ＤＰＤＫシステム構成］
図２３は、アクセラレータ１１を備えるＨＷ１０の制御を行うＤＰＤＫシステムの構成を示す図である。
ＤＰＤＫシステムは、ＨＷ１０、パケット処理ＡＰＩ（Application Programming Interface）１４、アプリケーション（ＡＰＬ）２０を有する。

ＡＰＬ２０は、ＡＰＬの実行に先立って行われるパケット処理である。ＡＰＬ２０は、ここではＡＰＬ１，ＡＰＬ２である。

パケット処理ＡＰＩ１４は、ＮＩＣやアクセラレータに向けてパケット処理をオフロードする際のＡＰＩである。パケット処理ＡＰＩ１４は、user space（ユーザ空間）上に配置されたデータ高速転送ミドルウェアでありＤＰＤＫである。
ＤＰＤＫは、ＡＰＬ２０が動作するuser spaceでパケット処理機能を実現し、user spaceからpollingモデルでパケット到着時に即時刈取りを行うことで、パケット転送遅延を小さくすることを可能にする。すなわち、ＤＰＤＫは、polling（ＣＰＵでキューをbusy poll）によりパケットの刈取り（バッファに溜まっているパケットの中身を参照して、そのパケットの処理を、次に行う処理を考慮してバッファから該当するキューのエントリを削除する）を行うため、待ち合わせがなく遅延小である。

ＨＷ１０は、ＡＰＬ１，ＡＰＬ２との間でデータ送受信の通信を行う。以下の説明において、ＡＰＬ１，ＡＰＬ２が、ＨＷ１０からのパケットを受け取るデータの流れをＲｘ側受信と称し、ＡＰＬ１，ＡＰＬ２が、ＨＷ１０にパケットを送信するデータの流れをＴｘ側送信と称する。

ＨＷ１０は、アクセラレータ１１を備える。また、ＨＷ１０は、通信ネットワークに接続するためのＮＩＣ（物理NIC）を備えていてもよい。
アクセラレータ１１は、ＣＰＵからの入力をもとに、特定の演算を高速に行う計算ユニットハードウェアである。アクセラレータ１１は、具体的には、ＧＰＵ（Graphics Processing Unit）やＦＰＧＡ（Field Programmable Gate Array）等のＰＬＤ（Programmable Logic Device）である。図２３では、アクセラレータ１１は、複数のＩＰコア（Intellectual Property Core）１２、データを先入れ先出しのリスト構造で保持するＲｘキュー（queue：待ち行列）およびＴｘキューからなる物理キュー１３を備える。ＩＰコア１２は、ＦＰＧＡ、ＩＣ、ＬＳＩなどの半導体を構成する再利用可能な回路コンポーネントの設計情報であり、デバイスコア（Ｃｏｒｅプロセッサ）と呼ぶこともある。

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

ＤＰＤＫ等、ポールモードでデータをアクセラレータに転送する既存アプリケーション（ＡＰＬ２０，ＡＰＬ１，ＡＰＬ２）は、初期化時にアプリケーションが使用する物理キュー１３を固定的に紐付けて動作する（図２３の破線囲み参照）。アプリケーションのスレッド（以下、アプリスレッドという）はアクセラレータ１１に対応するRing Buffer１６（図２４参照）を介して送受信処理を行う。アプリスレッド１５は、ここではPollingThreadである。

図２４は、図２３のＤＰＤＫシステムのポーリングによる受信処理を説明する図である。
アプリスレッド（PollingThread）１５およびパケット処理ＡＰＩ１４は、ユーザ空間（user space）３０上に配置される。
ポーリングによる受信処理では、転送すべきデータがあるときに該当データのポインタをRing Buffer１６に格納する（図２４の符号ａ参照）。
アクセラレータ１１からの遅延を抑制するために、アプリスレッド１５はRing Buffer１６をポーリングし、転送すべきデータがあるときに該当データのポインタを取得し受信処理を行う（図２４の符号ｂ参照）。その際、アプリスレッド１５はポーリングによりＣＰＵ使用率が１００％となり、消費電力が増大する。
ＤＰＤＫは、アプリスレッド１５がパケット到着をポーリングするため遅延は少ないが消費電力が増大する。図２３に示すように、複数のアプリケーションＡＰＬ１，ＡＰＬ２がある場合、消費電力の増大の影響は甚大である。

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

THE LINUX FOUNDATION PROJECTS DPDK, ［online］,［令和３年１１月５日検索］,インターネット〈http:// www.dpdk.org/〉 Kei Fujimoto, Kenichi Matsui, Masayuki Akutsu, "KBP: Kernel Enhancements for Low-Latency Networking without Application Customization in Virtual Server", IEEE CCNC 2021.

しかしながら、ポーリングモデルによるパケット転送では、下記課題がある。
ＤＰＤＫでは、kernel threadはpolling（ＣＰＵでキューをbusy poll）を行うために、ＣＰＵコアを専有する。このため、例えば間欠的なパケット受信であっても、ＤＰＤＫでは、パケット到着有無に関わらず、ＣＰＵを常に１００％使用するため、消費電力が大きくなる課題がある。
ＫＢＰについても、上記ＤＰＤＫと同様の課題がある。すなわち、ＫＢＰは、kernel内でpollingモデルによりパケット到着を常時監視することで、softIRQを抑止し、低遅延なパケット処理を実現することができる。しかし、パケット到着を常時監視するkernel threadがＣＰＵコアを専有し、常にＣＰＵタイムを使用するため、消費電力が高くなる課題がある。

このような背景を鑑みて本発明がなされたのであり、本発明は、物理サーバに搭載されたアクセラレータリソースを複数のアプリケーションで使用する際、アクセラレータからアプリケーションへのデータ転送遅延を抑えつつ、データのポーリングに用いるＣＰＵの消費電力を削減することを課題とする。

前記した課題を解決するため、アクセラレータを含むデバイスをアプリケーションで使用する際、前記デバイスから前記アプリケーションへのデータ転送を行うサーバ内データ転送装置であって、前記デバイスと前記アプリケーションに対応するアプリスレッドとの間の通信を監視しデータ到着タイミングを計るデータ到着監視部と、前記データ到着監視部がデータの到着を検知したデータ到着時に前記アプリスレッドを起床させてデータを受信させ、前記データの到着がない間はSleepさせるポーリング制御部と、前記デバイスの物理キューの代わりとなる仮想キューを用いて、前記デバイスと前記アプリケーションに対応するアプリスレッドにデータ処理を行わせることで、前記アプリケーションに対して前記デバイスを接続するデバイス擬似部と、前記仮想キューと前記物理キューの間を動的に接続変更するプロキシ部と、を備えることを特徴とする。

本発明によれば、物理サーバに搭載されたアクセラレータリソースを複数のアプリケーションで使用する際、アクセラレータからアプリケーションへのデータ転送遅延を抑えつつ、データのポーリングに用いるＣＰＵの消費電力を削減することができる。

本発明の実施形態に係るサーバ内データ転送システムの概略構成図である。本発明の実施形態に係るサーバ内データ転送システムのブロック構成図である。本発明の実施形態に係るサーバ内データ転送システムのアプリスレッドのsleep制御動作を説明する図である。図３のアプリスレッドのsleep制御動作の制御シーケンス図である。本発明の実施形態に係るサーバ内データ転送システムのアクセラレータとの通信プロキシを説明する図である。本発明の実施形態に係るサーバ内データ転送システムのプロキシ部のスレッドＩＤと物理キューの対応表を示す図である。本発明の実施形態に係るサーバ内データ転送システムのプロキシ部の仮想キューテーブルを示す図である。本発明の実施形態に係るサーバ内データ転送システムのプロキシ部の論物マッピングテーブルを示す図である。本発明の実施形態に係るサーバ内データ転送システムのプロキシ部の物理キューテーブルを示す図である。本発明の実施形態に係るサーバ内データ転送システムのポーリング制御において、パケット到着情報を用いた起床判断処理を示すフローチャートである。本発明の実施形態に係るサーバ内データ転送システムのポーリング制御において、タイミング情報(統計)を用いた起床判断処理を示すフローチャートである。本発明の実施形態に係るサーバ内データ転送システムの仮想キューのパケットタイマをテーブルにして示す図である。本発明の実施形態に係るサーバ内データ転送システムの仮想キューの閾値テーブルを示す図である。本発明の実施形態に係るサーバ内データ転送システムのパケット送信の制御シーケンス図である。本発明の実施形態に係るサーバ内データ転送システムのパケット受信・ポーリングの制御シーケンス図である。本発明の実施形態に係るサーバ内データ転送システムのＩＰコアスケールインの制御シーケンス図である。図１６のＩＰコアスケールインを説明する図である。本発明の実施形態に係るサーバ内データ転送システムの論物マッピングテーブル更新処理を示すフローチャートである。本発明の実施形態に係るサーバ内データ転送システムのスレッドスケールインの制御シーケンス図である。本発明の実施形態に係るサーバ内データ転送システムのスレッドスケールインを説明する図である。本発明の実施形態に係るサーバ内データ転送システムの論物マッピングテーブル更新処理を示すフローチャートである。本発明の実施形態に係るサーバ内データ転送システムのサーバ内データ転送装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。アクセラレータを備えるＨＷの制御を行うＤＰＤＫシステムの構成を示す図である。図２３のＤＰＤＫシステムのポーリングによる受信処理を説明する図である。

以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるサーバ内データ転送システム等について説明する。
（実施形態）
［全体構成］
図１は、本発明の実施形態に係るサーバ内データ転送システムの概略構成図である。図２３と同一構成部分には、同一符号を付している。
図１に示すように、サーバ内データ転送システム１０００は、ＨＷ１０、パケット処理ＡＰＩ１４、コントローラ（ＣＴＲＬ）（サーバ内データ転送装置）１００、アプリケーション（ＡＰＬ）２０を有する。

コントローラ１００は、アプリケーション２０とＨＷ１０との間に配置される。このため、パケット処理ＡＰＩ１４は、アプリケーション２０とコントローラ１００間に配置された形となるが、アプリケーション２０からみると、コントローラ１００の存在は見えず、ＮＩＣやアクセラレータに向けてパケット処理をオフロードする際のＡＰＩである。

コントローラ１００は、アクセラレータ１１を含むデバイスをアプリケーション２０で使用する際、デバイスからアプリケーション２０へのデータ転送を行うサーバ内データ転送装置である。
コントローラ１００は、アプリスレッド１５と複数のアクセラレータ１１のＩＰコア１２の間の紐付けを管理し、アプリケーション２０の代わりにアクセラレータ１１との通信を行う。

コントローラ１００は、パケット到着監視部１１０と、ポーリング制御部１２０と、デバイス擬似部１３０と、プロキシ部１４０と、を備える。

パケット到着監視部１１０は、アクセラレータ１１（デバイス）とアプリスレッド１５との間の通信を監視しパケット到着タイミングを計る。すなわち、アクセラレータ１１とアプリスレッド１５との間で処理が終わった後のパケットがアプリケーションで受信するために上がってくるが、パケット到着監視部１１０は、このパケット到着を監視して、アクセラレータ１１からのパケット到着タイミングを計る。

ポーリング制御部１２０は、パケット到着監視部１１０がパケット到着を検知したパケット到着時にアプリスレッド１５を起床させてパケット処理を促し、パケットがない間はSleepさせる。
いままでは、１００％起きてポーリング処理していたものを、不要な時は、パケット処理を止める（ポーリングを止める；Sleepさせる）。ポーリング制御部１２０は、パケット到着時だけアプリスレッド１５を起床させる）。

デバイス擬似部１３０は、アプリケーション２０に対して既存と同等のインターフェイスで接続し、デバイスの物理キュー１３の代わりに仮想キュー２００（図５参照）を提供する。
デバイス擬似部１３０は、デバイスの物理キューに対応し、当該物理キューの代わりに仮想キュー２００を用いて、アプリスレッド１５にパケット処理を行わせることで、アプリケーション２０に対してデバイスを接続する。
仮想キュー２００は、物理キュー１３の代わりにアプリスレッド１５に見せているキューである。

アプリケーション２０からは、アクセラレータ１１を常に使っている（アクセラレータ１１と常に通信している）と思わせたい（換言すれば、コントローラ１００をアクセラレータ１１から隠したい）。デバイス擬似部１３０は、アプリケーション２０に対して既存と同等のインターフェイスで接続し、デバイスの物理キュー１３の代わりに仮想キュー２００を提供する。これにより、アプリケーション２０は、アクセラレータ１１と常に通信しているように見せかける。

プロキシ部１４０は、仮想キュー２００と物理キュー１３の間を動的に接続変更する。
仮想キュー２００によって、アプリスレッド１５からパケットが来たときに、そのパケットをアクセラレータ１１まで届ける必要があるが、プロキシ部１４０は、仮想キュー２００と物理キュー１３の間を接続する。

プロキシ部１４０は、仮想キュー２００に対する物理キュー１３の紐付けを変更すると同時にＩＰコア１２やアプリスレッド１５の増減を指示する。プロキシ部１４０は、さらに、１つのアプリスレッド１５に対して複数の物理キュー（１：Ｎ）や、複数のアプリスレッド１５に対して１つの物理キュー（Ｍ：１）を紐づける（ＮおよびＭは、任意の自然数）。

［サーバ内データ転送システム］
図２は、コントローラ１００を備えるサーバ内データ転送システム１０００のブロック構成図である。図１と同一構成部分には、同一符号を付している。
サーバ内データ転送システム１０００は、ユーザ空間３０上に配置されるアプリスレッド１５と、複数の物理キュー１３およびＩＰコア１２を有するアクセラレータ１１と、コントローラ１００と、を備える。

また、サーバ内データ転送システム１０００には、ＲＩＣ（RAN Intelligent Controller）などの外部コントローラ５０が接続される。ＲＩＣは、ＲＡＮ（Radio Access Network）アーキテクチャというソフトウェアによって定義されたコンポーネントであり、ＲＡＮ機能の制御と最適化、インテリジェント化を実現する。

図２の白抜き矢印は、データの流れを示しており、データ送受信処理の流れからみると、コントローラ１００は、アプリスレッド１５とアクセラレータ１１間に介在した構成である。

コントローラ１００は、パケット到着監視部１１０と、ポーリング制御部１２０と、デバイス擬似部１３０と、プロキシ部１４０と、統合制御部１５０と、アプリ制御部１６０と、デバイス制御部１７０と、外部コントローラＩＦ１８０と、を備える。
統合制御部１５０は、各部を統合制御する。統合制御部１５０は、外部コントローラＩＦ１８０の要求に対しスケールイン判断を行う（後記図１９参照）。また、統合制御部１５０は、プロキシ部１４０に「論物マッピングテーブル更新要求」を行う（後記図１９参照）。統合制御部１５０は、デバイス制御部１７０に、スケールイン要求を行う（後記図１９）。

アプリ制御部１６０は、統合制御部１５０からの指示に従ってアプリスレッド１５を制御する。
デバイス制御部１７０は、統合制御部１５０からの指示に従ってアクセラレータ１１を制御する。
外部コントローラＩＦ１８０は、外部コントローラ５０からの指示を受ける。

以下、上述のように構成されたサーバ内データ転送システムの動作を説明する。
［アプリスレッドのSleep制御動作］
図３は、アプリスレッドのSleep制御動作を説明する図である。図１および図２４と同一構成部分には、同一符号を付している。
アプリスレッド１５、パケット処理ＡＰＩ１４、およびコントローラ１００は、ユーザ空間３０上に配置される。

上述したように、複数のアプリケーションＡＰＬ１，ＡＰＬ２（図１参照）がある場合、消費電力の増大の影響は甚大である。そこで、複数のアプリケーションＡＰＬ１，ＡＰＬ２がある場合のアプリスレッドのSleep制御動作について説明する。
複数のアプリケーションＡＰＬ１，ＡＰＬ２について、それぞれ複数のアプリスレッド１５が存在する。
コントローラ１００のポーリング制御部１２０（図１参照）は、パケット到着時にアプリスレッド１５を起床させてパケット処理を促し、パケットがない間はSleepさせる。

コントローラ１００のパケット到着監視部１１０（図１参照）は、アクセラレータ１１との通信を監視しパケット到着タイミングを計る。
パケット到着監視部１１０（図１参照）は、ポーリングによる受信処理では、転送すべきデータのポインタを物理キュー４１を用いて、Ring Buffer１７（Ring Buffer<１>）に格納する（図３の符号ａ参照）。

ちなみに、従来であれば、図２４に示すように、アプリスレッド１５はRing Buffer１６をポーリングし、パケットを刈り取っていた。

これに対し、本実施形態では、パケット到着監視部１１０（図１参照）は、アプリスレッド１５に代わって、仮想キュー２００（図５参照）を用いて、Ring Buffer１７をポーリングし、転送すべきデータがあるときに該当データのポインタを取得し受信処理を行う（図３の符号ｂ参照）。

プロキシ部１４０は、アプリスレッド１５に代わって、転送すべきデータのポインタを、Ring Buffer１８（Ring Buffer<２>）（＝仮想キュー２００）に格納する（図３の符号ｃ参照）。

ポーリング制御部１２０は、アプリスレッド１５に対してイベントを通知する（図３の符号ｄ参照）。

アプリスレッド１５は、転送すべきデータがあるときに該当データのポインタを仮想キュー２００を用いて取得する（図３の符号ｅ参照）。

ここで、パケット到着監視部１１０が、すべてのアプリスレッド１５を代表して物理キュー１３のポーリングを行う。これにより、複数のアプリスレッド１５がある場合であっても、１つのパケット到着監視部１１０のみで物理キュー１３の監視ができる。例えば、図２３の場合、複数のアプリケーションＡＰＬ１，ＡＰＬ２に対し複数の（６つの）アプリスレッド１５が並列で処理が存在し、図２３の従来例であればその６つのアプリスレッド１５についてポーリングを行う必要があった。これに対し、本実施形態では、並列に存在する複数のアプリスレッド１５に対して、１つのパケット到着監視部１１０による全物理キュー１３のポーリングだけで、すべての物理キュー１３を監視できる。このため、単純計算で、電力消費を１／６に抑えることができる。ポーリングをすべてなくせなくても課題は解決できる。

以上、アプリスレッド１５の代わりにコントローラ１００が代表してアクセラレータ１１のパケット到着を監視しRing Buffer１７をポーリングする。
コントローラ１００がイベント通知等の方法でアプリスレッド１５にパケット到着を通知する。

図４は、図３のアプリスレッドのsleep制御動作の制御シーケンス図である。
アプリスレッド１５は、Ring Buffer１７にアクセラレータ実行要求を通知し（Ｓ１）、Ring Buffer１７は、この実行要求をRing Buffer１８に通知する（Ｓ２）。Ring Buffer１８は、この実行要求をアクセラレータ１１に通知する（Ｓ３）。

ここで、コントローラ１００は、アプリスレッド１５が、Ring Buffer１７にアクセラレータ実行要求を通知すると、アプリスレッド１５をSleepさせる（図４の符号ｆ参照）。

アクセラレータ１１は、アクセラレータ１１からの要求を実行し（Ｓ４）、処理結果をRing Buffer１８に送信する（Ｓ５）。コントローラ１００のパケット到着監視部１１０は、アクセラレータ１１との通信を監視しており、コントローラ１００は、Ring Buffer１８との間で、アプリスレッド１５に代わって、Ring Buffer１８をポーリングする（図４の符号ｇ参照）。

コントローラ１００は、イベント通知等の方法でアプリスレッド１５にパケット到着を通知する（図４の符号ｈ参照）。

Ring Buffer１８は、処理結果をRing Buffer１７に送信し（Ｓ６）、Ring Buffer１７は、イベント通知を受けて起床したアプリスレッド１５からデータ送信要求があった場合にアクセラレータ１１の処理結果をアプリスレッド１５に送信する（Ｓ７）。

このように、コントローラ１００が代表してアクセラレータ１１からのパケット到着をポーリングにより監視できる。このため、アプリスレッド１５がそれぞれでポーリングによりパケット到着を監視する必要がなくなり、消費電力を削減することができる。

コントローラ１００は、全てのアプリスレッド１５の通信を監視できるため、全てのアプリスレッド１５のポーリングを効率化し、サーバ全体の消費電力の削減が可能になる。

サーバ内データ転送システム１０００は、パケット到着時にコントローラ１００からアプリスレッド１５に対してイベント通知を行う、パケット送受信間隔の統計データから得たタイミング情報をもとにイベント通知を行う、などの方法で遅延を抑制することが可能になる。

［アクセラレータとの通信プロキシ］
図５は、アクセラレータとの通信プロキシを説明する図である。図１と同一構成部分には、同一符号を付している。
アプリケーション２０にとってアクセラレータ１１と同様に扱えるように、コントローラ１００が既存と同等のインターフェイスを持った擬似的なデバイスとしてアプリケーション２０との通信を行う。その際、アプリケーション２０に対して物理キュー１３の代わりに仮想キュー２００を提供する。
デバイス擬似部１３０（図１、図２）は、アプリケーションに対して既存と同等のインターフェイスで接続し、デバイスの物理キュー１３の代わりに仮想キュー２００を提供する。

図６は、プロキシ部１４０のスレッドＩＤと物理キュー１３の対応表２１０を示す図である。
スレッドＩＤ「１００１…」ごとに対応する物理キュー１３を割り当てる。例えば、図５に示すアクセラレータ１１のＩＰコア１２の左から順に、物理キュー（０～５）がある場合、スレッドＩＤ「１００１」は、図５に示すアクセラレータ１１のＩＰコア１２の一番左の物理キュー（０）に割り当てられる。スレッドＩＤに対して複数の物理キューを割り当てることも可能である。例えば、スレッドＩＤ「１００３」は、図５に示すアクセラレータ１１のＩＰコア１２の物理キュー（２，３）に割り当てられる。この例は、仮想キューから見たときの接続が物理キュー（２，３）に分岐していることで示される。逆に、スレッドＩＤ「２００１」と「２００２」は、いずれも物理キュー（４）に割り当てられる。この例は、接続が物理キュー（４）に集約していることで示される。
なお、従来では、スレッドＩＤと物理キューは１対１に対応しており、上記分岐・集約はない。

図７は、プロキシ部１４０の仮想キューテーブル２２０を示す図である。
仮想キューテーブル２２０は、スレッドＩＤがどの仮想キューに対応しているかを記述する。
スレッドＩＤと仮想キューは、１対１で対応している。例えば、スレッドＩＤ「１００１」は、仮想キュー（０）に対応し、スレッドＩＤ「１００２」は、仮想キュー（１）に対応している。なお、Proc_type（プロセスタイプ）は、アクセラレータにどのような種別の処理をさせたいかを規定する。例えば、Proc_type「１」は、種別１の処理に対応するＩＰコア１２に接続可能であり、Proc_type「２」は、種別２の処理に対応するＩＰコア１２に接続可能である、などである。ＡＰＬは、スレッドが複数のアプリケーションに対応しているとき、そのアプリケーション種別を記述する。「状態」は、スレッドがアクティブ（Used）か非アクティブ（空欄）かを記述する。

図８は、プロキシ部１４０の論物マッピングテーブル２３０を示す図である。
論物マッピングテーブル２３０は、仮想キュー（０～４）に対して物理キュー（０～３）を割り当てる。例えば、仮想キュー（０）に対して物理キュー０を割り当て、仮想キュー（１）に対して物理キュー１を割り当てる。なお、複数の物理キュー（物理キュー２，３）を仮想キュー（３）に割り当てることも可能である。

図９は、プロキシ部１４０の物理キューテーブル２４０を示す図である。
ＩＰコアＩＤは、実際に処理を行うコアのＩＤであり、ＩＰコアＩＤごとに、物理キュー、Proc_type、デバイスＩＤ、「状態」が対応付けられる。Proc_typeは、同じ種別の処理でないと繋げないことを記述している。デバイスＩＤは、アクセラレータで処理されるアクセラレータの種別を示しており、例えばデバイスＩＤ「１」であればアクセラレータ１が対応していることを記述する。

［ポーリング制御］
<パケット到着情報を用いた起床判断>
図１０は、ポーリング制御において、パケット到着情報を用いた起床判断処理を示すフローチャートである。
ステップＳ１１でポーリング制御部１２０は、パケット到着監視部１１０がパケット到着を確認したか否かを判別する。パケット到着を確認できない場合（Ｓ１１：Ｎｏ）、ステップＳ１１に戻ってパケット到着を待つ。

パケット到着を確認できた場合（Ｓ１１：Ｙｅｓ）、ステップＳ１２でポーリング制御部１２０は、仮想キュー２００に対応するアプリスレッド１５（以下の説明において、アプリスレッド１５は、ポーリング制御におけるスレッドであるため、ポーリングスレッド１５と表記する）に対して起床指示を送信する。

ステップＳ１３でポーリング制御部１２０は、ポーリングスレッド１５が起床しパケットを刈り取ったか否かを判別する。パケットを刈り取っていない場合（Ｓ１３：Ｎｏ）、ステップＳ１３に戻ってパケット刈り取りを待つ。

パケットを刈り取った場合（Ｓ１３：Ｙｅｓ）、ステップＳ１４でポーリング制御部１２０は、仮想キュー２００に対応するポーリングスレッド１５に対して次の刈り取りまでSleepを指示して本フローの処理を終了する。

<タイミング情報(統計)を用いた起床判断>
図１１は、ポーリング制御において、タイミング情報(統計)を用いた起床判断処理を示すフローチャートである。
ステップＳ２１でポーリング制御部１２０は、仮想キュー２００を選択する。
ステップＳ２２でポーリング制御部１２０は、仮想キュー２００のパケットタイマ２５０（図１２参照）で最大のものを確認する。

図１２は、仮想キュー２００のパケットタイマ２５０をテーブルにして示す図である。
パケットＩＤごとに仮想キューおよびタイマを設定する。
仮想キュー２００ごとにタイマを設定しておくことで、パケット到着時の起床のタイミングをあらかじめ設定しておくことができ、Sleep制御の実効を図ることができる。

図１１に戻り、ステップＳ２３でポーリング制御部１２０は、パケットタイマ２５０は仮想キュー２００の閾値を超えているか否かを判別する。

図１３は、仮想キュー２００の閾値テーブル２６０を示す図である。
仮想キューごとに刈り取りをするか否かの閾値を設定する。例えば、仮想キュー（０）が、閾値「２００」になるまでは刈り取りを行わない、ことを設定する。

図１１に戻り、パケットタイマ２５０が仮想キュー２００の閾値を超えていない場合（Ｓ２３：Ｎｏ）、ステップＳ２１に戻ってパケットタイマ２５０が仮想キュー２００の閾値を超えるまでステップＳ２１およびステップＳ２２を繰り返す。パケットタイマ２５０の閾値は、パケット送信から受信までの統計情報から別途設定する。

パケットタイマ２５０が仮想キュー２００の閾値を超えた場合（Ｓ２３：Ｙｅｓ）、ステップＳ２４でポーリング制御部１２０は、仮想キュー２００に対応するポーリングスレッドに対して起床指示を送信する。

ステップＳ２５でポーリング制御部１２０は、スレッドが起床しパケットを刈り取ったか否かを判別する。パケットを刈り取っていない場合（Ｓ２５：Ｎｏ）、ステップＳ２５に戻ってパケット刈り取りを待つ。

スレッドが起床しパケットを刈り取った場合（Ｓ２５：Ｙｅｓ）、ステップＳ２６でポーリング制御部１２０は、仮想キュー２００に対応するポーリングスレッド１５に対して次の刈り取りまでsleepを指示して本フローの処理を終了する。

［パケット送信］
図１４は、パケット送信の制御シーケンス図である。本パケット送信は、<ポーリングパターン>と<ポーリングなしパターン>とがある。なお、このポーリングはパケット到着監視部１１０と仮想キュー２００間のポーリングである。

<ポーリングパターン>
アプリスレッド１５は、仮想キュー２００にパケットのポインタ情報を送信する（Ｓ１０１）。
一方、パケット到着監視部１１０は、パケット到着をポーリングにより確認する（Ｓ１５１）。
仮想キュー２００は、パケット到着監視部１１０に「パケット到着あり」および「パケットのポインタ情報」の通知を行う（Ｓ１５２）。

パケット到着監視部１１０は、仮想キュー２００からの「パケット到着あり」および「パケットのポインタ情報」を受けて、プロキシ部１４０に「パケットのポインタ情報」を送信する（Ｓ１０５）。

プロキシ部１４０は、「パケットのポインタ情報」を受けて、仮想キュー２００に対応する物理キュー１３の確認を行う（Ｓ１０６）。
プロキシ部１４０は、物理キュー１３に「パケットのポインタ情報」を送信する（Ｓ１０７）。

この<ポーリングパターン>（ポーリングありパターン）によるパケット送信は、下記<ポーリングなしパターン>のようなコントローラ１００への通知がない。

<ポーリングなしパターン>
上記<ポーリングパターン>と同一手順には同一ステップ番号を付している。
アプリスレッド１５は、仮想キュー２００にパケットのポインタ情報を送信するとともに（Ｓ１０１）、パケット到着監視部１１０に「パケット到着あり」の通知を行う（Ｓ１０２）。
アプリスレッド１５からの「パケット到着あり」の通知を受けて、パケット到着監視部１１０は、仮想キュー２００に対してパケット到着確認を行う（Ｓ１０３）。仮想キュー２００は、パケット到着監視部１１０に「パケット到着あり」および「パケットのポインタ情報」を送信する（Ｓ１０４）。

［パケット受信・ポーリング制御］
図１５は、パケット受信・ポーリングの制御シーケンス図である。
パケット到着監視部１１０は、物理キュー１３に対してパケット到着をポーリングにより確認する（Ｓ１１１）。物理キュー１３は、パケット到着監視部１１０に「パケット到着あり」および「パケットのポインタ情報」を送信する（Ｓ１１２）。

パケット到着監視部１１０は、物理キュー１３からの「パケット到着あり」および「パケットのポインタ情報」を受けて、プロキシ部１４０に「パケットのポインタ情報」を送信する（Ｓ１１３）。

プロキシ部１４０は、「パケットのポインタ情報」を受けて、物理キュー１３に対応する仮想キュー２００の確認を行う（Ｓ１１４）。
プロキシ部１４０は、仮想キュー２００に「パケットのポインタ情報」を送信するとともに（Ｓ１１５）、パケット到着監視部１１０に「対応する仮想キュー情報」を送信する（Ｓ１１６）。

パケット到着監視部１１０は、プロキシ部１４０からの「対応する仮想キュー情報」を受けて、ポーリング制御部１２０に「パケット到着あり」を送信する（Ｓ１１７）。
ポーリング制御部１２０は、パケット到着監視部１１０からの「パケット到着あり」を受けて、アプリスレッド１５に「イベント通知」を行う（Ｓ１１８）。

アプリスレッド１５は、「起床処理」を行う（Ｓ１１９）。
アプリスレッド１５は、仮想キュー２００に「パケットのポインタ情報」を要求する（Ｓ１２０）。仮想キュー２００は、この要求を受けて、仮想キュー２００に「パケットのポインタ情報」を送信する（Ｓ１２１）。

［ＩＰコアスケールイン］
図１６は、ＩＰコアスケールインの制御シーケンス図である。
外部コントローラＩＦ１８０は、統合制御部１５０に「スケールイン判断要求」を行う（Ｓ１３１）。
統合制御部１５０は、スケールイン判断を行う（Ｓ１３２）。
統合制御部１５０は、プロキシ部１４０に「論物マッピングテーブル更新要求」を行う（Ｓ１３３）。プロキシ部１４０は、論物マッピングテーブル２３０（図８参照）を更新し（図１８の論物マッピングテーブル更新参照）、統合制御部１５０にその旨を通知する（Ｓ１３５）。

ＩＰコアスケールイン処理では、ＩＰコア１２のうち、ＩＰコア＃２がスケールインされる場合を例にとる（図１７参照）。
統合制御部１５０は、デバイス制御部１７０に「ＩＰコア＃２スケールイン要求」を行う（Ｓ１３６）。デバイス制御部１７０は、ＩＰコア＃２の電源停止操作を行うとともに（Ｓ１３７）、統合制御部１５０に「ＩＰコア＃２スケールイン完了」を通知する（Ｓ１３８）。

図１７は、図１６のＩＰコアスケールインを説明する図である。図５と同一構成部分には、同一符号を付している。
図１６のＩＰコアスケールイン処理により、ＩＰコア＃２はスケールインされる（図１７の破線矢印ｉ参照）。

図１８は、論物マッピングテーブル更新処理を示すフローチャートである。
ステップＳ３１でプロキシ部１４０は、スケールインする物理キューに対応する仮想キュー２００があるか否かを判別する。対応する仮想キュー２００がない場合（Ｓ３１：Ｎｏ）、本フローによる論物マッピングテーブル更新処理を正常終了する。

対応する仮想キュー２００がある場合（Ｓ３１：Ｙｅｓ）、ステップＳ３２でプロキシ部１４０は、仮想キュー２００を１つ選択する。

ステップＳ３３でプロキシ部１４０は、仮想キュー２００のproc_typeと同じproc_typeの物理キュー１３があるか否かを判別する。仮想キュー２００のproc_typeと同じproc_typeの物理キュー１３がない場合（Ｓ３３：Ｎｏ）、本フローによる論物マッピングテーブル更新処理をＮＧ終了する。

上記ステップＳ３３で仮想キュー２００のproc_typeと同じproc_typeの物理キュー１３がある場合（Ｓ３３：Ｙｅｓ）、仮想キュー２００と物理キュー１３の再紐付けを行うと判断してステップＳ３４でプロキシ部１４０は、複数デバイスがある場合デバイスを選択する（ただしポリシーによる）。このポリシーは、例えばなるべく負荷が高いデバイスに集中させる（集約）、または負荷が小さいデバイスに分散する（負荷分散）である。

ステップＳ３５でプロキシ部１４０は、複数物理キュー１３がある場合物理キュー１３を選択（ポリシーによる）する。このポリシーは、例えばなるべく負荷が高い物理キューに集中させる（集約）、または負荷が小さい物理キューに分散する（負荷分散）である。

ステップＳ３６でプロキシ部１４０は、論物マッピングテーブル２３０（図８参照）から仮想キュー２００と紐付けする物理キュー１３のセルの値を１に変更する。

ステップＳ３７でプロキシ部１４０は、論物マッピングテーブル２３０から仮想キュー２００とスケールイン物理キュー１３のセルの値を０に変更して上記ステップＳ３１に戻る。

［スレッドスケールイン］
図１９は、スレッドスケールインの制御シーケンス図である。
外部コントローラＩＦ１８０は、統合制御部１５０に「スケールイン判断要求」を行う（Ｓ１４１）。
統合制御部１５０は、スケールイン判断を行う（Ｓ１４２）。
統合制御部１５０は、プロキシ部１４０に「論物マッピングテーブル更新要求」を行う（Ｓ１４３）。プロキシ部１４０は、論物マッピングテーブル２３０（図８参照）を更新し（Ｓ１４４）（図２１の論物マッピングテーブル更新参照）、統合制御部１５０にその旨を通知する（Ｓ１４５）。

スレッドスケールイン処理では、アプリスレッド１５のうち、スレッド＃２がスケールインされる場合を例にとる（図２０参照）。
統合制御部１５０は、デバイス制御部１７０に「スレッド＃２スケールイン要求」を行う（Ｓ１４６）。デバイス制御部１７０は、スレッド＃２のポーリング停止操作を行うとともに（Ｓ１４７）、統合制御部１５０に「スレッド＃２スケールイン完了」を通知する（Ｓ１４８）。

図２０は、スレッドスケールインを説明する図である。図５および図１７と同一構成部分には、同一符号を付している。
図１９のスレッドスケールイン処理により、図２０に示すスレッド＃２はスケールインされる（図２０の破線矢印ｊ参照）。

図２１は、論物マッピングテーブル更新処理を示すフローチャートである。
ステップＳ４１でプロキシ部１４０は、スケールインする仮想キューに対応する物理キュー１３があるか否かを判別する。対応する物理キュー１３がない場合（Ｓ４１：Ｎｏ）、本フローによる論物マッピングテーブル更新処理を正常終了する。

対応する物理キュー１３がある場合（Ｓ４１：Ｙｅｓ）、ステップＳ４２でプロキシ部１４０は、物理キュー１３を１つ選択する。

ステップＳ４３でプロキシ部１４０は、物理キュー１３のproc_typeと同じproc_typeの仮想キュー２００があるか否かを判別する。物理キュー１３のproc_typeと同じproc_typeの仮想キュー２００がない場合（Ｓ４３：Ｎｏ）、ステップＳ４７に進む。

上記ステップＳ４３で物理キュー１３のproc_typeと同じproc_typeの仮想キュー２００がある場合（Ｓ４３：Ｙｅｓ）、仮想キュー２００と物理キュー１３の再紐付けを行うと判断してステップＳ４４でプロキシ部１４０は、複数アプリがある場合アプリを選択する（ただしポリシーによる）。このポリシーは、例えばなるべく負荷が高いＡＰＬに集中させる（集約）、または負荷が小さいＡＰＬに分散する（負荷分散）である。

ステップＳ４５でプロキシ部１４０は、複数仮想キュー２００がある場合仮想キュー２００を選択する（ただしポリシーによる）。このポリシーは、例えばなるべく負荷が高い仮想キューに集中させる（集約）、または負荷が小さい仮想キューに分散する（負荷分散）である。

ステップＳ４６でプロキシ部１４０は、論物マッピングテーブル２３０（図８参照）から物理キュー１３と紐付けする仮想キュー２００のセルの値を１に変更する。

ステップＳ４７でプロキシ部１４０は、論物マッピングテーブル２３０から物理キュー１３とスケールイン仮想キュー２００のセルの値を０に変更して上記ステップＳ４１に戻る。

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

アクセラレータ９０５は、通信Ｉ／Ｆ９０８からのデータ、または、ＲＡＭ９０２からのデータの少なくとも一方のデータを高速に処理するアクセラレータ（デバイス）１１（図１、図５）である。なお、アクセラレータ９０５として、ＣＰＵ９０１またはＲＡＭ９０２からの処理を実行した後にＣＰＵ９０１またはＲＡＭ９０２に実行結果を戻すタイプ（look-aside型）を用いてもよい。一方、アクセラレータ９０５として、通信Ｉ／Ｆ９０８とＣＰＵ９０１またはＲＡＭ９０２との間に入って、処理を行うタイプ（in-line型）を用いてもよい。

アクセラレータ９０５は、通信Ｉ／Ｆ９０８を介して外部装置９１５と接続される。入出力Ｉ／Ｆ９０６は、入出力装置９１６と接続される。メディアＩ／Ｆ９０７は、記録媒体９１７からデータを読み書きする。

ＣＰＵ９０１は、ＲＯＭ９０３またはＨＤＤ９０４に格納されたプログラムに基づいて動作し、ＲＡＭ９０２に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、図１、図３、図５に示すコントローラ１００の各部の制御を行う。そして、このプログラムは、通信回線を介して配布したり、ＣＤ－ＲＯＭ等の記録媒体９１７に記録して配布したりすることも可能である。
ＲＯＭ９０３は、コンピュータ９００の起動時にＣＰＵ９０１によって実行されるブートプログラムや、コンピュータ９００のハードウェアに依存するプログラム等を格納する。

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

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

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

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

［効果］
以上説明したように、本実施形態に係るサーバ内データ転送装置は、アクセラレータ１１を含むデバイスをアプリケーション２０で使用する際、デバイスからアプリケーション２０へのデータ転送を行うサーバ内データ転送装置（コントローラ１００）であって、デバイスとアプリケーション２０に対応するアプリスレッド１５との間の通信を監視しパケット到着タイミングを計るパケット到着監視部１１０と、パケット到着監視部１１０がパケット到着を検知したパケットの到着時にアプリスレッド１５を起床させてパケット処理を行わせ、パケットの到着がない間はSleepさせるポーリング制御部１２０と、を備える。

このようにすることで、パケット到着監視部１１０およびポーリング制御部１２０を備えたコントローラ（サーバ内データ転送装置）１００がアプリケーション２０とアクセラレータ１１を仲介する構成をとる。

コントローラ１００が代表してアクセラレータ１１からのパケット到着をポーリングにより監視できるため、アプリスレッド１５がそれぞれでポーリングによりパケット到着を監視する必要がなくなり、消費電力を削減することができる。

コントローラ１００は、全てのアプリスレッド１５の通信を監視できるため、全てのアプリスレッド１５のポーリングを効率化してサーバ全体の消費電力の削減が可能になる。

また、コントローラ１００は、パケット到着時にアプリスレッド１５に対してイベント通知を行う、パケット送受信間隔の統計データからタイミング情報をもとにイベント通知を行う、などの方法で遅延を抑制することが可能になる。

さらに、ｖＲＡＮ（virtual Radio Access Network：仮想無線アクセスネットワーク）等、アクセラレータを用いてデータ処理を高速化するネットワークアプリケーションを同一サーバに複数搭載する際、本システムを適用することで、以下の効果が得られる。

省電力性：各アプリスレッド１５におけるポーリングが不要になり、ＣＰＵコアの消費電力を大幅に削減することができる。

効率性（動的な側面）：昼夜のように大きく需要が変化するケースでは、ＩＰコアスケールインやスレッドスケールインにより不要なリソースを停止することで消費電力の削減を図ることができる。

効率性（静的な側面）：アクセラレータ１１に余力のある場合には１つの物理キューに対して複数のアプリケーションの仮想キューを紐付けることでアクセラレータに収容可能なユーザ数を増加することができる。

本実施形態に係るサーバ内データ転送装置（コントローラ）１００は、デバイスの物理キューに対応し、当該物理キューの代わりに仮想キュー２００を用いて、アプリスレッド１５にパケット処理を行わせることで、アプリケーション２０に対してデバイスを接続するデバイス擬似部１３０と、仮想キュー２００と物理キュー１３の間を動的に接続変更するプロキシ部１４０と、を備える。

このように、デバイス擬似部１３０およびプロキシ部１４０を備え、デバイス擬似部１３０は、アプリケーションに対して物理キュー１３の代わりに仮想キュー２００を提供する。アプリケーション２０からは実際のアクセラレータ１１と通信しているように見えるため、改造が不要である。

コントローラ１００は、アプリスレッド１５と複数のアクセラレータ１１のＩＰコア１２の間の紐付けを管理し、アプリケーション２０の代わりにアクセラレータ１１との通信を行う。コントローラ１００は、仮想キュー２００に対する物理キュー１３の紐付けを変更すると同時にＩＰコア１２やアプリスレッド１５の増減を指示することで、需要に応じてＩＰコア１２やアプリスレッド１５を増やしたり（スケールアウト）、減らしたり（スケールイン）といった、動的なリソース変更が可能となる。

さらに、１つのアプリスレッド１５に対して複数の物理キュー（１：Ｎ）や、複数のアプリスレッドに対して１つの物理キュー（Ｍ：１）を紐付けることで、より柔軟なリソース管理や重畳によるリソース集約が可能となる。

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

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

１０ＨＷ
１１，９０５アクセラレータ（デバイス）
１２ＩＰコア（デバイスコア）
１４パケット処理ＡＰＩ
１７，１８ Ring Buffer
１５アプリスレッド（ポーリングスレッド）
２０アプリケーション（ＡＰＬ）
１００コントローラ（サーバ内データ転送装置）
１１０パケット到着監視部
１２０ポーリング制御部
１３０デバイス擬似部
１４０プロキシ部
１５０統合制御部
１６０アプリ制御部
１７０デバイス制御部
１８０外部コントローラＩＦ
２２０仮想キューテーブル
２３０論物マッピングテーブル
２４０物理キューテーブル
２５０パケットタイマ
２６０閾値テーブル
１０００サーバ内データ転送システム
ＡＰＬ１，ＡＰＬ２アプリケーション

Claims

アクセラレータを含むデバイスをアプリケーションで使用する際、前記デバイスから前記アプリケーションへのデータ転送を行うサーバ内データ転送装置であって、
前記デバイスと前記アプリケーションに対応するアプリスレッドとの間の通信を監視しデータ到着タイミングを計るデータ到着監視部と、
前記データ到着監視部がデータの到着を検知したデータ到着時に前記アプリスレッドを起床させてデータを受信させ、前記データの到着がない間はSleepさせるポーリング制御部と、
前記デバイスの物理キューの代わりとなる仮想キューを用いて、前記デバイスと前記アプリケーションに対応するアプリスレッドにデータ処理を行わせることで、前記アプリケーションに対して前記デバイスを接続するデバイス擬似部と、
前記仮想キューと前記物理キューの間を動的に接続変更するプロキシ部と、を備える
ことを特徴とするサーバ内データ転送装置。
アクセラレータを含むデバイスをアプリケーションで使用する際、前記デバイスから前記アプリケーションへのデータ転送を行うサーバ内データ転送装置であって、
前記デバイスの物理キューの代わりとなる仮想キューを用いて、前記デバイスと前記アプリケーションに対応するアプリスレッドにデータ処理を行わせることで、前記アプリケーションに対して前記デバイスを接続するデバイス擬似部と、
前記仮想キューと前記物理キューの間を動的に接続変更するプロキシ部と、を備えるとともに、
前記アプリスレッドと一または複数の前記物理キューとを対応付ける対応情報と、
前記アプリスレッドがどの仮想キューに対応しているかを記述する記述情報と、
前記仮想キューに対して前記物理キューを割り当てる論物マッピング情報と、を有し、
前記プロキシ部は、
前記アプリスレッドの減少が指示された場合、前記論物マッピング情報を参照して、スケールインする前記物理キューに対応する前記仮想キューがあるか否かを判別し、対応する前記仮想キューがある場合、前記対応情報および前記記述情報をもとに、前記物理キューと接続している前記仮想キューの数を動的に減少し、前記仮想キューを使用する前記アプリスレッドを停止させる
ことを特徴とするサーバ内データ転送装置。
アクセラレータを含むデバイスをアプリケーションで使用する際、前記デバイスから前記アプリケーションへのデータ転送を行うサーバ内データ転送装置であって、
前記デバイスの物理キューの代わりとなる仮想キューを用いて、前記デバイスと前記アプリケーションに対応するアプリスレッドにデータ処理を行わせることで、前記アプリケーションに対して前記デバイスを接続するデバイス擬似部と、
前記仮想キューと前記物理キューの間を動的に接続変更するプロキシ部と、を備えるとともに、
前記アプリスレッドと一または複数の前記物理キューとを対応付ける対応情報と、
前記アプリスレッドがどの仮想キューに対応しているかを記述する記述情報と、
前記仮想キューに対して前記物理キューを割り当てる論物マッピング情報と、を有し、
前記プロキシ部は、
前記アプリスレッドの増加が指示された場合、前記論物マッピング情報を参照して、スケールアウトする前記物理キューに対応する前記仮想キューがあるか否かを判別し、対応する前記仮想キューがある場合、前記対応情報および前記記述情報をもとに、前記物理キューと接続している前記仮想キューの数を動的に増加し、前記仮想キューを使用する前記アプリスレッドを再開させる
ことを特徴とするサーバ内データ転送装置。
アクセラレータを含むデバイスをアプリケーションで使用する際、前記デバイスから前記アプリケーションへのデータ転送を行うサーバ内データ転送装置であって、
前記デバイスの物理キューの代わりとなる仮想キューを用いて、前記デバイスと前記アプリケーションに対応するアプリスレッドにデータ処理を行わせることで、前記アプリケーションに対して前記デバイスを接続するデバイス擬似部と、
前記仮想キューと前記物理キューの間を動的に接続変更するプロキシ部と、を備えるとともに、
前記アプリスレッドと一または複数の前記物理キューとを対応付ける対応情報と、
前記アプリスレッドがどの仮想キューに対応しているかを記述する記述情報と、
前記仮想キューに対して前記物理キューを割り当てる論物マッピング情報と、
前記デバイスのＩＰコアごとに、物理キュー、Proc_type、デバイスＩＤが対応付けられる物理キュー情報と、を有し、
前記プロキシ部は、
前記ＩＰコアの減少が指示された場合、前記論物マッピング情報を参照して、スケールインする前記物理キューに対応する前記仮想キューがあるか否かを判別し、対応する前記仮想キューがある場合、前記対応情報、前記記述情報および前記物理キュー情報をもとに、前記仮想キューと接続している前記物理キューの数を動的に減少し、前記物理キューを使用する前記デバイスの前記ＩＰコアを停止させる構成を有する
ことを特徴とするサーバ内データ転送装置。
アクセラレータを含むデバイスをアプリケーションで使用する際、前記デバイスから前記アプリケーションへのデータ転送を行うサーバ内データ転送装置であって、
前記デバイスの物理キューの代わりとなる仮想キューを用いて、前記デバイスと前記アプリケーションに対応するアプリスレッドにデータ処理を行わせることで、前記アプリケーションに対して前記デバイスを接続するデバイス擬似部と、
前記仮想キューと前記物理キューの間を動的に接続変更するプロキシ部と、を備えるとともに、
前記アプリスレッドと一または複数の前記物理キューとを対応付ける対応情報と、
前記アプリスレッドがどの仮想キューに対応しているかを記述する記述情報と、
前記仮想キューに対して前記物理キューを割り当てる論物マッピング情報と、
前記デバイスのＩＰコアごとに、物理キュー、Proc_type、デバイスＩＤが対応付けられる物理キュー情報と、を有し、
前記プロキシ部は、
前記ＩＰコアの増加が指示された場合、前記論物マッピング情報を参照して、スケールアウトする前記物理キューに対応する前記仮想キューがあるか否かを判別し、対応する前記仮想キューがある場合、前記対応情報、前記記述情報および前記物理キュー情報をもとに、前記仮想キューと接続している前記物理キューの数を動的に増加し、前記物理キューを使用するデバイスの前記ＩＰコアを再開させる
ことを特徴とするサーバ内データ転送装置。
アクセラレータを含むデバイスをアプリケーションで使用する際、前記デバイスから前記アプリケーションへのデータ転送を行うサーバ内データ転送装置のサーバ内データ転送方法であって、
前記サーバ内データ転送装置は、
前記デバイスと前記アプリケーションに対応するアプリスレッドとの間の通信を監視しデータ到着タイミングを計るステップと、
データの到着を検知したデータ到着時に前記アプリスレッドを起床させてデータを受信させ、前記データの到着がない間はSleepさせるステップと、
前記デバイスの物理キューの代わりとなる仮想キューを用いて、前記デバイスと前記アプリケーションに対応するアプリスレッドにデータ処理を行わせることで、前記アプリケーションに対して前記デバイスを接続するステップと、
前記仮想キューと前記物理キューの間を動的に接続変更するステップと、を実行する
ことを特徴とするサーバ内データ転送方法
アクセラレータを含むデバイスをアプリケーションで使用する際、前記デバイスから前記アプリケーションへのデータ転送を行うサーバ内データ転送装置としてのコンピュータに、
前記デバイスと前記アプリケーションに対応するアプリスレッドとの間の通信を監視しデータ到着タイミングを計るデータ到着監視手段、
前記データ到着監視手段がデータの到着を検知したデータ到着時に前記アプリスレッドを起床させてデータを受信させ、前記データの到着がない間はSleepさせるポーリング制御手段、
前記デバイスの物理キューの代わりとなる仮想キューを用いて、前記デバイスと前記アプリケーションに対応するアプリスレッドにデータ処理を行わせることで、前記アプリケーションに対して前記デバイスを接続するデバイス擬似手段、
前記仮想キューと前記物理キューの間を動的に接続変更するプロキシ手段、
を実行させるためのプログラム。