CN104285415B - 混合数据流处理器 - Google Patents

Abstract

一种处理分组流的网络设备具有入口前端。该入口前端确定这些分组是在有界时延路径中还是在尽力而为路径中被处置。这些有界时延路径分组相比这些尽力而为路径分组以更高优先级被许可资源。在这些分组通过多个处理级而被处理时，利用处理引擎，这些有界时延分组在与有保证速率相对应的时间段内被处理。仅当这些处理引擎确定该资源许可将不影响与这些第一分组有关的时延界限时，才向这些尽力而为路径分组许可资源。

Description

混合数据流处理器

相关申请的交叉引用

本公开内容要求来自2012年5月10日提交的临时申请序列号No.61/645,306以及来自2012年9月27日提交的临时申请序列号No.61/706,513的优先权。这些临时申请的公开内容通过引用以它们的整体并入本文。

背景技术

当前的公开内容涉及一种处理分组的网络设备。

本文所提供的背景技术描述是用于一般性地呈现本公开内容的背景的目的。当前被命名为发明人的工作，到它在这个背景技术章节中被描述的程度，以及在提交时以其他方式还不够资格作为现有技术的本描述的方面，既不明确地也不隐含地被承认为相对本公开内容的现有技术。

处理分组的现代网络设备通常包括处理单元或“处理引擎”，这些处理单元或“处理引擎”串行地被布置为以被理解为管道线配置的方式来处理分组。在管道线配置中，分组在各级中被处理以便实现高吞吐率。

发明内容

作为概述，下面所讨论的示例实施例一般性地涉及一种网络设备，该网络设备通过使用两个路径：“硬”路径和“软”路径的多个处理单元来处理分组。遍历硬路径的分组以提供有界时延的方式而被处理。遍历软路径的分组以尽力而为方式而被处理。尽管有前文，但不是每个示例实施例都被要求具有这个段落中所提到的特征中的所有特征或者甚至是任何特征。

根据一个示例实施例，提供有一种用于处理分组的网络设备，该设备具有：入口前端，被配置为将分组流中的第一分组识别为将在多个处理级中的每个级以有保证速率来处理的分组，并且将该分组流中的第二分组识别为将在该多个处理级中的每个级不以有保证速率来处理的分组；多个引擎，被配置为提供用于在处理级处理该分组流中使用的相应资源；该处理级被配置为：(1)对于该第一分组，选择性地促使使用从这些引擎中的一个引擎获得的该资源来对该第一分组执行第一分组处理操作，并且在与该有保证速率相对应的时间段内将该第一分组传递给下一个处理级；以及(2)对于该第二分组，选择性地从这些引擎中的一个引擎请求该资源用于处理该第二分组，将该第二分组缓冲在缓冲器中直到该资源可用，促使使用该可用资源来对该第二分组执行第二分组处理操作，以及将该第二分组以不被保证的速率传递给下一个处理级。

在另一个示例实施例中，这些处理级被布置在管道线中。在另一个示例实施例中，该入口前端、这些引擎、以及该多个处理级被设置在同一集成电路设备上。该分组流包括将以有保证的处理速率来处理的多个分组，并且该一个或多个引擎被配置为，响应于确定向该第二分组许可该资源将不影响将以该有保证速率来处理的分组的该有保证速率，向请求该资源以用于该第二分组的该处理级许可该资源。在一个示例实施例中，该入口前端被配置为，将数据分组作为大多数的将以该有保证速率来处理的分组而提供给该多个处理级。

根据一个示例实施例的该网络设备进一步包括背压总线，其中下游处理级被配置为，通过该背压总线用信号向上游处理级通知，该下游处理级是否可用于接收该第二分组以用于附加处理。在另一个示例实施例中，该下游处理级基于该下游处理级的缓冲器填充程度，用信号向该上游处理级通知是否传递该第二分组。响应于下游处理级的缓冲器达到预定充满阈值，该下游处理级向上游处理级发送信号来停止发送分组。另外，该网络设备具有设置在这些处理级中的软路径缓冲器，这些软路径缓冲器被配置为在可变时间段内缓冲该第二分组，该可变时间段是以下项的函数：从处理级到这些引擎中的一个或多个引擎的对许可访问该资源的请求、以及由一个或多个引擎给请求的该处理级的使得该资源可用于处理该第二分组的许可。

在一个示例实施例中，该多个处理级被布置在管道线中，并且这些软路径缓冲器被配置为向前级提供背压信号，该背压信号指示是否在该管道线中向前发送将不以该有保证速率来处理的另一个分组。在另一个示例实施例中，这些软路径缓冲器被配置为，响应于这些软路径缓冲器中的一个软路径缓冲器超出充满阈值而声明该背压信号，并且该入口前端被配置为，接收该背压信号并且不发送将不以有保证速率来处理的另一个分组，直到该背压信号被解除声明。

在又另一个示例实施例中，该多个处理级被布置为提供：软路径，其不以有保证速率来处理分组；以及硬路径，其以有保证速率来处理分组而不论施加在这些引擎该软路径上的处理负载。

在一个示例实施例中，提供有一种方法，包括：将分组流中的第一分组识别为将在多个处理级中的每个级以有保证速率来处理的分组；将分组流中的第二分组识别为将在该多个处理级中的每个级不以有保证速率来处理的分组；在处理级从引擎请求资源，使得能够在有界时间段内对该第一分组执行操作，该有界时间段由与该有保证速率相对应的预定时延来限定；使用该资源对该第一分组执行处理操作，并且在由该有保证速率所限定的时间段内将该第一分组传递给下一级；请求用以从该引擎请求该资源的准许，使得能够对该第二分组执行操作；响应于资源请求，做出与使用该资源是否将影响该第一分组的该有保证速率有关的确定，并且根据该确定来提供资源许可；以及响应于该资源许可，从该引擎请求该资源。

在一个示例实施例中，该方法还包括：缓冲该资源请求，直到该确定指示该第一分组的该有保证速率将不被影响。

在又一个示例实施例中，提供了一种网络设备，用于以基本上有保证速率来处理第一分组的流，并且用于以可变速率来同时处理第二分组的流。该设备还包括：一个或多个引擎，供应处理资源用于在处理该第一分组中使用并且用于在处理该第二分组中使用；以及处理级，耦合至该一个或多个引擎，该处理级被配置为：在由该有保证速率所限定的时段内，使用从该一个或多个引擎获得的该资源来处理该第一分组，以及针对用于处理这些第二分组之中的第二分组的该资源而做出资源请求，缓冲该第二分组，直到这些引擎中的一个或多个引擎指示用于处理该第二分组而不导致用于处理这些第一分组的该时段超出该有保证速率的该资源的可用性。

在一个示例实施例中，提供有一种管道线处理器，该管道线处理器包括多个处理级，该多个处理级包括该处理级，该多个处理级每个都被配置为对这些第一分组和这些第二分组执行一个或多个处理操作。该设备基于该引擎是否能够许可该资源而不影响这些第一分组的该有保证速率，来确定何时许可该资源。当存在包括该引擎的多个引擎时，这些引擎中的每个引擎具有资源并且耦合至该处理级，该处理级被配置为生成与该多个引擎中的多于一个引擎有关的资源请求。在一个示例实施例中，该处理级向该多个引擎中的每个引擎提供该资源请求。

在附加的示例实施例中，网络设备还包括：分组分类器，设置在该处理级和该引擎的上游，被配置为将分组流中的分组分类为这些第一分组之一或者这些第二分组之一。

附图说明

图1是提供用于根据示例实施例的操作的概念的高级别概览的高度简化的说明性示图；

图2图示了根据示例实施例的硬实时系统；

图3图示了根据示例实施例的软实时系统；

图4图示了根据示例实施例的混合系统，该混合系统具有图2的硬实时系统和图3的软实时系统；以及

图5图示了根据示例实施例的示例方法的流程图。

具体实施方式

在以下的讨论中，为了增加的清楚性和简洁性，对公知功能和构造的描述可能被省略。

概念性概述

图1示出了网络设备300。网络分组的流1被引入。一些分组1H将经由硬路径而被处理，并且一些分组1S将经由软路径而被处理。该设备中的组件2促使硬路径分组1H经由硬路径3而被处理，并且促使软路径分组1S经由软路径4而被处理。将理解，在图1中以及在其他图中的两个物理路径的图示被提供用于解释的目的，并且将不被理解为限制示例实施例。

硬路径分组1H通过经过处理级5而传递来遍历硬路径3。在图1中，仅示出了两个级，5-1和5-2。这些处理级由处理单元来实施并且涉及对各种资源(未示出)的使用，其将在下面更详细地被描述。尽管示例实施例不要求对分组的改变以作为每个处理级的结果而出现，但是图1通过处理级S1(即，5-1)之前的标签H到之后的标签H’上的改变而图示了分组中的改变。同样地，图1以标签H”示出了已经通过处理级S2的硬路径分组。在最后的处理级S2之后，这些网络分组如此地被处理而出口。

遍历硬路径3的硬路径分组1H由处理级5的处理单元(未示出)以提供有界时延的方式来处理。此处，术语“有界时延”可以被理解为具有与“没有延迟”相类似或者与“以有保证的吞吐率”相类似的内涵。

软路径分组1S遍历软路径4。仅为了解释的目的，软路径4被图示为等待被处理的、软路径分组的形象的等待线条。软路径分组1S在该线条的末端进入软路径，并且最终被处理。

实施软路径的一些具体示例实施例在下面被描述，但是总体概念是软路径分组1S以尽力而为的方式被处理。如图1中所示出的，软路径分组1S从由标签S所图示的预处理状态前进到由标签S’所图示的后处理状态。虽然从S到S’的改变由位于等待线条与虚线软路径分组1S之间的带有实线箭头的实线简单地描绘，但是将理解，执行该处理的资源是执行处理级5中的硬路径分组1H的处理的相同资源。

也就是说，处理级5涉及意图为以有界时延(即，没有延迟)来处理硬路径分组1H的资源，但是思想是，只要对硬路径分组1H的处置没有不利地被影响，这些相同的资源就将被用来处理软路径分组1S。

为了这个目的，根据示例实施例，设备300被示出并且软路径4向处理级5发出请求(图1中的“Req”)。这些请求背后的概念是，它们将在处理级5的自由裁量下被处置。在下面，各种其他方法也被讨论，但是思想是处理级5的处理单元处于最佳位置，以确定它们各自的处理工作负荷是否准许代表软路径分组1S来请求对该处理的处置。

一旦对给定的软路径分组的处理被执行，经处理的分组S’可以以适合于情形的任何方式而出口或者被处理。

更深地查看针对硬路径分组的有界时延和针对软路径分组的尽力而为处理的含意，导致了在讨论继续时要记住的一些要点。首先，延迟在硬路径中不能被容忍，并且因此很有可能的是，时不时地，硬路径中的少许分组将被丢弃而结束，使得绝大多数的分组能够在所准许的时延的界限内遍历硬路径。另一方面，因为关于软路径分组何时将被处理没有特定的时间方面的预期，所以软路径分组将需要被丢弃将是相对罕见的。冒着过于概括的风险，可以说(一般而言)硬路径提供有保证的定时但不提供有保证的递送，而软路径提供有保证的递送但不提供有保证的定时。

将这个一般性的框架记在心上，下面的讨论将进而聚焦于：(1)本文件的剩余部分中所使用的术语，(2)仅有硬路径实施方式的网络设备(即，仅具有硬路径的网络设备)，(3)仅有软路径实施方式的网络设备，以及(4)具有硬路径和软路径两者的“混合”网络设备。本讨论还将从概念的转移到具体的，从而提出多个教导性的示例实施例。

术语

本讨论的这个章节阐述了将被用来解释下面的示例实施例的技术术语。

本公开内容的特定实施例涉及一种具有网络处理器和/或分组处理器的网络设备，这些网络处理器和/或分组处理器包括被配置为处理网络分组的流的多个可编程处理单元。可能有利地被采用的这种处理单元的一个示例是从MARVELL TECHNOLOGY GROUP，LTD可得到的PACKET INSTRUCTION SET COMPUTER(PISC)处理器。

在一种示例实施例中，这些处理单元被布置为管道线，该管道线具有串行布置的可编程处理级，这些可编程处理级被配置为对分组流中的分组执行特定于分组的处理操作。一个或多个引擎访问点(EAP)被包括在这些可编程处理单元之间的管道线中，并且被配置为从该处理管道线外部的一个或多个引擎(诸如查找表、加速器等)获得专门的资源。

该管道线经由串行布置的EAP而与一个或多个引擎交互。例如，EAP能够被用来代表分组向引擎发送请求，并且接收对应的响应，该对应的响应能够被集成至该分组中。代表分组所发送的该请求被用于各种分组处理操作，诸如访问查找表和数据库，使用在该管道线之外的该引擎的共享资源和加速器来执行这些分组处理操作。

在一种示例实施例中，分组流包括硬路径分组和软路径分组两者。很好地适合于在硬路径中处置的分组类型的一个示例是数据分组。数据分组通常将是最常见并且最时间敏感的网络分组类型，并且数据的快速移动在任何网络中都是值得的目标。

合情理地在软路径中被处置的分组类型的一个示例是控制消息(CM)分组。在一种示例实施例中，CM分组通常不需要以有保证速率和有界时延来处理，并且因此很好地适合于在尽力而为的基础上被处置，以便于不扰乱硬路径分组的有保证速率和有界时延。

相比于数据分组，例如因为一些CM分组执行更加耗时的表格管理操作，CM分组通常较不频繁地请求对引擎的访问。因此，为了最大化吞吐量，数据分组被允许尽可能多地使用引擎的容量。另外，在一些实施例中，因为CM分组相对于数据分组是比较罕见的，所以预留引擎容量不是仅被分配来服务这些分组。

容易理解为何数据分组一般很好地适合于经由硬路径来处置，并且容易理解为何CM分组一般很好地适合于经由软路径来处置。因此，下面的讨论将经常使用术语“数据分组”替代术语“硬路径分组”，并且使用术语“CM分组”替代术语“软路径分组”。然而，将理解，这些术语仅被用来简化读者的理解。可能存在有其中CM分组应当经由硬路径而被处置的情形，并且可能存在有其中数据分组应当经由软路径而被处置的情形。此外，存在众多本文没有具体讨论的其他分组类型，并且存在众多可能在未来被开发的分组类型。

因此，下面按照术语“数据分组”和“CM分组”所讨论的示例实施例不应当在限制性的意义上而是仅在教导性的意义上被解释。

硬实时系统

硬实时系统具有一个或多个硬路径，每个硬路径具有固定的最大时延和有保证的性能。这意味着，流经硬实时系统的分组将在某个时间量内被处理，该时间量在系统设计和/或生产期间的某个阶段被确定。因此，硬路径中的每个硬路径具有来自引擎的资源之中的固定资源分配，以便于以有保证速率和有界时延来提供有保证的性能。

图2图示了根据本公开内容的示例实施例的硬实时系统100。硬实时系统100包括设置在网络处理器单元或分组处理器单元中的管道线处理器10，在一些实施例中，网络处理器单元或分组处理器单元是网络设备(诸如交换机)的一部分。如图2中所看到的，分组处理器10处于与管道仲裁器20和引擎30-1至30-n的通信中，引擎30-1至30-n进而通过总线的方式而耦合至分组处理器10。管道线处理器10通过位于管道线处理器10的各个级处的引擎访问点(EAP)34-1...34-n而与引擎30交互。如果EAP 34-1...34-n没有相互区分，则它们简单地被称为“EAP 34”，此外EAP 34的数量可以不同于引擎30的数量。管道线10包括一个或多个相关联的处理器核心14-1...14-n，如果没有相互区分则它们简单地被称为“处理器核心14”。在一种实施例中，这些处理核心是可编程核心，诸如PISC处理单元，这些可编程核心被配置为对流经该管道线的分组执行基于可编程上下文的处理操作。EAP 34是用于分类任务的专门I/O单元，并且每个都能够从引擎30请求资源以处理分组并且接收对应的响应，能够使用相关联的处理器核心14-1...14-n来将该对应的响应集成在该分组中。在一些实施例中，EAP 34还由它自己来更新分组上下文而无需对处理器核心14的使用。

更具体地，EAP 34将对存储在引擎30的嵌入式或外部存储器(TCAM、SRAM、DRAM等)中的资源(例如，查找表、控制表、转发表、专用加速器等)的访问统一，并且接收由相关联的处理核心14-1...14-n在分组流经管道线10时用来处理分组的上下文/代码。

在这个讨论中，如果引擎30-1至30-n没有相互区分，则它们简单地在一般意义上被称为“引擎30”。管道仲裁器20从流量管理器40接收分组，这些分组大多数是数据分组并且还包括一些CM分组，诸如非可执行的控制消息(nXCM)，流量管理器40将这些分组存储在缓冲器44中。如本文所使用的，术语流量管理器40是一种排队系统，该排队系统能够像通向高级外部缓冲系统的先入先出(FIFO)缓冲器一样简单，该高级外部缓冲系统包括队列、调度层次、以及如下的缓冲器，该缓冲器具有比管道仲裁器20和管道线10中的那些的容量更大的容量。流量管理器40在本文中还可以被称为出口前端。

在一种实施例中，管道仲裁器20在分组从流量管理器被接收时将它们存储在缓冲器26中、速率整形(即，封包速率整形)并且调度这些分组以用于使用分组整形器24来处理、并且将这些分组馈送给管道线处理器10，在管道线处理器10处它们被处理。更具体地，在一种实施例中，在被用来驱动各个可编程处理核心的代码被汇编为可执行计算机指令的这样的时刻，速率整形器24通过总计各引擎的最坏情况预订并且确保引擎的最坏情况预订小于其实际容量，来检查引擎30的最大利用率。这些经速率整形和调度的分组然后以有保证速率和有界时延而遍历通过管道线处理器10。这些经速率整形和调度的分组在硬实时系统中能够被丢弃，以便提供有保证速率和有界时延。更具体地，在当硬路径具有有保证的资源时的正常情况中，流经硬路径的分组的递送、吞吐率和有界时延将被保证。然而，如果资源中的任何资源被超额分配用于硬路径，则硬路径分组可以被丢弃以便于实现对于大多数分组的保证。相对照地，如果资源被超额分配用于软路径，则分组将不被丢弃。替代地，它们被缓冲并且等待资源变为可用。

在一些示例实施例中，管道线处理器10由一个或多个分组指令集计算机(PISC)处理器单元所形成，PISC处理器单元中的每个PISC处理器单元都接收至少经部分处理的分组、处理上下文、以及适合的代码，以执行接下来的处理操作。在一种实施例中，PISC处理器是被具体设计用于分组处理的处理器核心，但是本公开内容不必然被限制于此并且管道线10在一种实施例中被实施为一个或多个通用CPU或处理器核心。在硬实时系统100中，分组不能被重新排序，因为它们就像前进通过具有有保证速率和有界时延的固定长度的先入先出(FIFO)设备那样行进通过管道线处理器10，直到它们到达信宿50，在各种实施例中，信宿50是另一个管道线处理器、PISC、EAP等适当设备。例如，在一种实施例中，在每个时钟周期中，管道线处理器10的硬路径中的所有分组向前移动一个级，到下一个处理器核心14或EAP34，在该下一个处理器核心14或EAP 34处，后续的处理操作被执行。在这个示例中，在处理器核心14处所执行的指令总是被执行以在单个时钟周期内完成，并且每个指令能够并行地执行多至某个数量的(例如，四个)操作。分组然后继续至信宿50。

然而，如上面所提到的，在一种实施例中，硬实时系统100中存在多个硬路径。这些多个硬路径并行地处理分组，并且对于与一个硬路径相关联的分组，有可能传递与硬实时系统100内的另一个硬路径相关联的分组。

因此，如上面所描述的，硬实时系统100以对应于例如导线速度(wirespeed)的有保证速率来处理分组、保证分组顺序、具有有限量的缓冲器、并且假定最坏情况时延。注意到，在一种实施例中，仅头部或者表示分组的其他描述符数据结构传递通过管道线处理器10。此外，平均地说，在具有基于例如它们各自的大小或长度的不同处理要求的分组的典型混合中。通过示例的方式，具有60字节的大小的分组具有比具有1500字节的大小的分组更高的分组速率。这些分组可能具有相同的处理要求，例如程序，但是这些分组的频率是不同的。例如，如果有许多长分组，则该处理大多是空闲的。在各种实施例中，因为对于一些分组需要维持导线速度处理，所以由引擎30所提供的资源的相当大部分可能在任何给定时刻都不被使用。作为结果，未使用的资源可用于处理相对罕见的CM分组，以及非时限性的其他类似分组。

软实时系统

在一种实施例中，软实时系统具有一个或多个软路径，每个软路径都具有非保证的速率和非有界的时延、以及不被保证的概况描绘(profiling)。这意味着，流经软实时系统的分组将在某个时间被处理，但是因为不存在有保证速率并且不存在有界时延，所以分组将被处理的时间是不确定的。也就是说，使用可用资源在尽力而为的基础上处理流经软实时系统的分组，而不负面地影响例如硬路径中的处理。

图3图示了根据本公开内容的示例实施例的软实时系统200。软实时系统200包括上面所描述的管道线处理器10、管道仲裁器20、引擎30、流量管理器40、以及信宿50，因此对它们的多余描述被省略。

一般而言，分组被存储在流量管理器的先入先出(FIFO)缓冲器上，直到它们由流量管理器40输入至管道线，并且从处理器到处理器地被传递。此外，当分组到达EAP 34，并且需要来自引擎30的资源时，一种通用过程随即发生。也就是说，EAP 34请求该资源并且继续缓冲该分组，直到引擎用信号通知可用性。一旦引擎用信号通知可用性，EAP 34然后能够从引擎30获得该资源。

因为软实时系统200不具有有保证速率和有界时延，并且软实时系统中的分组将不被丢弃，所以可能存在如下的场合，在该场合中，EAP 34的软路径缓冲器18-1...18-n变为充满。因此，虽然硬实时系统能够丢弃分组以便提供有保证速率和有界时延，但是软实时系统没有被设计为丢弃分组并且将缓冲分组直到它能够被处理。软路径缓冲器18-1...18-n在不被个别指代时简单地被称为“软路径缓冲器18”。

归因于软路径缓冲器18变为充满的可能性，在一些示例实施例中，EAP 34向在前的EAP 34并且向管道仲裁器20提供背压反馈(由虚线箭头指示)。此外，因为来自管道线处理器10的背压信号促使管道仲裁器20停止向软路径发送分组，所以管道仲裁器20的缓冲器28也可能变得充满。因此，管道仲裁器20也能够向流量管理器40提供背压信号，告知流量管理器40停止向软路径发送分组。在流量管理器40不向软路径发送分组的时间期间，分组累积在流量管理器40的深软路径缓冲器46中。

在一些示例实施例中，背压信号经由分离的背压总线(未示出)而被提供在软实时系统200中。

在一些示例实施例中，使用基于信用点(credit)的系统而不使用背压的其他流控制方案被使用。这些基于信用点的系统稍后被描述。

在软实时系统200中，不像上面所描述的硬实时系统100和传统的软路径，管道仲裁器20不试图预测何时将存在允许CM分组被捎带并且与数据分组一起在带内行进的间隙。也就是说，因为不存在有保证速率和有界时延，所以管道仲裁器20不对分组速率整形，而是响应于接收到指示管道线可用于处理接下来的分组的信号而将它们发送给管道线10用于处理。

尽管管道仲裁器20不需要为了它自己的目的而速率整形和调度分组，但是有可能当一些其他考虑要求它时添加速率整形和/或调度。然而，为了支持多个硬路径和多个软路径，管道仲裁器20应当调度分组。如果存在背压信号被解除声明(de-asserted)或者硬路径中的任何硬路径中没有分组，则分组能够被调度到软路径中。当存在多个软路径时，管道仲裁器40通过例如轮询调度方案来为不同的软路径调度分组。

当没有被背压信号禁止时，管道仲裁器40将分组馈送给管道处理器10。进一步地，因为软路径不具有硬路径的固定的资源分配，所以软路径在引擎的资源变为可用时使用它们。

然而，在仅有软路径被使用的情况中，不可能给出除了统计性能之外的任何速率/时延保证。

混合设备

因此，根据一种示例实施例，实现有一种混合系统，该混合系统包括组合在相同资源上的上面所提到的硬实时系统100和上面所提到的软实时系统200两者。该混合系统给出了两个系统的最佳并且通过遍历硬路径而允许需要保证的程序(例如，经承诺的分组程序(CPP)的程序)得以实现，同时还在引擎30的资源变得经由软路径可用时允许不需要保证的程序(例如，过度分组程序(EPP)的程序)来访问引擎30的资源。作为结果，硬路径能够减少归因于偶尔高成本的CM分组的额外时延/缓冲，并且软路径具有用于CM分组的简单得多的调控机制。

混合系统

图4图示了示例混合系统300。混合系统300的引擎30具有用于硬实时系统100并且用于软实时系统200的分离的(逻辑)缓冲系统(队列)。例如，引擎30-1包括本地硬时间缓冲器32-1H和本地软时间缓冲器32-1S，并且引擎30中的每个引擎都包括各自的本地硬时间缓冲器和各自的本地软时间缓冲器。

在该混合系统中，硬实时系统100相对于软实时系统200具有优先性。这是因为硬实时系统100具有有保证速率和有界时延，而软实时系统200不具有有保证速率和有界时延。

用于路径选择的机制

流量管理器40将不需要有保证速率和有界时延的分组定向至管道仲裁器20中的软路径缓冲器28。这些分组主要是CM分组，然而，本公开内容不限制于此，并且软路径缓冲器28在一种示例实施例中也接收数据分组。类似地，流量管理器40将需要保证的分组定向至管道仲裁器20中的硬路径缓冲器26。这些分组主要是数据分组，然而，本公开内容不限制于此，并且硬路径缓冲器26在一种示例实施例中也接收CM分组。

在一种示例实施例中，流量管理器40是具有被映射至出口端口的多个队列的高级缓冲器系统。在被映射至出口端口的队列中所存储的所有分组都将在相同的软路径或相同的硬路径中被处理。也就是说，在流量管理器40的出口端口与软路径和硬路径的输入之间存在映射。在一些实施例中，流量管理器40从经由入口端口接收分组，将这些分组存储在它的缓冲器系统中，并且将这些分组传输给管道仲裁器30。流量管理器40不需要做任何处理选择，因为处理选择已经由从一个入口端口到队列的静态映射完成，或者已经由预分类器通过关于分组的查找表(在例如TCAM中)在流量管理器40中选择一个队列而完成。

流量管理器40仅选择(调度)在它的缓冲器系统/队列中的哪些分组要发送给出口端口，而不考虑由这些分组所要求的处理类型。

在另一个示例实施例中，流量管理器40包括用于硬路径和软路径中的每个路径的先入先出(FIFO)缓冲器。

在一种示例实施例中，流量管理器40使用各种技术将分组定向至相应的硬路径和软路径，这些技术诸如静态选择、依据服务类的动态选择、以及依据流量频率的动态选择，下面描述它们中的每一个。

在静态选择技术中，根据一种示例实施例，一经分组到达流量管理器40，就确定该分组是需要发送给硬路径还是发送给软路径。具体地说，用于硬路径的候选包括需要有保证的导线速度性能的那些分组，或者需要在规定时间内被执行的分组。这些候选的示例包括数据流量、普通OAM ping程序、以及一些管理分组，这些管理分组用于执行诸如表格擦除(table scrub)的程序或者用于检测超时的程序。

用于软路径的候选包括简单地需要“尽力而为”性能的那些分组。这些候选的示例包括管理分组，诸如更新表格条目的分组或者读取计数器的分组。

在依据服务类的动态选择中，根据一种示例实施例，存在一种使用管道线处理器10的分类。在通过管道线处理器10的分组的第一传递中，数据流量被用于该分组的分类，例如，硬路径用于导线速度。该分组通过另一个管道线处理器50而被传递或者通过相同的管道线处理器10而被循环，并且取决于该早先的分类而进入硬路径或软路径。此外，如管道线的一组TCAM或SIP(例如，硬编码的交换机)能够执行该分类。

第二传递中用于硬路径的候选包括具有速率敏感和时延敏感的服务类的分组。示例包括系统控制分组、VOIP、游戏、会议等。第二传递中用于软路径的候选包括既不速率敏感也不时延敏感的服务类的分组。示例包括VoD、数据流量、清扫器类分组等。

在依据流量频率的动态选择中，根据一种示例实施例，存在与上面关于依据服务类技术所描述的分类相类似的分类。第二传递中用于硬路径的候选包括大块流量，例如，层2(L2)以太网流量。第二传递中用于软路径的候选包括应当被管理但是人们可能不想以优化的资源来提供的相对罕见的流量类型，例如，层3(L3)以太网流量。

用于请求资源的机制

在硬路径中，当分组到达EAP的缓冲器16时，这些EAP简单地代表这些分组来请求资源。这些请求被存储在引擎的硬路径缓冲器32-H中，并且它们按照它们由引擎30接收的顺序而被执行。

相对照地，当不存在背压信号时，例如，当背压信号被解除声明时，软路径缓冲器28将存储在其上的分组推送给管道线处理器10。一经到达管道线处理器10，这些分组就被存储在EAP 34的软路径缓冲器18中。响应于接收到软路径缓冲器18中的分组，EAP 34向引擎30中的一个或多个引擎发送“许可请求(request to grant)”。响应于接收到该许可请求，引擎30确定它们是否具有可以被使用而不扰乱硬路径中的分组流的可用资源。响应于确定存在可以被利用而不扰乱硬路径中的分组流的可用资源，引擎30向EAP 34发送“许可”。响应于从该引擎30接收到该许可，EAP 34然后从发送该许可的引擎请求资源，并且该请求被存储在该引擎的软路径缓冲器32-S中并且按照它由引擎30所接收的顺序而被执行。该“许可请求”可以被认为是资源请求，并且“许可”可以被认为是资源许可。

引擎30通过例如缓冲器填充程度、信号量、未完成的信用点(outstandingcredits)、其他本地资源等中的至少一项而基于其当前的拥塞状况来确定它们是否具有可用资源，并且能够因此关于它们是否具有可用资源而快速地做出正确决定。因此，不需要尝试从管道仲裁器20来预测引擎拥塞。作为结果，来自所有EAP 34的未使用带宽能够可用于软路径。

从软路径接收的许可请求在引擎处被入队在分离的(多个)队列中。如上面所描述的，这些引擎每个都包括硬路径缓冲器32-H和软路径缓冲器32-S。换句话说，在一种实施例中，软路径具有与硬路径的队列结构相平行的队列结构。这使得用以消耗引擎30的资源的请求能够对于软路径而保持待决，而不扰乱硬路径中的分组流。

因为引擎30将它们的资源分发给EAP 34，所以它们每个都充当用于EAP 34的代理(broker)。引擎30能够以若干不同的方式来调控它们资源的分发。

在一个示例实施例中，引擎30通过经由分离的背压总线(未示出)向EAP 34中的每个EAP提供背压信号，来调控它们资源的分发。因此，在这个实施例中，引擎30需要每EAP一个队列或者对队头(head-of-line)阻塞的接受。因此，对于这些队列，存在由于不可停止的数据而变得庞大的潜在性，并且速率取决于往返。也就是说，引擎30实现了更高的缓冲器填充，例如，从而多个EAP 34可以在同一时钟周期期间发送同时的请求。如果EAP 34与引擎30之间的运输时延多于一个时钟周期，则在背压信号能够被声明以便于停止EAP发送更多分组(例如，“不可停止的数据”)之前，对引擎34的多于一个请求可能被发送。

在另一个示例实施例中，引擎30经由信用点来调控它们资源的分发。这些信用点对应于在引擎30处的缓冲器位置，并且速率取决于EAP 34被给予的信用点的量。例如，EAP34请求一个或多个信用点，然后当引擎能够向请求的EAP 34授予信用点时它如此做。接着，当EAP 34接收到该信用点时，它向引擎30发送对资源的请求。在被消耗时，该引擎将信用点返回给EAP 34。这能够通过利用响应或者经由分离总线来捎带该信用点而实现。

在一个示例实施例中，如果引擎30的软缓冲器32-S中有缓冲器空间，则引擎30向请求了信用点的(多个)EAP 34授予信用点。信用点对应于软请求缓冲器中的条目。引擎30(在一个实施例中是该引擎)具有用于每个EAP 34(或类似客户端)的计数器(未示出)，以便保持跟踪每个EAP 34当前所需要的信用点的数量。EAP 34可以通过分离总线上的信号来从引擎30请求信用点(通过例如+1来增加相关联的计数器的计数)。引擎30也可以具有代理(未示出)，该代理在请求了信用点的所有EAP 34之中的轮询中选择哪个EAP 34来授予信用点。本公开内容不限制于轮询方案，并且也能够包括加权的轮询方案、大多数未完成信用点优先方案(most outstanding credits first scheme)(例如，最大队列优先)、严格优先级方案等。

当EAP 34被选择时，它的请求计数器减少例如-1。引擎30可以向同一EAP 34或不同的EAP 34授予多个信用点，以便得到更高的吞吐量。当这些引擎请求被引擎30消耗和处理时，它释放软缓冲器32-1，由此使得这些信用点再次可用于由代理分发。引擎30利用通向EAP34的分离总线上的信号来发送信用点许可。计数器增加例如+1，这意味着EAP 34被准许从该引擎请求该数量的引擎资源，并且当该请求实际上被传输给引擎30时，该计数器减少相同量，例如，-1。

例如，代理保持跟踪可用的信用点。代理通过具有与软缓冲器中的条目的数量相对应的X个信用点而开始，并且当代理向EAP 34授予信用点时，可用的信用点减少。代理不会授予信用点使得可用的信用点变为负的。当引擎的软请求缓冲器32-S中所存储的引擎请求被引擎30消耗时，它释放软请求缓冲器32-S中的一个条目。然后代理的可用信用点的数量增加，并且该信用点再次可用于由该代理分发给EAP 34中的一个EAP。

在另一个示例实施例中，引擎30经由使用分离请求/许可总线(未示出)的请求许可方案，来调控它们资源的分发。例如，EAP请求多个信用点，并且如果引擎能够接受这些请求而不扰乱硬路径上的分组流，则该引擎向该EAP授予多个信用点。在这个示例实施例中，速率取决于往返时间，能够通过一次授予多个信用点来改进往返时间。

在这些实施例中，如果这些信用点根据当前需求而被分发，则当与有关技术相比较时，引擎30的软路径缓冲器32-S和引擎容量可以更高效地被利用。如所描述的，根据这些示例实施例的引擎30能够表现得像代理并且根据需求来分发它们各自的资源容量。

另外，在一些示例实施例中，引擎30通过适配向EAP 34中的每个EAP所授予的信用点的量，来调控速率。在这些实施例中，适应性方案基于EAP 34的特定发送频率。例如，通过经由信用点总线(未示出)来发送定期的信用点更新(其中当新的更新到达时，未被使用的信用点丢失)或者通过发送定期适配{+，-，0}。

此外，在一种示例实施例中，专门的请求许可引擎被使用，以通过例如以轮询类型方式在当前请求对请求的许可的所有EAP 34之中许可请求而实施该代理。

在一种替换实施例中，提供有一种动态许可请求方案。在这个实施例中，如果EAP34需要代表软路径中的分组向引擎30发送N个请求，则EAP将从引擎30请求N个对请求的许可。引擎30然后将基于它的当前处理负载而向EAP 34发送多至N个的对请求的许可。响应于接收到该多至N个的对请求的许可，该EAP将该许多请求传输给引擎30，其中它们被存储在软路径缓冲器32-S中，直到它们能够被执行而不扰乱硬路径中的分组流。

为了更好地理解这个动态许可请求方案，出于解释的简单性，假设EAP 34一次仅能够请求1个信用点。因此，EAP 34在它请求新的信用点之前需要使用该信用点。

在一种示例实施例中，EAP 34基于经许可的请求(N)而保持跟踪每引擎的状态。当所有经许可的请求被发送给EAP 34时，然后EAP请求新的信用点。在有多个信道的情况中，EAP 34代表软路径中的分组向多个引擎30提交许可请求。在这种情况中，该EAP在发送请求之前需要从向其提交许可请求的所有引擎30获得许可，或者该请求一旦被许可EAP 34就发送该请求并且然后在前进至管道线处理器10的下一级之前等待所有的响应。在前进至管道线处理器10的下一级之前等待所有的响应，通过将信用点被占用的时间减少到尽可能地少，而更好地利用了资源。在有多个引擎30的情况中，如果一次仅有一个请求，则仅有一个每信道的状态并且简单的解决方案是一次仅授予一个信用点。这是因为在引擎使用期间不需要保持跟踪后来的分组。因为这个动态许可请求方案中的EAP不能实际上不具有某事物要发送给引擎30而请求信用点以便于避免丢失信用点，所以这个方案不需要支持每引擎30的分离的N个状态。

为了更好地从引擎30的视点来理解该动态许可请求方案，假设对每个引擎30有多个未完成的信用点，因此克服了信道总线时延并且由此仅受到软路径的请求许可时延的限制。关于每引擎的状态，如果M是可用信用点的当前数量(其对于填满软路径缓冲器32-S是不受限制的)并且N是当前未完成的所授予的信用点的数量，则当一个请求由引擎30消耗时，M增加1。类似地，当一个请求从EAP 34被接收时，则M减少1。当一个信用点由引擎30授予时，则N增加1，并且当一个请求由引擎30从该EAP接收到时，则N减少1。

基于上述，在这个方案中M应当始终大于或等于N，除了当M小于0时，这意味着有存在缓冲器溢出，以及当N小于0时，这意味着已经存在未预期的请求。

当EAP 34想要成为请求调度的一部分时，则它设置待决的请求标记。为了理解这个方案中的每EAP 34的状态，假设G是未完成的经许可的请求。如果一个请求被许可，则G增加1。如果一个请求被接收，则G减少1。除了当G小于零时(意味着已经存在未预期的请求)，N等于G。

在一个示例实施例中，引擎使用超时(T)来保护免于丢失请求。当新的请求被许可时，T是MAX。MAX的值是任意设定的，以便于当然地成为一种误差，但不是太大以致于将发生不稳定。T每个时钟周期减少例如1。

当M大于0时，则引擎能够许可请求，并且为了履行请求，根据一种示例实施例，在具有待决请求的EAP 34之间实施轮询。

在另一个示例实施例中，存在一种静态的基于信用点的软路径。在这个实施例中，软路径依赖于静态信用点系统，在静态信用点系统中，信用点在编译时间被分发。对于引擎30，B等于与软路径缓冲器32-S相对应的信用点的总数量。在编译时间，这些信用点C在EAP之间被分发，使得C的总数小于B，由此防止软路径将干扰硬路径中的分组流的可能性。在一个示例性实施例中，EAP一次被指配多于一个信用点以得到高吞吐量并且由此克服信道总线时延。

多个流

如所描述的，硬路径它自己像常规的处理管道那样工作，并且因此硬实时系统100不被要求具有多于一个硬路径。然而，被理解的是，本公开内容不限制于此，并且在示例实施例中，如由在图1和3中从流量管理器40通过硬实时系统100向信宿流动的多个线条所指示的，存在多于一个硬路径。

另一方面，软路径从例如用于不同应用的不同流受益，例如，如果不同应用使用不同的引擎30，则它们能够相互独立地处理。也就是说，根据示例实施例，如由在图3中从流量管理器40通过软实时系统200向信宿50流动的多个线条所指示的，存在多于一个软路径。

在示例实施例中，本文所描述的混合系统300被具体化为片上系统(SOC)，其中上面所描述的组件中的每个组件被提供在同一芯片上。在示例实施例中，这些混合系统被具体化为SOC，其中至少管道线处理器10和引擎30被提供在同一芯片上并且没有被提供在该同一芯片上的其他组件被提供作为分立组件、作为其他片上系统、或者它们的组合。根据示例实施例，这些混合系统300被具体化为经由内部网络(总线结构/系统总线)等而连接的完全分立的组件。

图5图示了根据本文所描述的示例实施例的示例方法的流程图。在S100处管道仲裁器20接收分组，并且在S105处确定该分组是否将在硬路径中被处理。

在S100处，响应于确定该分组将在硬路径中被处理，管道仲裁器20将该分组发送给管道线10的硬路径。在S115处，响应于该分组到达管道线10的硬路径，EAP 34从引擎30请求资源以便处理该分组。在S120处，响应于从引擎30接收到资源，该EAP利用对处理器14的使用来处理该分组。在步骤S125处，如果管道线10中存在另一个处理级，则该过程开始于S115而重复。否则，如果不存在下一级，则经处理的分组被发送给信宿50并且该过程对于该管道线10结束。

在S105处，响应于确定该分组将不在硬路径中被处理(例如，它被运往软路径)，管道仲裁器20将该分组发送给管道线10的软路径。在S130处，响应于确定该分组将不在软路径中被处理，网络设备将该分组缓冲在管道仲裁器20中，除非背压信号存在或者被声明。也就是说，在不存在背压时，即，当背压被解除声明时，该分组被缓冲在管道仲裁器20中。在S135处，响应于确定背压信号存在或者被声明，软实时系统200向上游发信号以请求流量管理器40停止发送将在软路径中被处理的分组。这个背压信号保持声明，直到系统背压允许该分组被发送给管道线10以被存储在软路径缓冲器18中。

在S140处，响应于接收到软路径上的该分组，该分组被缓冲在缓冲器18中。在S145处，响应于将该分组存储在缓冲器18中，EAP34向引擎30发送许可请求。

在S150处，响应于从该EAP接收到许可请求，引擎30确定是否有充足的资源可用于处理该分组而不影响硬路径的时延。响应于确定没有足够的资源可用于处理该分组而不影响硬路径的时延，该许可请求被缓冲在引擎30的软路径缓冲器32-S中，直到该请求能够被许可。如果软路径缓冲器32-S超出预定的填充水平阈值，则它向软实时系统提供或者声明背压信号，以防止更多分组被发送给软路径，直到软路径缓冲器32-S填充水平下降到该预定填充阈值之下。

在S155处，响应于确定有足够的资源可用于处理该分组而不影响硬路径的时延，该引擎向EAP 34发送许可。在S160处，响应于接收到该许可，该EAP从引擎30请求资源以便处理该分组。

在S165处，响应于处理该分组，确定管道线10中是否存在另一级。如果不存在另一级，则该过程对于这个管道线10中的该分组结束。否则，如果存在另一级，则在S170处，该软实时系统确定背压信号是否被声明，以便于允许该分组被缓冲在下一级中。

在175处，响应于确定背压被声明以便于不允许该分组被缓冲在下一级中，软实时系统200用信号通知这些上游级不发送另一个分组，并且这些软实时系统继续监测背压信号，直到背压信号被解除声明以便于允许该分组被发送给下一级。在180处，响应于确定背压信号被解除声明以便于允许该分组被缓冲在下一级中，软实时系统200用信号通知这些上游级发送另一个分组，并且该分组被存储在下一级的缓冲器18中，由此将该过程循环回到S140。

结论

尽管已经关于各种实施例在上面描述了发明的概念，但是注意，不偏离所描述的特征的技术思想和范围，熟悉这个领域的技术人员能够有对这些特征的各种各样的排列和修改，这些特征的技术思想和范围应该由所附权利要求来限定。

进一步地，虽然本申请文件包含许多特征，但是这些特征不应当被解释为是对本公开内容或所附权利要求的范围的限制。在分离的实施例的上下文中描述的某些特征也能够组合地被实施。相反地，在单个实施例的上下文中描述的各种特征也能够分离地或者以任何合适的子组合而被实施在多个实施例中。

尽管各附图以具体的顺序描述了各操作和/或示出了组件的具体布置，并且在数据中心的访问区段的上下文中被描述，但是人们不应当将该具体顺序和/或布置解释为是被限制的，或者所执行的所有操作以及所公开的组件被要求获得期望的结果。存在众多能够被配置为以在本公开内容中关于各种实施例所描述的方式来转发分组、传输各种地址解析消息、以及更新地址缓存和分组地址的硬件和软件设备。因此，其他实施方式也在以下的权利要求的范围内。

Claims (20)

1.一种用于处理分组的网络设备，所述设备包括：

入口前端，被配置为将分组流中的第一分组识别为将在多个处理级中的每个级以有保证速率来处理的分组，并且将所述分组流中的第二分组识别为将在所述多个处理级中的每个级不以有保证速率来处理的分组；

多个引擎，被配置为提供用于在处理级处理所述分组流中使用的相应资源；

所述处理级被配置为：

(i)对于所述第一分组，选择性地促使使用从所述引擎中的一个引擎获得的所述资源来对所述第一分组执行第一分组处理操作，并且在与所述有保证速率相对应的时间段内将所述第一分组传递给下一个处理级；以及

(ii)对于所述第二分组，选择性地从所述引擎中的一个引擎请求所述资源用于处理所述第二分组，将所述第二分组缓冲在缓冲器中直到所述资源可用，促使使用所述可用的资源来对所述第二分组执行第二分组处理操作，以及将所述第二分组以不被保证的速率传递给下一个处理级。

2.根据权利要求1所述的用于处理分组的网络设备，其中所述处理级被布置在管道线中。

3.根据权利要求1所述的用于处理分组的网络设备，其中所述入口前端、所述引擎、以及所述多个处理级被设置在同一集成电路设备上。

4.根据权利要求1所述的用于处理分组的网络设备，其中所述分组流包括将以有保证的处理速率来处理的多个分组，并且所述多个引擎被配置为，响应于确定向所述第二分组许可所述资源将不影响将以所述有保证速率来处理的分组的所述有保证速率，向请求所述资源以用于所述第二分组的所述处理级许可所述资源。

5.根据权利要求4所述的用于处理分组的网络设备，其中所述入口前端被配置为，将数据分组作为将以所述有保证速率来处理的分组而提供给所述多个处理级。

6.根据权利要求1所述的网络设备，进一步包括背压总线，其中下游处理级被配置为，通过所述背压总线用信号向上游处理级通知，所述下游处理级是否可用于接收所述第二分组以用于附加处理。

7.根据权利要求6所述的网络设备，其中所述下游处理级基于所述下游处理级的缓冲器填充程度，用信号向所述上游处理级通知是否传递所述第二分组。

8.根据权利要求1所述的网络设备，其中响应于下游处理级的缓冲器达到预定充满阈值，所述下游处理级向上游处理级发送信号来停止发送分组。

9.根据权利要求1所述的网络设备，进一步包括设置在所述处理级中的软路径缓冲器，所述软路径缓冲器被配置为在可变时间段内缓冲所述第二分组，所述可变时间段是以下项的函数：从处理级到所述引擎中的一个或多个引擎的对许可访问所述资源的请求、以及由一个或多个引擎给请求的所述处理级的使得所述资源可用于处理所述第二分组的许可。

10.根据权利要求9所述的网络设备，其中所述多个处理级被布置在管道线中，并且

其中所述软路径缓冲器被配置为向前级提供背压信号，所述背压信号指示是否在所述管道线中向前发送将不以所述有保证速率来处理的另一个分组。

11.根据权利要求10所述的网络设备，其中所述软路径缓冲器被配置为，响应于所述软路径缓冲器中的一个软路径缓冲器超出充满阈值而声明所述背压信号，并且

其中所述入口前端被配置为，接收所述背压信号并且不发送将不以有保证速率来处理的另一个分组，直到所述背压信号被解除声明。

12.根据权利要求1所述的网络设备，其中所述多个处理级被布置为提供：

软路径，其不以有保证速率来处理分组；以及

硬路径，其以有保证速率来处理分组而不论施加在所述引擎所述软路径上的处理负载。

13.一种用于处理分组的方法，包括：

将分组流中的第一分组识别为将在多个处理级中的每个级以有保证速率来处理的分组；

将分组流中的第二分组识别为将在所述多个处理级中的每个级不以有保证速率来处理的分组；

在处理级从引擎请求资源，使得能够在有界时间段内对所述第一分组执行操作，所述有界时间段由与所述有保证速率相对应的预定时延来限定；

使用所述资源对所述第一分组执行处理操作，并且在由所述有保证速率所限定的时间段内将所述第一分组传递给下一级；

请求用以从所述引擎请求所述资源的准许，使得能够对所述第二分组执行操作；

响应于资源请求，做出与使用所述资源是否将影响所述第一分组的所述有保证速率有关的确定，并且根据所述确定来提供资源许可；以及

响应于所述资源许可，从所述引擎请求所述资源。

14.根据权利要求13所述的方法，进一步包括：缓冲所述资源请求，直到所述确定指示所述第一分组的所述有保证速率将不被影响。

15.一种网络设备，用于以有保证速率来处理第一分组的流，并且用于以可变速率来同时处理第二分组的流，所述网络设备包括：

一个或多个引擎，供应处理资源用于在处理所述第一分组中使用并且用于在处理所述第二分组中使用；以及

处理级，耦合至所述一个或多个引擎，所述处理级被配置为：

在由所述有保证速率所限定的时段内，使用从所述一个或多个引擎获得的所述资源来处理所述第一分组，以及

针对用于处理所述第二分组的所述资源而做出资源请求，缓冲所述第二分组，直到所述引擎中的一个或多个引擎指示用于处理所述第二分组而不导致用于处理所述第一分组的所述时段超出所述有保证速率的所述资源的可用性。

16.根据权利要求15所述的网络设备，进一步包括管道线处理器，所述管道线处理器包括多个处理级，所述多个处理级包括所述处理级，所述多个处理级每个都被配置为对所述第一分组和所述第二分组执行一个或多个处理操作。

17.根据权利要求16所述的网络设备，其中所述引擎基于所述引擎是否能够许可所述资源而不影响所述第一分组的所述有保证速率，来确定何时许可所述资源。

18.根据权利要求15所述的网络设备，所述引擎中的每个引擎具有资源并且被耦合至所述处理级，所述处理级被配置为生成与所述引擎中的多于一个引擎有关的资源请求。

19.根据权利要求18所述的网络设备，其中所述处理级向所述引擎中的每个引擎提供所述资源请求。

20.根据权利要求15所述的网络设备，进一步包括：分组分类器，设置在所述处理级和所述引擎的上游，被配置为将分组流中的分组分类为所述第一分组或者所述第二分组。