JP3716766B2 - パケット処理装置及び順序制御方法 - Google Patents
パケット処理装置及び順序制御方法 Download PDFInfo
- Publication number
- JP3716766B2 JP3716766B2 JP2001267037A JP2001267037A JP3716766B2 JP 3716766 B2 JP3716766 B2 JP 3716766B2 JP 2001267037 A JP2001267037 A JP 2001267037A JP 2001267037 A JP2001267037 A JP 2001267037A JP 3716766 B2 JP3716766 B2 JP 3716766B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- processing
- output
- unit
- packet processing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、パケット処理装置及び順序制御方法に関し、特に、並列処理における簡易な順序制御が可能なパケット処理装置及び順序制御方法に関する。
【０００２】
【従来の技術】
高速ＩＰルータに代表される、多数のＩＰパケット処理を行なう通信装置ではさまざまな特性をもつパケットを効率良く処理することが要求される。たとえば、Ｅｔｈｅｒｎｅｔスイッチのような比較的簡単な処理から、ＩＰスイッチ、さらに上位レイヤプロトコル情報にもとづいてスイッチングを行なう複雑な処理まで多種多様な処理を行なう必要がある。
【０００３】
このような要求に応えるため、複数のマイクロコントローラを備え、それぞれが複数の処理を並列して、あるいは処理ブロック毎にリレーして処理するプロセッサが登場している。このようなプロセッサは、ネットワークプロセッサと呼ばれる。ネットワークプロセッサでは、ＣＰＵによるプログラム処理と同様に命令セットを解釈しながらパケットを処理する。このため、処理能力を向上させるには複数のプロセッサに分散させて処理することが必要になる。
【０００４】
分散処理を行なう場合、各処理部における処理プロトコルの違い、プロセッサの負荷の違い、などからパケットの受信順序を保証できなくなることが予想される。もちろん、ネットワークプロセッサに限らず、複数の処理部に分散処理をさせる際に、その順序が問題となる場合には順序制御が必要になる。
【０００５】
順序制御が必要になる場合の最も確実な実現方法を図７、８に示す。図７におけるパケット処理装置２０では受信部に受信カウンタ１７０によりパケット毎にシーケンス番号を付与し、各処理部での処理後に、出力部において送信カウンタ１７１に基づいて待ち合わせを行なう。この方法では、最後に出力したカウンタ値の次の値を持つパケットが到着するまでは他のパケットは待たなくてはならない。この方法はパケット順序を保持する確実な方法であるものの、次のような問題がある。
【０００６】
【発明が解決しようとする課題】
すなわち、上記の従来技術によるパケット処理装置では、処理部において廃棄すべきであると判断されたパケットや、簡単なプロトコルのため処理が早く終了したパケットに対しては、先行して入力されたパケットよりも早く処理が終了する。この場合、出力部で待ち合わせが発生するため、本来であれば出力されてもかまわない処理済みパケットが処理装置に滞留することとなり、装置が無駄に占有されるとともにパケットの処理時間が見かけ上長くなる。さらに、これらのパケットを早く出力してしまうとカウンタ値が不連続になり、不連続となるカウンタ値の管理も必要になり、処理が複雑になるという問題もある。
【０００７】
本発明は上記問題点を解決して、構成が簡易で、しかもパケットの処理時間を短縮することが可能なパケット処理装置及び順序制御方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するために、本発明のパケット処理装置は、入力される入力パケットを受信し、外部から入力される信号に基づき、複数のパケット出力端子のいずれかに出力する受信部と、前記複数のパケット出力端子の各々に接続され、前記入力パケットに所定の処理を施して処理済みパケットを出力する複数のパケット処理部と、複数の入力端子の各々に前記処理済みパケットが入力され、外部から印加される制御信号に基づき、パケットを出力する出力部と、前記出力部に前記制御信号を供給する順序制御部とを備え、前記順序制御部が、前記パケット処理部のいずれかから出力される前記処理済みパケットを、先行して開始した処理が完了していない他の前記パケット処理部で処理中の入力パケットと出力方路を異にする場合に、前記出力部から出力する旨の前記制御信号を生成する。
【０００９】
また、本発明のパケット処理装置の他の構成では、入力される入力パケットを受信し、外部から入力される信号に基づき、複数のパケット出力端子のいずれかに出力する受信部と、前記複数のパケット出力端子の各々に接続され、前記入力パケットに所定の処理を施して処理済みパケットを出力する複数のパケット処理部と、複数の入力端子の各々に前記処理済みパケットが入力され、外部から印加される制御信号に基づき、パケットを出力する出力部と、前記出力部に前記制御信号を供給する順序制御部とを備え、前記順序制御部は、前記パケット処理部のいずれかから出力される前記処理済みパケットを、他の前記パケット処理部で行っている処理の全てが前記処理済みパケットの処理に遅れて開始された場合に、前記出力部から出力する旨の前記制御信号を生成する。
【００１０】
上記他の構成においては、前記順序制御部は、前記パケット処理部のいずれかから出力される前記処理済みパケットを、他の前記パケット処理部で行っている処理のうち少なくとも１つが前記処理済みパケットの処理に先行して開始された場合には、当該先行処理されているパケットの出力方路が前記処理済みパケットと異なる場合に、前記出力部から出力する旨の前記制御信号を生成してもよい。
【００１１】
あるいは、また、前記パケット処理装置は、さらに、前記処理済みパケットを、前記先行処理を行う前記パケット処理部がある場合に一時退避させる退避キューを備えていてもよい。
【００１２】
本発明のパケット処理装置の、さらに他の構成では、入力される入力パケットを受信し、外部から入力される信号に基づき、複数のパケット出力端子のいずれかに出力する受信部と、前記複数のパケット出力端子の各々に接続され、前記入力パケットに所定の処理を施して処理済みパケットを出力する複数のパケット処理部と、複数の入力端子の各々に前記処理済みパケットが入力され、外部から印加される制御信号に基づき、パケットを出力する出力部と、前記出力部に前記制御信号を供給する順序制御部とを備え、前記順序制御部は、前記パケット処理部の各々に対し、その使用状況、他の全てのパケット処理部の先行処理状況を示す先行マスク、及び前記入力パケットの出力方路を示すストリームＩＤ、を管理する状態テーブルを備えている。
【００１３】
上記構成において、前記順序制御部は、前記パケット処理部のいずれかから出力される前記処理済みパケットを、当該パケット処理部に対応する前記先行マスクが他のパケット処理部が先行処理を行っていないことを示す場合に、前記前記出力部から出力する旨の前記制御信号を生成してもよい。
【００１４】
あるいは、また、前記順序制御部は、第１のパケット処理部の前記先行マスクが先行処理有りを示す場合であって、先行処理を行っている第２のパケット処理部の前記ストリームＩＤが、前記第１のパケット処理部と異なる場合には、前記第１のパケット処理部に対する前記先行マスクを、前記第２のパケット処理部に先行処理が無い旨に書き換えてもよい。
【００１５】
さらに、また、前記順序制御部は、パケット処理部が処理を完了した際に、前記先行マスクで当該パケット処理部が先行処理を行っている旨の表示を全て先行処理無しに書き換えてもよい。
【００１６】
あるいは、前記パケット処理装置は、さらに、前記処理済みパケットを格納するバッファの位置、処理を行った前記パケット処理部の特定及びその前記先行マスク、を一時退避させる退避キューを備えていてもよい。
【００１７】
本発明のパケット処理装置のさらに他の構成によると、入力される入力パケットを受信し、外部から入力される信号に基づき、複数のパケット出力端子のいずれかに出力する受信部と、前記入力パケットに所定の処理を施し処理済みパケットとして出力する縦続接続された複数の処理ブロックと、複数の入力端子の各々に前記処理済みパケットが入力され、外部から印加される制御信号に基づき、パケットを出力する出力部と、前記出力部に前記制御信号を供給する順序制御部とを備え、前記縦続接続された複数の処理ブロックの各々は複数のパケット処理部を備え、縦続接続の初段の前記処理ブロックは、前記複数のパケット出力端子の各々に接続されている。
【００１８】
ここで、前記順序制御部は、最終段の前記処理ブロックに含まれる前記パケット処理部のいずれかから出力される前記処理済みパケットを、前記複数の処理ブロックに含まれる前記パケット処理部であって前記処理済みパケットの処理に関与していないもので行っている処理のうち少なくとも１つが前記処理済みパケットの処理に先行して開始された場合には、当該先行処理されているパケットの出力方路が前記処理済みパケットと異なる場合に、前記出力部から出力する旨の前記制御信号を生成してもよい。
【００１９】
さらに、上記のパケット処理装置は、前記処理済みパケットを、前記先行処理を行う前記パケット処理部がある場合に一時退避させる退避キューを備えていてもよい。
【００２０】
あるいは、前記順序制御部は、前記複数の処理ブロックの初段から最終段に亘って連結された一連の前記パケット処理部に対し、その使用状況、他の全ての一連のパケット処理部の先行処理状況を示す先行マスク、及び前記入力パケットの出力方路を示すストリームＩＤ、を管理する状態テーブルを備えていてもよい。
【００２１】
あるいは、前記順序制御部は、前記一連のパケット処理部のいずれかから出力される前記処理済みパケットを、当該一連のパケット処理部に対応する前記先行マスクが他の一連のパケット処理部が先行処理を行っていないことを示す場合に、前記出力部から出力する旨の前記制御信号を生成してもよい。
【００２２】
あるいは、前記順序制御部は、第１の一連のパケット処理部の前記先行マスクが先行処理有りを示す場合であって、先行処理を行っている第２の一連のパケット処理部の前記ストリームＩＤが、前記第１の一連のパケット処理部と異なる場合には、前記第１の一連のパケット処理部に対する前記先行マスクを、前記第２の一連のパケット処理部に先行処理が無い旨に書き換えてもよい。
【００２３】
あるいは、前記順序制御部は、前記一連のパケット処理部が処理を完了した際に、前記先行マスクで当該一連のパケット処理部が先行処理を行っている旨の表示を全て先行処理無しに書き換えてもよい。
【００２４】
本発明の順序制御方法は、入力するパケットに、所定の複数のパケット処理のいずれかを施した後、順序を出力方路ごとに保存して出力する順序制御方法であって、前記パケット処理のいずれか１つである第１のパケット処理の終了時点で、先行して開始された他のパケット処理の有無を調べる先行処理調査工程と、該先行処理調査工程において、「無」と判明した場合には、前記第１のパケット処理で得られたパケットを対応する出力方路に出力し、「有」と判明した場合には、先行する前記他のパケット処理と前記第１のパケット処理の対象であるパケットの出力方路が異なる場合に前記第１のパケット処理で得られたパケットを対応する出力方路に出力するパケット出力工程とを含んでいる。
【００２５】
ここで、上記の順序制御方法は、さらに、前記複数のパケット処理のいずれかの状況を退避する退避工程を含んでいてもよい。
【００２６】
あるいは、前記複数のパケット処理が、縦続接続された複数のパケット処理群に分割され、前記先行処理調査工程及び前記パケット出力工程を、前記複数のパケット処理群のうち、最終のパケット処理群に対して行うように構成してもよい。
【００２７】
以上述べてきたように、本発明においては、パケット処理を並列して行う構成において、先行して開始されたパケット処理が未だ終了していない場合であっても、出力方路を異にする場合は、出力で衝突する恐れがないため、処理が終了したパケットの出力を許可している。このため、本発明においては、パケットが入力されてから出力されるまでの時間を短縮することが可能となる。
【００２８】
また、本発明においては、同時に１パケットしか処理しないことを前提としているため、パケット単位のカウント値ではなく、パケット処理部単位の先行情報のみによる順序制御が可能であり、構成の簡易化が可能となる。
【００２９】
【発明の実施の形態】
本発明のパケット処理装置及び順序制御方法の構成及びその動作を図１乃至図６を用いて説明する。
【００３０】
（第１の実施例）
図１に本発明によるパケット処理装置の構成を示す。本実施例のパケット処理装置１０は、受信部１００、パケット処理部１１０−１〜１１０−４、出力部１２０、順序制御部１３０から構成される。パケット処理部１１０−ｉは、パケットを処理するために必要な複数の構成要素を備える。本実施例の構成では、パケットヘッダから処理内容を検索する検索部１１１、検索した処理内容に基づいてパケットを加工する加工部１１２をパケット処理部の要素として含んでいる。また、順序制御部１３０は処理要求判定部１３１、状態管理部１３２及び出力判定部１３３を含んでいる。
【００３１】
図２に本実施例の中心となる順序制御部１３０の構成について示す。
順序制御部で管理する信号には以下のものがある。すなわち、複数のパケット処理部のうちいずれの処理部が使用中か否かの状態を保持している使用中フラグ、それぞれのパケット処理部が処理開始時に自身より先行して処理を始めていたことの情報を保持するためのｍａｓｋ信号、それぞれの処理部で処理中のパケットがどのようなストリーム識別子を持つかを示すＳＩＤ（Ｓｔｒｅａｍ ＩＤ）信号、各パケット処理部において処理が完了し、出力したことを示す出力通知信号である。出力判定部１３３は、これらの信号を使って出力判定を行なう。なお、パケット処理部ならびに順序制御部はハードウェアで実現してもよいし、ソフトウェアで記述した処理手順をマイクロプロセッサにより実行する構成としてもよい。
【００３２】
図１、図２を用いてパケット処理装置１０の動作について説明する。パケット処理装置の受信部１００にてパケットを受信すると、受信部１００は処理要求判定部１３１に問い合わせて未使用であるパケット処理部の番号を取得する。使用中／未使用は、状態テーブル１３２のｂｕｓｙフラグを調べることにより判定できる。受信部１００は、指定された番号のパケット処理部（１１０−１乃至１１０−４のいずれか）に対してパケットを入力する。各パケット処理部ではパケットのヘッダ情報並びに回線情報に基づき検索部１１１にて検索を行なう。ヘッダ情報としてはＥｔｈｅｒｎｅｔのＭＡＣアドレス、ＩＰパケットのＩＰアドレス、ｔｃｐ／ｕｄｐのポート番号などがある。また、回線情報としては受信した物理ポート番号、論理ポート番号などがある。なお、受信ポートが複数あることは図１には示していないが、複数の受信ポートからのパケットも受信部１００において到着時間順に扱うものとし、受信ポート数は問わない。検索部１１１における検索の結果、処理内容を取得する。処理内容とは、そのパケットが所属するストリームのＩＤ値ならびにそのストリームのＱｏＳ処理内容、パケットヘッダの付け替え内容、出力ポート番号などを指す。本発明では同一ストリームＩＤに属するパケットの到着順を保持することを特徴とするが、この判断としてストリームＩＤの解決が必要である。ここでストリームの例としては同一端末から同じ宛先ホストへ向かうパケット群があり、ヘッダの組み合わせをキーとして検索を行なうことにより、パケットが属するストリームを特定することが可能になる。
【００３３】
加工部１１２では、検索部１１１で得られた処理内容に基づいてパケットヘッダを加工する。加工内容の例としては、出力パケットへの新規宛先ＭＡＣアドレスへの付け替えやトンネリング処理によるカプセル化タイプの変更などがある。
【００３４】
このようにパケットに対する処理が完了したときに処理結果のパケットを出力する。この際、受信部１００におけるパケット到着順を保持したまま出力することが要求される。ただし、互いに異なるストリームＩＤ間では順序を保持する必要はない。このような要求を満たして出力する方法を順序制御部１３０内部の出力判定部１３３で提供する。本発明の特徴であるところの、この判定方法について説明する。
【００３５】
図２は、出力判定部１３３と状態テーブル１３２を示しており、本発明による出力判定方法に使用する変数の関係を示している。状態テーブル１３２は、パケット処理部毎にエントリーを持つ。このエントリーのフィールドとしては、パケット処理部が使用中か否かを示すｂｕｓｙフラグ、先行してパケット処理を行っているパケット処理部の番号を示す先行マスクフラグ、自身が処理するパケットのストリームＩＤ値、自身が処理したパケットが出力部１２０で退避しているかどうかを示すｗａｉｔフラグ、である。
【００３６】
先行マスクフラグは、それぞれの処理を開始した際にすでに処理中であったパケット処理部の番号を保持しておくためのものである。本実施例では、先行マスクフラグを４ビットで表示する。各ビットが、パケット処理部の各々に対応しており、最上位桁（ＭＳＢ）がパケット処理部１１０−４、最下位桁（ＬＳＢ）がパケット処理部１１０−１の処理中／未処理を表す。各ビットは、“０”が未処理、“１”が処理中を表す。図２の状態テーブル１３２で説明すると、処理部４がパケット処理を開始したときにすでにパケット処理部１１０−１、２、３が処理中（ｂｕｓｙ）であったことを“０１１１”と表現する。同様に表を見ると、パケット処理部１１０−３が処理を開始したときには、すでにパケット処理部１１０−１、２が処理中であったことを表わしている。
【００３７】
このマスクフラグの変化の模様を本実施例に基づいて説明する。前述のように受信部１００が受信パケットをパケット処理部のいずれかに送ると、そのパケット処理部に対応する状態フラグとして先行するパケットを処理中の処理部番号に対応するビットマップを設定する。また、入力時にはまだストリームＩＤが確定していないので、ストリームＩＤ＝不定をテーブルに書きこんでおく。
【００３８】
あるパケット処理部において処理が完了し、処理済みのパケットを出力すると、出力部１２０から順序制御部３００に対し出力通知信号１５１〜１５４により処理の完了が通知される。出力通知信号を受けとった出力判定部１３３は、該当するパケット処理部の状態を表現しているビットをクリアする。このようにして自身より先行してシステム(パケット処理装置)内に入力したパケットの処理が終了するたびにマスクフラグをクリアしていくことで、自分より先に出力すべき、すなわち自身が出力したいときに待ち合わせをしなければならない処理数の変化を表現している。この状態フラグのビットが全てクリアされたときには自身より先行してシステムに入力したパケットが無くなったことを意味するので出力可能になる。
【００３９】
図３のフローチャート（Ａ）に出力通知信号を受信した場合の状態フラグの処理について示す。出力通知信号を受信すると、その出力通知信号がどのパケット処理部から発生したかに基づいて、マスクフラグにおいて対応するビットをクリアする（Ａ１）。ついで、すでに処理が完了していれば（Ａ２）出力判定処理を行ない、完了していなければ引き続き出力通知信号を待つ（Ａ３）。
図３のフローチャート（Ｂ）に出力判定部１３３の判定論理について示す。フローチャートＡに示したように、自身の全ての処理が完了すると出力判定を行なう（Ｂ）。まず、状態を示す先行マスクフラグをチェックする（Ｂ１）。ここで全てのビットが０であれば前述のように先行するパケットがいないことを表すのでパケットを出力する（Ｂ２）。Ｂ１において全てのビットが０で無かった場合には先行する処理を待つ必要がある。ただし順序制御が必要なのは同一ストリームＩＤを持つパケットであるので、ストリームＩＤの比較を行なう。マスクフラグにおいてビットが１である位置の処理部について、それぞれのストリームＩＤと自身のストリームＩＤとの比較を行なう（Ｂ３）。ここでストリームＩＤが異なる場合には順序制御が不要なので、マスクの該当ビットをクリアする（Ｂ４）。なお、比較対象のストリームＩＤとして検索部にて未確定のものがあった場合には、これが同一ストリームＩＤになる可能性があるので、マスクビットはそのままにしておく。こうしてストリームＩＤに基づいてマスクビットのクリアを行なってから再びマスクフラグをチェックする（Ｂ５）。全てのビットが０であればＢ２により出力する。全てのビットが０でない場合は先行する処理部からの出力通知信号を待ち、出力通知信号を受信した時点で再び出力判定処理を行なう。
【００４０】
より具体的に、図４を用いて先行マスクフラグの遷移について説明する。
【００４１】
図４はパケット処理部１１０−１から４においてパケット＃１〜＃８が処理される様子を示している。ここで、パケット処理部１１０−４で＃５のパケットを処理する際のマスクフラグに注目して説明する。時間ｔ１において受信部が処理部を割り当てる際に、すでに処理部１ではパケット＃１が、処理部２ではパケット＃２が、処理部３ではパケット＃４が処理中であるため、処理要求判定部１３１では処理部４を割り当てる。各パケット処理部の空き／処理中は、状態テーブル１３２中のｂｕｓｙフラグに基づいて判定する。ｔ１においては、パケット処理部１００−１、２、３が使用中であったため、ｍａｓｋフラグは０１１１となる。ｔ２において処理部３の＃４の処理が終了し出力されるとパケット処理部１００−３に対応するマスクビットをクリアし、“００１１”となる。ｔ３には処理部1において＃１の処理が終了して出力されると処理部１に対応するマスクビットをクリアし“００１０”と遷移する。
【００４２】
ｔ４ではパケット処理部１１０−４において処理が完了したので、出力判定を行なう。このときのマスクフラグは“００１０”であり、マスクビットの下位２ビット目に１が立っているので、ビット位置に対応するパケット処理部１１０−２がまだ処理中であることがわかる。そこでパケット処理部１１０−２が処理しているパケット＃２のストリームＩＤ（表中ＳＩＤと記述）と自身（＃５）のストリームＩＤを比較する。互いのストリームＩＤが異なればマスクビットをクリアして出力可能であるが、ここではストリームＩＤが一致したとする。すると処理部４は処理部２からのパケット＃２の出力完了を待たなければならない。ｔ４からｔ６までの破線は待ち合わせ状態にあることを示している。ｔ５において処理部２がパケット＃２を出力すると、このときに発生する出力通知信号により処理部４のマスクは“００００”に遷移する。これにより処理部４は出力可能になるので、ｔ５の出力通知信号受信後（ｔ６）にパケット＃５を出力する。
【００４３】
以上のように、先行する処理に関する情報をビット列で保持し、また先行するパケット処理が完了したことにより前述のビット情報をクリアすること、また、ストリームＩＤ比較をビット情報に反映させることによりパケット出力の順序制御を行なう。
【００４４】
（第２の実施例）
図４の例ではパケット処理部１１０−４がパケット＃５を出力する際に待ち合わせが発生し、したがって、パケット処理部１１０−４において休眠時間（ｔ４〜ｔ６時間）が発生する。これに伴い、システムとしてパケット処理部１１０−１〜４を使用して分散処理しているにもかかわらず無駄な時間が発生する。これを解消する方法として第２の実施例について説明する。
【００４５】
図５は第２の実施例について図４に対応して記述したものである。図５ではあらたに「退避キュー５」が追加されている。先に説明したように図４ではｔ４において待ちが発生した。図５ではこのｔ４において待ちキュー５にその処理に必要な情報を退避させる。処理に必要な情報としてはパケットを格納している位置を示すバッファポインタ、退避する前にどのパケット処理部で処理していたかを表す処理部番号、そのパケット処理部におけるマスクフラグなどがある。
【００４６】
退避キュー５におけるビット処理は他のパケット処理部と同様である。退避キュー５におけるマスクフラグを図５においてはｍａｓｋ［５］と示すが、そのビット遷移は図４におけるｍａｓｋと同様である。ｔ６において、ｍａｓｋ［５］が“００００”になると出力可能になる。退避キュー５に退避したパケットを出力する際（ｔ７）には、退避元の処理部番号が４であったことに基づいて、出力通知信号を処理部４からの出力通知信号に重ね合わせるようにする。その信号をうけとるパケット処理部１１０−１〜４ではパケット処理部１１０−４か退避キューかいずれが出力したかに着目する必要はない。
【００４７】
次に図５においてパケット＃７について注目する。パケット＃７は処理部４の処理パケットを待ちキューに退避させた後に、パケット処理部１１０−４を使って処理するパケットである。このときパケット処理部１１０−４の状態情報としてｗａｉｔ ｆｌａｇを付加する（図２の状態テーブル１３２参照）。ｗａｉｔ ｆｌａｇが立っている場合、該当するマスクフラグには自身のパケット処理部をあらわすビット位置に１を立てる。すなわちｔ５において“１０１１”とする。これにより、パケット処理部１１０−４自身の先行処理があることを示す。ｔ６では１００１と遷移し、ｔ７において退避キューからの出力通知信号によって自身のビットをクリアし、“０００１”と遷移する。
【００４８】
一方、パケット処理部１１０−３で処理されるパケット＃８の入力時のフラグは“１０００１０１１”とあらわす。ここで上位４ビットはｗａｉｔ ｆｌａｇが立っているパケット処理部に対応するビットをＯＮにしておく。図においてはｔ６で処理部２からパケットが出力されるため、“１０００１００１”となる。またｔ７で退避キューにいるパケットが出力されるが、このとき上位４ビットに１が立っている場合は上位側のビットのみをクリアする。これによりパケット処理部１１０−４が退避していたパケットが出力されたことを認識する。この状態で“００００１００１”となり、パケット＃７、＃１のそれぞれの出力を待っている状態に遷移する。
【００４９】
このように１つのパケット処理部の処理を表現するためにビットを拡張することで、１パケットの出力を完了することなく、次の処理を開始することが可能である。図５のように１つのパケット処理部あたりに２ビットを使用すれば、退避キューに入れるパケットと合わせて１つのパケット処理部につき２パケットまで連続処理が可能である。なお、退避キューは複数のパケット処理部で共用できるが、その数を増やすことにより、待ち合わせ時間短縮の効果をあげることが可能である。
【００５０】
（第３の実施例）
さらに、本発明の第３の実施例を図６を使用して説明する。図６では複数のパケット処理部１〜４を含む処理ブロック２１０とその後段に複数のパケット処理部５〜７を含む処理ブロック２２０が縦続接続されて構成される。また、順序制御部２３０は処理ブロック２１０、２２０の情報をまとめて管理している。
【００５１】
ここで、パケット処理部３において処理しているパケットがｍａｓｋ［３］＝００１０の状態、すなわちパケット処理部２からの出力通知信号を待たなければならない状態にある場合を考える。このパケットを後段の処理ブロック２２０へ受け渡す場合を考える。このパケットをパケット処理部７にて引き続き処理する場合に、そのマスクフラグをｍａｓｋ［７］＝｛０１１｝｛００１０｝として表す。すなわち｛処理ブロック２２０のマスク｝｛処理ブロック２１０のマスク｝のように結合してマスクフラグを構成し前段処理ブロックの状態を保持する。
【００５２】
ｔ２において先行する処理部５の処理が完了すると、ｍａｓｋ［７］＝｛０１０｝｛００１０｝と遷移する。さらにｔ３において処理部６の処理が完了すると、ｍａｓｋ［７］＝｛０００｝｛００１０｝と遷移する。この時点で処理ブロック２２０内には待つべき処理部はないが、処理ブロック２１０内に先行するパケットが存在するので、これを待つ必要がある。処理ブロック２１０内のパケット処理部２にて処理が完了し出力すると、出力通知信号ならびに処理ブロック２２０内で選択した処理部の番号が通知される。図の場合は処理部５を選択しているのでこれによりｍａｓｋ［７］＝｛００１｝｛００００｝のように処理ブロック２１０のマスクをクリアし、処理ブロック２２０のマスクに情報を伝播させる。処理部７の出口では処理部5が完了するのを待つ必要があるが、ここでは図５と同様に退避する等の処理を行なえばよい。
【００５３】
本実施例においては、複数の処理ブロックのうち、最終段でまとめて順序制御を行っている。各段で順序制御を行わないため、順序制御に要するハードウェアを削減することが可能となる。これとともに、未使用のパケット処理部を減らすことができるため、処理効率の改善も可能となる。
【００５４】
なお、以上の説明においてパケット処理部の数は４あるいは３としていたが、この数はこれらに限定されない。
【００５５】
【発明の効果】
以上説明したように、本発明によるパケット処理装置では、自身より先行する処理に関するビット情報を保持し、また先行するパケットの出力と処理部番号との対応から前述のビット情報を更新すること、ならびにストリームＩＤ比較をビット情報に反映させることによりパケット出力の順序制御を行う。このようにすることで従来必要であった受信番号カウンタと送信番号カウンタによる順序管理が不要となるとともに、入力パケットが出力されるまでの時間を低減することが可能となる。
【図面の簡単な説明】
【図１】 本発明の第１の実施例によるパケット処理装置の構成を表す図である。
【図２】 第１の実施例における出力判定部及び状態テーブルの構成を表す図である。
【図３】 本発明の第１の実施例における処理フローを表す図である。
【図４】 本判明の第１の実施例における処理例を表す図である。
【図５】 本発明の第２の実施例における処理例を表す図である。
【図６】 本発明の第３の実施例によるパケット処理装置の構成を表す図である。
【図７】 従来技術によるパケット処理装置の構成を表す図である。
【図８】 従来技術によるパケット処理装置の処理フローを表す図である。
【符号の説明】
１０、２０：パケット処理装置
１００：受信部
１１０−１〜４：パケット処理部
１１１：検索部
１１２：加工部
１２０：出力部
１３０：順序制御部
１３１：処理要求判定部
１３２：状態テーブル
１３３：出力判定部
１５１〜１５４：出力通知信号
１６１〜１６４：出力許可信号
１７０：受信カウンタ
１７１：出力カウンタ
１７２：出力判定部
２１０、２２０：処理ブロック
【発明の属する技術分野】
本発明は、パケット処理装置及び順序制御方法に関し、特に、並列処理における簡易な順序制御が可能なパケット処理装置及び順序制御方法に関する。
【０００２】
【従来の技術】
高速ＩＰルータに代表される、多数のＩＰパケット処理を行なう通信装置ではさまざまな特性をもつパケットを効率良く処理することが要求される。たとえば、Ｅｔｈｅｒｎｅｔスイッチのような比較的簡単な処理から、ＩＰスイッチ、さらに上位レイヤプロトコル情報にもとづいてスイッチングを行なう複雑な処理まで多種多様な処理を行なう必要がある。
【０００３】
このような要求に応えるため、複数のマイクロコントローラを備え、それぞれが複数の処理を並列して、あるいは処理ブロック毎にリレーして処理するプロセッサが登場している。このようなプロセッサは、ネットワークプロセッサと呼ばれる。ネットワークプロセッサでは、ＣＰＵによるプログラム処理と同様に命令セットを解釈しながらパケットを処理する。このため、処理能力を向上させるには複数のプロセッサに分散させて処理することが必要になる。
【０００４】
分散処理を行なう場合、各処理部における処理プロトコルの違い、プロセッサの負荷の違い、などからパケットの受信順序を保証できなくなることが予想される。もちろん、ネットワークプロセッサに限らず、複数の処理部に分散処理をさせる際に、その順序が問題となる場合には順序制御が必要になる。
【０００５】
順序制御が必要になる場合の最も確実な実現方法を図７、８に示す。図７におけるパケット処理装置２０では受信部に受信カウンタ１７０によりパケット毎にシーケンス番号を付与し、各処理部での処理後に、出力部において送信カウンタ１７１に基づいて待ち合わせを行なう。この方法では、最後に出力したカウンタ値の次の値を持つパケットが到着するまでは他のパケットは待たなくてはならない。この方法はパケット順序を保持する確実な方法であるものの、次のような問題がある。
【０００６】
【発明が解決しようとする課題】
すなわち、上記の従来技術によるパケット処理装置では、処理部において廃棄すべきであると判断されたパケットや、簡単なプロトコルのため処理が早く終了したパケットに対しては、先行して入力されたパケットよりも早く処理が終了する。この場合、出力部で待ち合わせが発生するため、本来であれば出力されてもかまわない処理済みパケットが処理装置に滞留することとなり、装置が無駄に占有されるとともにパケットの処理時間が見かけ上長くなる。さらに、これらのパケットを早く出力してしまうとカウンタ値が不連続になり、不連続となるカウンタ値の管理も必要になり、処理が複雑になるという問題もある。
【０００７】
本発明は上記問題点を解決して、構成が簡易で、しかもパケットの処理時間を短縮することが可能なパケット処理装置及び順序制御方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するために、本発明のパケット処理装置は、入力される入力パケットを受信し、外部から入力される信号に基づき、複数のパケット出力端子のいずれかに出力する受信部と、前記複数のパケット出力端子の各々に接続され、前記入力パケットに所定の処理を施して処理済みパケットを出力する複数のパケット処理部と、複数の入力端子の各々に前記処理済みパケットが入力され、外部から印加される制御信号に基づき、パケットを出力する出力部と、前記出力部に前記制御信号を供給する順序制御部とを備え、前記順序制御部が、前記パケット処理部のいずれかから出力される前記処理済みパケットを、先行して開始した処理が完了していない他の前記パケット処理部で処理中の入力パケットと出力方路を異にする場合に、前記出力部から出力する旨の前記制御信号を生成する。
【０００９】
また、本発明のパケット処理装置の他の構成では、入力される入力パケットを受信し、外部から入力される信号に基づき、複数のパケット出力端子のいずれかに出力する受信部と、前記複数のパケット出力端子の各々に接続され、前記入力パケットに所定の処理を施して処理済みパケットを出力する複数のパケット処理部と、複数の入力端子の各々に前記処理済みパケットが入力され、外部から印加される制御信号に基づき、パケットを出力する出力部と、前記出力部に前記制御信号を供給する順序制御部とを備え、前記順序制御部は、前記パケット処理部のいずれかから出力される前記処理済みパケットを、他の前記パケット処理部で行っている処理の全てが前記処理済みパケットの処理に遅れて開始された場合に、前記出力部から出力する旨の前記制御信号を生成する。
【００１０】
上記他の構成においては、前記順序制御部は、前記パケット処理部のいずれかから出力される前記処理済みパケットを、他の前記パケット処理部で行っている処理のうち少なくとも１つが前記処理済みパケットの処理に先行して開始された場合には、当該先行処理されているパケットの出力方路が前記処理済みパケットと異なる場合に、前記出力部から出力する旨の前記制御信号を生成してもよい。
【００１１】
あるいは、また、前記パケット処理装置は、さらに、前記処理済みパケットを、前記先行処理を行う前記パケット処理部がある場合に一時退避させる退避キューを備えていてもよい。
【００１２】
本発明のパケット処理装置の、さらに他の構成では、入力される入力パケットを受信し、外部から入力される信号に基づき、複数のパケット出力端子のいずれかに出力する受信部と、前記複数のパケット出力端子の各々に接続され、前記入力パケットに所定の処理を施して処理済みパケットを出力する複数のパケット処理部と、複数の入力端子の各々に前記処理済みパケットが入力され、外部から印加される制御信号に基づき、パケットを出力する出力部と、前記出力部に前記制御信号を供給する順序制御部とを備え、前記順序制御部は、前記パケット処理部の各々に対し、その使用状況、他の全てのパケット処理部の先行処理状況を示す先行マスク、及び前記入力パケットの出力方路を示すストリームＩＤ、を管理する状態テーブルを備えている。
【００１３】
上記構成において、前記順序制御部は、前記パケット処理部のいずれかから出力される前記処理済みパケットを、当該パケット処理部に対応する前記先行マスクが他のパケット処理部が先行処理を行っていないことを示す場合に、前記前記出力部から出力する旨の前記制御信号を生成してもよい。
【００１４】
あるいは、また、前記順序制御部は、第１のパケット処理部の前記先行マスクが先行処理有りを示す場合であって、先行処理を行っている第２のパケット処理部の前記ストリームＩＤが、前記第１のパケット処理部と異なる場合には、前記第１のパケット処理部に対する前記先行マスクを、前記第２のパケット処理部に先行処理が無い旨に書き換えてもよい。
【００１５】
さらに、また、前記順序制御部は、パケット処理部が処理を完了した際に、前記先行マスクで当該パケット処理部が先行処理を行っている旨の表示を全て先行処理無しに書き換えてもよい。
【００１６】
あるいは、前記パケット処理装置は、さらに、前記処理済みパケットを格納するバッファの位置、処理を行った前記パケット処理部の特定及びその前記先行マスク、を一時退避させる退避キューを備えていてもよい。
【００１７】
本発明のパケット処理装置のさらに他の構成によると、入力される入力パケットを受信し、外部から入力される信号に基づき、複数のパケット出力端子のいずれかに出力する受信部と、前記入力パケットに所定の処理を施し処理済みパケットとして出力する縦続接続された複数の処理ブロックと、複数の入力端子の各々に前記処理済みパケットが入力され、外部から印加される制御信号に基づき、パケットを出力する出力部と、前記出力部に前記制御信号を供給する順序制御部とを備え、前記縦続接続された複数の処理ブロックの各々は複数のパケット処理部を備え、縦続接続の初段の前記処理ブロックは、前記複数のパケット出力端子の各々に接続されている。
【００１８】
ここで、前記順序制御部は、最終段の前記処理ブロックに含まれる前記パケット処理部のいずれかから出力される前記処理済みパケットを、前記複数の処理ブロックに含まれる前記パケット処理部であって前記処理済みパケットの処理に関与していないもので行っている処理のうち少なくとも１つが前記処理済みパケットの処理に先行して開始された場合には、当該先行処理されているパケットの出力方路が前記処理済みパケットと異なる場合に、前記出力部から出力する旨の前記制御信号を生成してもよい。
【００１９】
さらに、上記のパケット処理装置は、前記処理済みパケットを、前記先行処理を行う前記パケット処理部がある場合に一時退避させる退避キューを備えていてもよい。
【００２０】
あるいは、前記順序制御部は、前記複数の処理ブロックの初段から最終段に亘って連結された一連の前記パケット処理部に対し、その使用状況、他の全ての一連のパケット処理部の先行処理状況を示す先行マスク、及び前記入力パケットの出力方路を示すストリームＩＤ、を管理する状態テーブルを備えていてもよい。
【００２１】
あるいは、前記順序制御部は、前記一連のパケット処理部のいずれかから出力される前記処理済みパケットを、当該一連のパケット処理部に対応する前記先行マスクが他の一連のパケット処理部が先行処理を行っていないことを示す場合に、前記出力部から出力する旨の前記制御信号を生成してもよい。
【００２２】
あるいは、前記順序制御部は、第１の一連のパケット処理部の前記先行マスクが先行処理有りを示す場合であって、先行処理を行っている第２の一連のパケット処理部の前記ストリームＩＤが、前記第１の一連のパケット処理部と異なる場合には、前記第１の一連のパケット処理部に対する前記先行マスクを、前記第２の一連のパケット処理部に先行処理が無い旨に書き換えてもよい。
【００２３】
あるいは、前記順序制御部は、前記一連のパケット処理部が処理を完了した際に、前記先行マスクで当該一連のパケット処理部が先行処理を行っている旨の表示を全て先行処理無しに書き換えてもよい。
【００２４】
本発明の順序制御方法は、入力するパケットに、所定の複数のパケット処理のいずれかを施した後、順序を出力方路ごとに保存して出力する順序制御方法であって、前記パケット処理のいずれか１つである第１のパケット処理の終了時点で、先行して開始された他のパケット処理の有無を調べる先行処理調査工程と、該先行処理調査工程において、「無」と判明した場合には、前記第１のパケット処理で得られたパケットを対応する出力方路に出力し、「有」と判明した場合には、先行する前記他のパケット処理と前記第１のパケット処理の対象であるパケットの出力方路が異なる場合に前記第１のパケット処理で得られたパケットを対応する出力方路に出力するパケット出力工程とを含んでいる。
【００２５】
ここで、上記の順序制御方法は、さらに、前記複数のパケット処理のいずれかの状況を退避する退避工程を含んでいてもよい。
【００２６】
あるいは、前記複数のパケット処理が、縦続接続された複数のパケット処理群に分割され、前記先行処理調査工程及び前記パケット出力工程を、前記複数のパケット処理群のうち、最終のパケット処理群に対して行うように構成してもよい。
【００２７】
以上述べてきたように、本発明においては、パケット処理を並列して行う構成において、先行して開始されたパケット処理が未だ終了していない場合であっても、出力方路を異にする場合は、出力で衝突する恐れがないため、処理が終了したパケットの出力を許可している。このため、本発明においては、パケットが入力されてから出力されるまでの時間を短縮することが可能となる。
【００２８】
また、本発明においては、同時に１パケットしか処理しないことを前提としているため、パケット単位のカウント値ではなく、パケット処理部単位の先行情報のみによる順序制御が可能であり、構成の簡易化が可能となる。
【００２９】
【発明の実施の形態】
本発明のパケット処理装置及び順序制御方法の構成及びその動作を図１乃至図６を用いて説明する。
【００３０】
（第１の実施例）
図１に本発明によるパケット処理装置の構成を示す。本実施例のパケット処理装置１０は、受信部１００、パケット処理部１１０−１〜１１０−４、出力部１２０、順序制御部１３０から構成される。パケット処理部１１０−ｉは、パケットを処理するために必要な複数の構成要素を備える。本実施例の構成では、パケットヘッダから処理内容を検索する検索部１１１、検索した処理内容に基づいてパケットを加工する加工部１１２をパケット処理部の要素として含んでいる。また、順序制御部１３０は処理要求判定部１３１、状態管理部１３２及び出力判定部１３３を含んでいる。
【００３１】
図２に本実施例の中心となる順序制御部１３０の構成について示す。
順序制御部で管理する信号には以下のものがある。すなわち、複数のパケット処理部のうちいずれの処理部が使用中か否かの状態を保持している使用中フラグ、それぞれのパケット処理部が処理開始時に自身より先行して処理を始めていたことの情報を保持するためのｍａｓｋ信号、それぞれの処理部で処理中のパケットがどのようなストリーム識別子を持つかを示すＳＩＤ（Ｓｔｒｅａｍ ＩＤ）信号、各パケット処理部において処理が完了し、出力したことを示す出力通知信号である。出力判定部１３３は、これらの信号を使って出力判定を行なう。なお、パケット処理部ならびに順序制御部はハードウェアで実現してもよいし、ソフトウェアで記述した処理手順をマイクロプロセッサにより実行する構成としてもよい。
【００３２】
図１、図２を用いてパケット処理装置１０の動作について説明する。パケット処理装置の受信部１００にてパケットを受信すると、受信部１００は処理要求判定部１３１に問い合わせて未使用であるパケット処理部の番号を取得する。使用中／未使用は、状態テーブル１３２のｂｕｓｙフラグを調べることにより判定できる。受信部１００は、指定された番号のパケット処理部（１１０−１乃至１１０−４のいずれか）に対してパケットを入力する。各パケット処理部ではパケットのヘッダ情報並びに回線情報に基づき検索部１１１にて検索を行なう。ヘッダ情報としてはＥｔｈｅｒｎｅｔのＭＡＣアドレス、ＩＰパケットのＩＰアドレス、ｔｃｐ／ｕｄｐのポート番号などがある。また、回線情報としては受信した物理ポート番号、論理ポート番号などがある。なお、受信ポートが複数あることは図１には示していないが、複数の受信ポートからのパケットも受信部１００において到着時間順に扱うものとし、受信ポート数は問わない。検索部１１１における検索の結果、処理内容を取得する。処理内容とは、そのパケットが所属するストリームのＩＤ値ならびにそのストリームのＱｏＳ処理内容、パケットヘッダの付け替え内容、出力ポート番号などを指す。本発明では同一ストリームＩＤに属するパケットの到着順を保持することを特徴とするが、この判断としてストリームＩＤの解決が必要である。ここでストリームの例としては同一端末から同じ宛先ホストへ向かうパケット群があり、ヘッダの組み合わせをキーとして検索を行なうことにより、パケットが属するストリームを特定することが可能になる。
【００３３】
加工部１１２では、検索部１１１で得られた処理内容に基づいてパケットヘッダを加工する。加工内容の例としては、出力パケットへの新規宛先ＭＡＣアドレスへの付け替えやトンネリング処理によるカプセル化タイプの変更などがある。
【００３４】
このようにパケットに対する処理が完了したときに処理結果のパケットを出力する。この際、受信部１００におけるパケット到着順を保持したまま出力することが要求される。ただし、互いに異なるストリームＩＤ間では順序を保持する必要はない。このような要求を満たして出力する方法を順序制御部１３０内部の出力判定部１３３で提供する。本発明の特徴であるところの、この判定方法について説明する。
【００３５】
図２は、出力判定部１３３と状態テーブル１３２を示しており、本発明による出力判定方法に使用する変数の関係を示している。状態テーブル１３２は、パケット処理部毎にエントリーを持つ。このエントリーのフィールドとしては、パケット処理部が使用中か否かを示すｂｕｓｙフラグ、先行してパケット処理を行っているパケット処理部の番号を示す先行マスクフラグ、自身が処理するパケットのストリームＩＤ値、自身が処理したパケットが出力部１２０で退避しているかどうかを示すｗａｉｔフラグ、である。
【００３６】
先行マスクフラグは、それぞれの処理を開始した際にすでに処理中であったパケット処理部の番号を保持しておくためのものである。本実施例では、先行マスクフラグを４ビットで表示する。各ビットが、パケット処理部の各々に対応しており、最上位桁（ＭＳＢ）がパケット処理部１１０−４、最下位桁（ＬＳＢ）がパケット処理部１１０−１の処理中／未処理を表す。各ビットは、“０”が未処理、“１”が処理中を表す。図２の状態テーブル１３２で説明すると、処理部４がパケット処理を開始したときにすでにパケット処理部１１０−１、２、３が処理中（ｂｕｓｙ）であったことを“０１１１”と表現する。同様に表を見ると、パケット処理部１１０−３が処理を開始したときには、すでにパケット処理部１１０−１、２が処理中であったことを表わしている。
【００３７】
このマスクフラグの変化の模様を本実施例に基づいて説明する。前述のように受信部１００が受信パケットをパケット処理部のいずれかに送ると、そのパケット処理部に対応する状態フラグとして先行するパケットを処理中の処理部番号に対応するビットマップを設定する。また、入力時にはまだストリームＩＤが確定していないので、ストリームＩＤ＝不定をテーブルに書きこんでおく。
【００３８】
あるパケット処理部において処理が完了し、処理済みのパケットを出力すると、出力部１２０から順序制御部３００に対し出力通知信号１５１〜１５４により処理の完了が通知される。出力通知信号を受けとった出力判定部１３３は、該当するパケット処理部の状態を表現しているビットをクリアする。このようにして自身より先行してシステム(パケット処理装置)内に入力したパケットの処理が終了するたびにマスクフラグをクリアしていくことで、自分より先に出力すべき、すなわち自身が出力したいときに待ち合わせをしなければならない処理数の変化を表現している。この状態フラグのビットが全てクリアされたときには自身より先行してシステムに入力したパケットが無くなったことを意味するので出力可能になる。
【００３９】
図３のフローチャート（Ａ）に出力通知信号を受信した場合の状態フラグの処理について示す。出力通知信号を受信すると、その出力通知信号がどのパケット処理部から発生したかに基づいて、マスクフラグにおいて対応するビットをクリアする（Ａ１）。ついで、すでに処理が完了していれば（Ａ２）出力判定処理を行ない、完了していなければ引き続き出力通知信号を待つ（Ａ３）。
図３のフローチャート（Ｂ）に出力判定部１３３の判定論理について示す。フローチャートＡに示したように、自身の全ての処理が完了すると出力判定を行なう（Ｂ）。まず、状態を示す先行マスクフラグをチェックする（Ｂ１）。ここで全てのビットが０であれば前述のように先行するパケットがいないことを表すのでパケットを出力する（Ｂ２）。Ｂ１において全てのビットが０で無かった場合には先行する処理を待つ必要がある。ただし順序制御が必要なのは同一ストリームＩＤを持つパケットであるので、ストリームＩＤの比較を行なう。マスクフラグにおいてビットが１である位置の処理部について、それぞれのストリームＩＤと自身のストリームＩＤとの比較を行なう（Ｂ３）。ここでストリームＩＤが異なる場合には順序制御が不要なので、マスクの該当ビットをクリアする（Ｂ４）。なお、比較対象のストリームＩＤとして検索部にて未確定のものがあった場合には、これが同一ストリームＩＤになる可能性があるので、マスクビットはそのままにしておく。こうしてストリームＩＤに基づいてマスクビットのクリアを行なってから再びマスクフラグをチェックする（Ｂ５）。全てのビットが０であればＢ２により出力する。全てのビットが０でない場合は先行する処理部からの出力通知信号を待ち、出力通知信号を受信した時点で再び出力判定処理を行なう。
【００４０】
より具体的に、図４を用いて先行マスクフラグの遷移について説明する。
【００４１】
図４はパケット処理部１１０−１から４においてパケット＃１〜＃８が処理される様子を示している。ここで、パケット処理部１１０−４で＃５のパケットを処理する際のマスクフラグに注目して説明する。時間ｔ１において受信部が処理部を割り当てる際に、すでに処理部１ではパケット＃１が、処理部２ではパケット＃２が、処理部３ではパケット＃４が処理中であるため、処理要求判定部１３１では処理部４を割り当てる。各パケット処理部の空き／処理中は、状態テーブル１３２中のｂｕｓｙフラグに基づいて判定する。ｔ１においては、パケット処理部１００−１、２、３が使用中であったため、ｍａｓｋフラグは０１１１となる。ｔ２において処理部３の＃４の処理が終了し出力されるとパケット処理部１００−３に対応するマスクビットをクリアし、“００１１”となる。ｔ３には処理部1において＃１の処理が終了して出力されると処理部１に対応するマスクビットをクリアし“００１０”と遷移する。
【００４２】
ｔ４ではパケット処理部１１０−４において処理が完了したので、出力判定を行なう。このときのマスクフラグは“００１０”であり、マスクビットの下位２ビット目に１が立っているので、ビット位置に対応するパケット処理部１１０−２がまだ処理中であることがわかる。そこでパケット処理部１１０−２が処理しているパケット＃２のストリームＩＤ（表中ＳＩＤと記述）と自身（＃５）のストリームＩＤを比較する。互いのストリームＩＤが異なればマスクビットをクリアして出力可能であるが、ここではストリームＩＤが一致したとする。すると処理部４は処理部２からのパケット＃２の出力完了を待たなければならない。ｔ４からｔ６までの破線は待ち合わせ状態にあることを示している。ｔ５において処理部２がパケット＃２を出力すると、このときに発生する出力通知信号により処理部４のマスクは“００００”に遷移する。これにより処理部４は出力可能になるので、ｔ５の出力通知信号受信後（ｔ６）にパケット＃５を出力する。
【００４３】
以上のように、先行する処理に関する情報をビット列で保持し、また先行するパケット処理が完了したことにより前述のビット情報をクリアすること、また、ストリームＩＤ比較をビット情報に反映させることによりパケット出力の順序制御を行なう。
【００４４】
（第２の実施例）
図４の例ではパケット処理部１１０−４がパケット＃５を出力する際に待ち合わせが発生し、したがって、パケット処理部１１０−４において休眠時間（ｔ４〜ｔ６時間）が発生する。これに伴い、システムとしてパケット処理部１１０−１〜４を使用して分散処理しているにもかかわらず無駄な時間が発生する。これを解消する方法として第２の実施例について説明する。
【００４５】
図５は第２の実施例について図４に対応して記述したものである。図５ではあらたに「退避キュー５」が追加されている。先に説明したように図４ではｔ４において待ちが発生した。図５ではこのｔ４において待ちキュー５にその処理に必要な情報を退避させる。処理に必要な情報としてはパケットを格納している位置を示すバッファポインタ、退避する前にどのパケット処理部で処理していたかを表す処理部番号、そのパケット処理部におけるマスクフラグなどがある。
【００４６】
退避キュー５におけるビット処理は他のパケット処理部と同様である。退避キュー５におけるマスクフラグを図５においてはｍａｓｋ［５］と示すが、そのビット遷移は図４におけるｍａｓｋと同様である。ｔ６において、ｍａｓｋ［５］が“００００”になると出力可能になる。退避キュー５に退避したパケットを出力する際（ｔ７）には、退避元の処理部番号が４であったことに基づいて、出力通知信号を処理部４からの出力通知信号に重ね合わせるようにする。その信号をうけとるパケット処理部１１０−１〜４ではパケット処理部１１０−４か退避キューかいずれが出力したかに着目する必要はない。
【００４７】
次に図５においてパケット＃７について注目する。パケット＃７は処理部４の処理パケットを待ちキューに退避させた後に、パケット処理部１１０−４を使って処理するパケットである。このときパケット処理部１１０−４の状態情報としてｗａｉｔ ｆｌａｇを付加する（図２の状態テーブル１３２参照）。ｗａｉｔ ｆｌａｇが立っている場合、該当するマスクフラグには自身のパケット処理部をあらわすビット位置に１を立てる。すなわちｔ５において“１０１１”とする。これにより、パケット処理部１１０−４自身の先行処理があることを示す。ｔ６では１００１と遷移し、ｔ７において退避キューからの出力通知信号によって自身のビットをクリアし、“０００１”と遷移する。
【００４８】
一方、パケット処理部１１０−３で処理されるパケット＃８の入力時のフラグは“１０００１０１１”とあらわす。ここで上位４ビットはｗａｉｔ ｆｌａｇが立っているパケット処理部に対応するビットをＯＮにしておく。図においてはｔ６で処理部２からパケットが出力されるため、“１０００１００１”となる。またｔ７で退避キューにいるパケットが出力されるが、このとき上位４ビットに１が立っている場合は上位側のビットのみをクリアする。これによりパケット処理部１１０−４が退避していたパケットが出力されたことを認識する。この状態で“００００１００１”となり、パケット＃７、＃１のそれぞれの出力を待っている状態に遷移する。
【００４９】
このように１つのパケット処理部の処理を表現するためにビットを拡張することで、１パケットの出力を完了することなく、次の処理を開始することが可能である。図５のように１つのパケット処理部あたりに２ビットを使用すれば、退避キューに入れるパケットと合わせて１つのパケット処理部につき２パケットまで連続処理が可能である。なお、退避キューは複数のパケット処理部で共用できるが、その数を増やすことにより、待ち合わせ時間短縮の効果をあげることが可能である。
【００５０】
（第３の実施例）
さらに、本発明の第３の実施例を図６を使用して説明する。図６では複数のパケット処理部１〜４を含む処理ブロック２１０とその後段に複数のパケット処理部５〜７を含む処理ブロック２２０が縦続接続されて構成される。また、順序制御部２３０は処理ブロック２１０、２２０の情報をまとめて管理している。
【００５１】
ここで、パケット処理部３において処理しているパケットがｍａｓｋ［３］＝００１０の状態、すなわちパケット処理部２からの出力通知信号を待たなければならない状態にある場合を考える。このパケットを後段の処理ブロック２２０へ受け渡す場合を考える。このパケットをパケット処理部７にて引き続き処理する場合に、そのマスクフラグをｍａｓｋ［７］＝｛０１１｝｛００１０｝として表す。すなわち｛処理ブロック２２０のマスク｝｛処理ブロック２１０のマスク｝のように結合してマスクフラグを構成し前段処理ブロックの状態を保持する。
【００５２】
ｔ２において先行する処理部５の処理が完了すると、ｍａｓｋ［７］＝｛０１０｝｛００１０｝と遷移する。さらにｔ３において処理部６の処理が完了すると、ｍａｓｋ［７］＝｛０００｝｛００１０｝と遷移する。この時点で処理ブロック２２０内には待つべき処理部はないが、処理ブロック２１０内に先行するパケットが存在するので、これを待つ必要がある。処理ブロック２１０内のパケット処理部２にて処理が完了し出力すると、出力通知信号ならびに処理ブロック２２０内で選択した処理部の番号が通知される。図の場合は処理部５を選択しているのでこれによりｍａｓｋ［７］＝｛００１｝｛００００｝のように処理ブロック２１０のマスクをクリアし、処理ブロック２２０のマスクに情報を伝播させる。処理部７の出口では処理部5が完了するのを待つ必要があるが、ここでは図５と同様に退避する等の処理を行なえばよい。
【００５３】
本実施例においては、複数の処理ブロックのうち、最終段でまとめて順序制御を行っている。各段で順序制御を行わないため、順序制御に要するハードウェアを削減することが可能となる。これとともに、未使用のパケット処理部を減らすことができるため、処理効率の改善も可能となる。
【００５４】
なお、以上の説明においてパケット処理部の数は４あるいは３としていたが、この数はこれらに限定されない。
【００５５】
【発明の効果】
以上説明したように、本発明によるパケット処理装置では、自身より先行する処理に関するビット情報を保持し、また先行するパケットの出力と処理部番号との対応から前述のビット情報を更新すること、ならびにストリームＩＤ比較をビット情報に反映させることによりパケット出力の順序制御を行う。このようにすることで従来必要であった受信番号カウンタと送信番号カウンタによる順序管理が不要となるとともに、入力パケットが出力されるまでの時間を低減することが可能となる。
【図面の簡単な説明】
【図１】 本発明の第１の実施例によるパケット処理装置の構成を表す図である。
【図２】 第１の実施例における出力判定部及び状態テーブルの構成を表す図である。
【図３】 本発明の第１の実施例における処理フローを表す図である。
【図４】 本判明の第１の実施例における処理例を表す図である。
【図５】 本発明の第２の実施例における処理例を表す図である。
【図６】 本発明の第３の実施例によるパケット処理装置の構成を表す図である。
【図７】 従来技術によるパケット処理装置の構成を表す図である。
【図８】 従来技術によるパケット処理装置の処理フローを表す図である。
【符号の説明】
１０、２０：パケット処理装置
１００：受信部
１１０−１〜４：パケット処理部
１１１：検索部
１１２：加工部
１２０：出力部
１３０：順序制御部
１３１：処理要求判定部
１３２：状態テーブル
１３３：出力判定部
１５１〜１５４：出力通知信号
１６１〜１６４：出力許可信号
１７０：受信カウンタ
１７１：出力カウンタ
１７２：出力判定部
２１０、２２０：処理ブロック
Claims (15)
- 入力される入力パケットを受信し、外部から入力される信号に基づき、複数のパケット出力端子のいずれかに出力する受信部と、
前記複数のパケット出力端子の各々に接続され、前記入力パケットに所定の処理を施して処理済みパケットを出力する複数のパケット処理部と、
複数の入力端子の各々に前記処理済みパケットが入力され、外部から印加される制御信号に基づき、パケットを出力する出力部と、
前記出力部に前記制御信号を供給する順序制御部とを備え、
前記順序制御部が、前記パケット処理部のいずれかから出力される前記処理済みパケットを、先行して開始した処理が完了していない他の前記パケット処理部で処理中の入力パケットと出力方路を異にする場合に、前記出力部から出力する旨の前記制御信号を生成することを特徴とするパケット処理装置。 - 入力される入力パケットを受信し、外部から入力される信号に基づき、複数のパケット出力端子のいずれかに出力する受信部と、
前記複数のパケット出力端子の各々に接続され、前記入力パケットに所定の処理を施して処理済みパケットを出力する複数のパケット処理部と、
複数の入力端子の各々に前記処理済みパケットが入力され、外部から印加される制御信号に基づき、パケットを出力する出力部と、
前記出力部に前記制御信号を供給する順序制御部とを備え、
前記順序制御部は、前記パケット処理部のいずれかから出力される前記処理済みパケットを、他の前記パケット処理部で行っている処理の全てが前記処理済みパケットの処理に遅れて開始された場合に、前記出力部から出力する旨の前記制御信号を生成することを特徴とするパケット処理装置。 - 請求項２記載のパケット処理装置であって、
前記順序制御部は、前記パケット処理部のいずれかから出力される前記処理済みパケットを、他の前記パケット処理部で行っている処理のうち少なくとも１つが前記処理済みパケットの処理に先行して開始された場合には、当該先行処理されているパケットの出力方路が前記処理済みパケットと異なる場合に、前記出力部から出力する旨の前記制御信号を生成することを特徴とするパケット処理装置。 - 請求項３記載のパケット処理装置であって、
前記パケット処理装置は、さらに、前記処理済みパケットを、前記先行処理を行う前記パケット処理部がある場合に一時退避させる退避キューを備えていることを特徴とするパケット処理装置。 - 入力される入力パケットを受信し、外部から入力される信号に基づき、複数のパケット出力端子のいずれかに出力する受信部と、
前記複数のパケット出力端子の各々に接続され、前記入力パケットに所定の処理を施して処理済みパケットを出力する複数のパケット処理部と、
複数の入力端子の各々に前記処理済みパケットが入力され、外部から印加される制御信号に基づき、パケットを出力する出力部と、
前記出力部に前記制御信号を供給する順序制御部とを備え、
前記順序制御部は、前記パケット処理部の各々に対し、他の全てのパケット処理部の先行処理状況を示す先行マスク及び前記入力パケットの出力方路を示すストリームＩＤを含む状態テーブルを備え、前記パケット処理部のいずれかから出力される前記処理済みパケットを、当該パケット処理部に対応する前記先行マスクが他のパケット処理部が先行処理を行っていないことを示す場合に、前記前記出力部から出力する旨の前記制御信号を生成することを特徴とするパケット処理装置。 - 請求項５記載のパケット処理装置であって、
前記順序制御部は、第１のパケット処理部の前記先行マスクが先行処理有りを示す場合であって、先行処理を行っている第２のパケット処理部の前記ストリームＩＤが、前記第１のパケット処理部と異なる場合には、前記第１のパケット処理部に対する前記先行マスクを、前記第２のパケット処理部に先行処理が無い旨に書き換えることを特徴とするパケット処理装置。 - 請求項５記載のパケット処理装置であって、
前記順序制御部は、パケット処理部が処理を完了した際に、前記先行マスクで当該パケット処理部が先行処理を行っている旨の表示を全て先行処理無しに書き換えることを特徴とするパケット処理装置。 - 請求項５記載のパケット処理装置であって、
前記パケット処理装置は、さらに、前記先行マスクが他のパケット処理部が先行処理を行っていることを示す場合に、前記処理済みパケットを格納するバッファの位置、前記処理を行ったパケット処理部の処理部番号及び該パケット処理部における先行マスクを含む処理情報を退避する退避キューを備え、
前記順序制御部は、前記退避キューにおける先行マスクが全てのパケット処理部で先行処理が行われていないことを示す状態になったときに、当該先行マスクを含む処理情報に対応するパケットを出力する
ことを特徴とするパケット処理装置。 - 入力される入力パケットを受信し、外部から入力される信号に基づき、複数のパケット出力端子のいずれかに出力する受信部と、
前記入力パケットに所定の処理を施し処理済みパケットとして出力する縦続接続された複数の処理ブロックと、
複数の入力端子の各々に前記処理済みパケットが入力され、外部から印加される制御信号に基づき、パケットを出力する出力部と、
前記出力部に前記制御信号を供給する順序制御部とを備え、
前記縦続接続された複数の処理ブロックの各々は、入力パケットに所定の処理を施す複数のパケット処理部を備え、前記入力パケットは前記縦続接続された各段の処理ブロックが有するパケット処理部で所定の処理を施されて処理済パケットとして出力され、
前記順序制御部は、前記従属接続された最終段の処理ブロックに含まれる前記パケット処理部のいずれかから出力される前記処理済みパケットを、先行して開始した処理が完了していない他のパケット処理部で処理中の入力パケットと出力方路を異にする場合に、前記出力部から出力する旨の前記制御信号を生成することを特徴とするパケット処理装置。 - 請求項９記載のパケット処理装置であって、
前記パケット処理装置は、さらに、前記処理済みパケットを、前記先行処理を行う前記パケット処理部がある場合に一時退避させる退避キューを備えていることを特徴とするパケット処理装置。 - 請求項９記載のパケット処理装置であって、
前記順序制御部は、前記縦続接続された最終段の処理ブロックが有するパケット処理部の各々に対し、前記縦続接続された各段の処理ブロックが有する全てのパケット処理部の先行処理状況を前記各段毎に示す先行マスクを含む状態テーブルを備え、
前記縦続接続された最終段の処理ブロックが有するパケット処理部のいずれかから出力される前記処理済みパケットを、当該パケット処理部に対応する前記先行マスクが他のパケット処理部が先行処理を行っていないことを示す場合に、前記出力部から出力する旨の前記制御信号を生成する
ことを特徴とするパケット処理装置。 - 請求項１１記載のパケット処理装置であって、
前記状態テーブルは、前記入力パケットの出力方路を示すストリームＩＤをさらに含み、
前記順序制御部は、前記縦続接続された最終段の処理ブロックが有するパケット処理部のいずれかから出力される前記処理済みパケットを、当該パケット処理部に対応する前記先 行マスクで示される先行処理を行っている他のパケット処理部で処理中の入力パケットと出力方路を異にする場合に、前記出力部から出力する旨の前記制御信号を生成する
ことを特徴とするパケット処理装置。 - 請求項１１記載のパケット処理装置であって、
前記順序制御部は、前記縦続接続された各段の処理ブロックが有するパケット処理部が各段での処理を完了した際に、各段の処理ブロックに対応する前記先行マスクで当該パケット処理部が先行処理を行っている旨の表示を先行処理無しに書き換え、次段の処理ブロックが有するパケット処理部に処理を引継ぐ場合は、当該次段の処理ブロックに対応する前記先行マスクで当該処理を引継いだパケット処理部が先行処理を行っている旨の表示に書き換えることを特徴とするパケット処理装置。 - 入力されるパケットに、所定の複数のパケット処理のいずれかを施した後、順序を出力方路ごとに保存して出力する順序制御方法であって、
前記順序制御方法は、前記パケット処理のいずれか１つである第１のパケット処理の終了時点で、先行して開始された他のパケット処理の有無を調べる先行処理調査工程と、
該先行処理調査工程において、「無」と判明した場合には、前記第１のパケット処理で得られたパケットを対応する出力方路に出力し、「有」と判明した場合には、先行する前記他のパケット処理と前記第１のパケット処理の対象であるパケットの出力方路が異なる場合に前記第１のパケット処理で得られたパケットを対応する出力方路に出力するパケット出力工程とを含んでいることを特徴とする順序制御方法。 - 請求項１４記載の順序制御方法であって、
前記複数のパケット処理は縦続接続された複数段のパケット処理ブロックで行われ、
前記先行処理調査工程及び前記パケット出力工程は、前記複数段のパケット処理ブロックのうち、最終段のパケット処理ブロックに対して行うことを特徴とする順序制御方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001267037A JP3716766B2 (ja) | 2001-09-04 | 2001-09-04 | パケット処理装置及び順序制御方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001267037A JP3716766B2 (ja) | 2001-09-04 | 2001-09-04 | パケット処理装置及び順序制御方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003078557A JP2003078557A (ja) | 2003-03-14 |
| JP3716766B2 true JP3716766B2 (ja) | 2005-11-16 |
Family
ID=19093227
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001267037A Expired - Fee Related JP3716766B2 (ja) | 2001-09-04 | 2001-09-04 | パケット処理装置及び順序制御方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3716766B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7895431B2 (en) * | 2004-09-10 | 2011-02-22 | Cavium Networks, Inc. | Packet queuing, scheduling and ordering |
| JP5128194B2 (ja) * | 2007-07-24 | 2013-01-23 | 株式会社オートネットワーク技術研究所 | 中継接続ユニット |
| JP5359357B2 (ja) * | 2009-02-20 | 2013-12-04 | 日本電気株式会社 | パケット処理装置、該処理装置に用いられるパケット処理順序制御方法及びパケット処理順序制御プログラム |
| JP2023085819A (ja) | 2021-12-09 | 2023-06-21 | 富士通株式会社 | パケット制御装置及びパケット制御方法 |
-
2001
- 2001-09-04 JP JP2001267037A patent/JP3716766B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003078557A (ja) | 2003-03-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN104954251B (zh) | 高性能、可扩展和无掉话的数据中心交换结构 | |
| US6804815B1 (en) | Sequence control mechanism for enabling out of order context processing | |
| JP4260899B2 (ja) | 中継データベースへの中央処理装置のハードウェア支援によるアクセス | |
| US9207979B1 (en) | Explicit barrier scheduling mechanism for pipelining of stream processing algorithms | |
| US7000055B1 (en) | Multi-interface symmetric multiprocessor | |
| US8249072B2 (en) | Scalable interface for connecting multiple computer systems which performs parallel MPI header matching | |
| CN100448221C (zh) | 在计算机服务器中共享以太网适配器的方法和装置 | |
| US20020010793A1 (en) | Method and apparatus for performing frame processing for a network | |
| WO2006039596A1 (en) | Updating instructions executed by a multi-core processor | |
| EP3588915A1 (en) | Coalescing small payloads | |
| JP2004534311A (ja) | 共有属性に基づいて圧縮キューペアから複数の仮想キューペアを作成する構成 | |
| EP0992056A2 (en) | Search engine architecture for a high performance multi-layer switch element | |
| US20020174316A1 (en) | Dynamic resource management and allocation in a distributed processing device | |
| JP2007208963A (ja) | パケット処理装置及びパケット処理方法 | |
| KR100570143B1 (ko) | 상호 통신 프리프로세서 | |
| US9838323B2 (en) | Priority based anycast routing | |
| CN108984327B (zh) | 报文转发方法、多核cpu及网络设备 | |
| JP2018185624A (ja) | スイッチプログラム、スイッチング方法及び情報処理装置 | |
| US9164771B2 (en) | Method for thread reduction in a multi-thread packet processor | |
| US7940785B2 (en) | Ethernet adapter packet management | |
| JP3716766B2 (ja) | パケット処理装置及び順序制御方法 | |
| CN109698845B (zh) | 数据传输的方法、服务器、卸载卡及存储介质 | |
| EP1631906B1 (en) | Maintaining entity order with gate managers | |
| US7782780B1 (en) | System and method for arbitration of multicast data packets using holds | |
| JP2001202345A (ja) | 並列プロセッサ |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050111 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050118 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20050304 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050322 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050809 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050822 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080909 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090909 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090909 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100909 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110909 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120909 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130909 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |