专利名称：为分组处理确定时钟信号的方法和系统的制作方法
本申请涉及以下同时待审查的申请“网络协议引擎”，律师案卷号42.P14732；和“跟踪乱序分组”，律师案卷号42.P14792。这些申请是与本申请同一天递交的，并且署名相同的发明人。
附录参考本申请包括微码指令的附录Appendix A。作者保留这一材料的适用版权。
背景技术：
网络使得计算机和其他电子设备能够交换各种数据，例如电子邮件消息、网页、音频数据、视频数据等等。在通过网络传输之前，数据一般被分配到一组分组(packet)中。接收方在收到这些分组后可以将数据重新组装回其原始的形式。
除了被发送的数据(“有效载荷”)外，分组还包括“头部(header)”信息。网络协议可以定义存储在头部中的信息、分组的结构以及过程应当如何处理分组。
不同的网络协议处理网络通信的不同方面。很多网络通信模型将这些协议组织成不同的层。例如，传输控制协议/因特网协议(TCP/IP)模型和开放软件机构(OSI)模型一类的模型定义了“物理层”，该层处理物理介质上的比特级(bit-level)传输；“链路层”，该层处理在物理连接上提供可靠的数据通信的下层细节；“网络层”，例如因特网协议，该层可以处理在寻找穿过网络连接源和目的地的路径时所涉及的任务；以及“传输层”，该层可以协调源设备和目的地设备之间的通信，同时使“应用层”程序与网络通信的复杂性隔离。
一种不同的网络通信模型——异步传输模式(ATM)模型被用在ATM网络中。ATM模型也定义了物理层，但是定义了ATM和ATM适配层(AAL)两层来取代TCP/IP模型和OSI模型中的网络层、传输层和应用层。
一般而言，为了在网络上发送数据，针对不同的通信层要生成不同的头部。例如，在TCP/IP中，传输层处理通过向应用提供的一组数据添加传输层头部而生成传输层分组(有时称为“段”)；网络层处理接着通过向传输层分组添加网络层头部而生成网络层分组(例如IP分组)；链路层处理接着通过向网络分组添加链路层头部而生成链路层分组(也称为“帧”)；诸如此类。这一过程被称为封装(encapsulation)。打个比方，封装的过程很像把信封一个又一个地套在一起。
在分组穿过网络后，接收方可以拆封(de-encapsulate)分组(例如，“打开”信封)。例如，接收方的链路层处理可以验证所接收的帧，并且将封入的网络层分组传递给网络层处理。网络层处理可以使用网络头部来验证分组的正确递送，并且将封入的传输段传递给传输层处理。最终，传输层处理可以基于传输头部来处理传输分组，并将得到的数据传递给应用。
如上所述，发送方和接收方都要完成一定量的处理来处置分组。此外，网络连接的速度持续快速增长。例如，每秒能够传送10吉比特(gigabit)甚至更快的网络连接可能很快普及。网络连接速度的增长向提供这些连接的设备提出了重要的设计问题。即，在这样的速度下，设备可能很容易被巨大的网络流量压倒。
图1是基于分组数据确定时钟信号的系统的图。
图2是基于分组数据确定时钟信号的过程的流程图。
图3是基于分组数据提供时钟信号的机制的示意图。
图4是以基于分组数据的时钟信号为特征的网络协议引擎的图。
图5是网络协议引擎的示意图。
图6是网络协议引擎的处理器的示意图。
图7是用于编程网络协议操作的指令集的图表。
图8是TCP(传输控制协议)状态机的图。
图9-13图示了跟踪乱序分组的方案的操作。
图14是跟踪乱序分组的过程的流程图。
图15-16是跟踪乱序分组的系统的示意图，所述系统包括内容可寻址存储器。
具体实施例方式
网络连接的速度正在不断加快。例如，达到甚至超过每秒10吉比特的连接可能很快就会普及。为了跟上网络速度的增长，正在设计的一些系统以不断加快的时钟速度(例如具有更高频率的时钟信号)来运行。时钟信号在一定程度上决定了数字系统在一段时间内可以做多少事情。不幸的是，以高频时钟信号运行系统组件既消耗了大量功率，又可能产生热量，这些热量可能潜在改变对温度敏感的硅的行为。
图1描绘了一种基于一种或多种分组104特性来调整提供给分组处理逻辑108的时钟信号的方法。通过识别时钟信号可被减慢(例如频率降低)的时间段，该方法潜在地可能节省功率并且减少发热。潜在地，使用这种方法可以减轻对昂贵的冷却系统的需要，这些冷却系统可能占据了宝贵的设备资源(real estate)。
更详细地，图1描绘了分组104通过网络102连接而到达。一般而言，分组包括有效载荷和至少一个头部，有效载荷就是想要发送的数据，而头部描述了不同的分组特性。根据正在使用的网络协议，分组可以具有多种形式，例如IP分组、TCP段、ATM单元、HDLC(高层数据链路控制)帧、协议数据单位片段等等。
如图所示，分组104由分组处理逻辑108来处理。可以使用多种技术来实现逻辑108，例如ASIC(专用集成电路)、FPGA(现场可编程门阵列)和/或数字逻辑门的组合等实现方式。分组处理逻辑108也可以由执行分组处理指令的处理器来提供。
如图所示，分组处理逻辑108从时钟定标器(scaler)106接收时钟信号。时钟定标器106基于一个或多个接收分组104中的数据来确定时钟信号的频率。例如，时钟定标器106可以使用存储在分组104的头部中的多种信息，例如分组大小、有效载荷大小、服务质量、优先级等。此外，用总体特性取代单个分组的特性来调整时钟频率(例如，接收到的分组的平均大小)。
可以用多种硬件、固件和/或软件来实现时钟信号的确定。例如，可以写入程序来实现图2中所示的过程120。如图所示，在接收到分组数据(122)后，过程120可以确定(124)分组处理逻辑的时钟信号，并且生成(126)所确定的时钟信号。例如，程序可以将时钟信号标识符存储在由时钟信号源访问的寄存器中。
可替换地，如图3所示，可以用硬件来实现定标逻辑106。如图所示，定标系统106接收分组数据，并且相应地调整输出时钟信号的频率。如图所示，该方案使用分频器130a-130b来提供一定范围的可用频率(例如，32x、16x、8x和4x)。不同频率的信号被馈入多路复用器134，以基于一种或多种分组特性进行选择。例如，选择器134可以以一个幅度比较器为特征，该幅度比较器基于分组大小(或者其他分组特性)与预先计算出的不同阈值的比较结果而生成多路复用器132的选择信号。举例来说，系统128可以为多达64字节大小的分组选择32x的频率，为64和88字节之间大小的分组选择16x的频率，为88和126字节之间大小的分组选择8x的频率，为126和236字节之间大小的分组选择4x的频率。下面将更详细地讨论对这些示例性范围的确定，但是频率选择的基础和用来提供频率的机制可能变化很大。虽然图3仅仅图示了四种不同的时钟信号，但是其他实现方式可以将n个时钟信号馈入到n:1多路复用器132中。此外，虽然图3描绘了特定的硬件配置，但是多种其他设计也可以类似地调整输出时钟信号。
为了图示上述频率定标计数的一种潜在应用，图4描绘了网络协议“去负载(off-load)”引擎206的一个实施例。简要地说，类似于数学协处理器可以帮助中央处理单元(CPU)进行不同的计算，去负载引擎206至少可以部分地减少由于执行不同的网络协议操作而经常施加在主机上的网络通信负荷。例如，引擎206可被配置来执行用于传输层协议(例如TCP和用户数据报协议(UDP))、网络层协议(例如IP)和应用层协议(例如套接口编程)的操作。类似地，在ATM网络中，引擎206可被配置来提供ATM层或AAL层操作。引擎206还可以被配置来提供其他协议操作，例如与因特网控制消息协议(ICMP)有关的操作。
除了通过处置协议操作而节省主机处理器资源外，所示出的引擎206还可以提供“线速(wire-speed)”处理，甚至是针对非常快的连接，例如每秒10吉比特的连接和每秒40吉比特的连接。换言之，引擎206一般可以在另一个分组到达之前完成对一个分组的处理。通过跟上高速连接的脚步，引擎206可以潜在地避免或减小与排队大量积压分组相关联的开销和复杂度。
所示出的示例系统206包括接口208，用于接收在主机和网络202之间传播的数据。对于向外输出的数据，系统206的接口208接收来自主机的数据并生成分组，以例如经由提供网络连接(例如以太网连接或无线连接)的PHY和媒体访问控制(MAC)设备(未示出)进行网络传输。对于接收的分组(例如经由PHY和MAC到达的分组)，引擎206的接口208可以将分组处理的结果传递给主机。例如，系统206可以经由小型计算机系统接口(SCSI)或外设部件互连(PCI)类总线(例如PCI-X总线系统)与主机通信。
除了接口208之外，引擎206还包括实现协议操作的处理逻辑210。与接口208一样，可以使用多种技术来设计逻辑210。例如，逻辑210可被设计为硬连线ASIC(专用集成电路)、FPGA(现场可编程门阵列)和/或数字逻辑门的另外组合。
如图所示，数字逻辑210还可以利用处理器212(例如微控制器或微处理器)和存储设备216(例如ROM(只读存储器)或RAM(随机访问存储器))来实现，所述存储设备216用于存储处理器212可以执行来实现网络协议操作的指令。基于指令的引擎206提供了高度的灵活性。例如，当网络协议经受改变或者被替换时，可以通过替换指令而不是替换引擎206自身来更新引擎206。例如，主机可以通过例如在该主机启动时，将指令从主板上的外部闪存或ROM载入到存储设备216中而对引擎206进行更新。
由于对一个给定的分组可以执行很多指令，因此为了以线速运行，提供给引擎206的时钟可能是一个非常快的频率，要远大于跟上网络连接所需的频率。前面说过，这样可能会导致多种问题，包括增大的功率需求和潜在的热积聚。
作为施加给引擎206的组件的单一时钟信号的替换方案，图4描绘了一种“多频率”方法，其中以不同的频率为不同的引擎206组件提供时钟。作为一个实施例，可以用对应于网络连接速度的频率“1x”来为不同的接口108(208)组件提供时钟。由于处理逻辑210可被编程来执行多条指令，以针对给定的分组实现适当的网络协议操作，所以可以用比接口208组件更快的频率为不同的处理逻辑210组件提供时钟。例如，可以用接口208时钟频率的“k”倍为一个或多个处理逻辑210组件提供时钟，其中“k”大到足以提供足够的时间使处理器完成执行用于分组的指令，而不落后于线速。应当注意，并非处理引擎110(210)和接口108(208)模块内的所有组件都需要运行在同一时钟频率下。
举一个实施例，对于接口208的数据宽度为16位的引擎206而言，为了实现每秒10吉比特的速度，接口208的时钟频率应当为625MHz(例如，[每周期16位]×[每秒625,000,000周期]＝每秒10,000,000,000位)。假设接收的是64字节的分组(例如，仅有IP和TCP头部、帧校验序列以及硬件源地址和目的地地址的分组)，将花费16位/625MHz接口208一共32个周期来接收分组的所有位。潜在地，分组间的间隙可以在下一分组到达之前提供额外的时间。如果一组多达n条的指令被用来处理分组，并且每个周期可以执行不同的指令，那么处理模块210的时钟频率可以是k·(625MHz)，其中k＝n条指令/32个周期。为了实现方便，k的值可以上舍入(rounded up)到一个整数值或者一个2n的值，但这些都不是很严格的要求。
以上实施例考虑了最坏的情形(例如，非常小的分组)。然而，在实际当中，大多数的分组(约95％的分组)以更大的分组大小为特征，并且给予引擎206更多的时间来处理。因此，引擎206调整(106)时钟信号，提供给处理逻辑210组件基于一种或多种分组特性而改变的频率。举例来说，对于更大的分组，引擎206在下一个分组到达之前有更多的时间来处理所述分组，因而可以降低频率而不会落后于线速。同样，对于小一些的分组，可以提高频率。因此，时钟定标器106可以接收标识分组大小的数据(例如在IP分组头部中的长度字段)，并且相应地定标时钟频率的大小。
对于所示的示例引擎206，可以确定处理逻辑的时钟信号频率，使得它满足以下公式[(分组大小/数据宽度)/接口时钟频率]＞＝(接口时钟周期/接口时钟频率)+(指令的最大数量/处理时钟频率)。
处理时钟信号频率可以上舍入到接口时钟信号频率的整数倍，或者上舍入到等于2n的某个整数倍，但这仅是为了实现方便，并不一定严格如此。
为了节省处理时间，可以针对不同的分组特性预先计算不同的处理时钟信号频率。例如，定标器126可以访问基于一定范围的分组大小标识出某一具体时钟信号的数据。
使定标逻辑126在物理上靠近频率源可以减少功耗。此外，在全球时钟分布点处调整时钟既可以节约功率又可以减少提供时钟分发的逻辑需要。
此外，针对不同的进入分组“在传输过程中(on the fly)”自适应定标时钟频率，这样做可以通过降低在处理较大分组时的工作频率而减小功率。继而这又可以导致运行中的系统温度降低，从而可以避免硅“热点”的产生和/或昂贵的冷却系统。
图5描绘了系统206的示例实现方案。总体上看，在这个实现方式中，系统206将不同连接的上下文数据存储在存储器224中。例如，对于TCP协议，这一数据被称为TCB(传输控制块)数据。对于给定的分组，系统206在存储器224中查找对应的上下文数据，并使这一数据可用于处理器212，在这个实施例中是经由工作寄存器226而对处理器212可用。使用所述上下文数据，处理器212执行一组适当的协议实现指令214。可能由处理器212修改的上下文数据然后被返回到上下文数据存储器224。
更详细地说，所示出的系统206包括输入定序器220，其解析接收分组的头部(例如TCP/IP分组的TCP和IP头部)并暂时缓冲解析后的数据。输入定序器206还可以发起将分组的有效载荷存储在主机可访问的存储器中(例如经由DMA(直接存储器访问))。
如上所述，系统206针对不同的网络连接将上下文数据存储在存储器224中。为了快速地检索一个给定分组的上下文数据224，所描绘的系统206包括了内容可寻址存储器222(CAM)，该存储器为通过分组的IP源地址和目的地地址以及源和目的地端口的组合而标识出的不同连接存储不同的连接标识符(例如索引号)。就象数据库可以基于关键字(key)来检索记录一样，CAM可以基于内容值快速地检索所存储的数据。因此，基于由输入定序器220解析的分组数据，CAM 222可以快速地检索出连接标识符，并将这一标识符提供给上下文数据存储器224。接着，对应于所述标识符的连接数据被传输到工作寄存器226，以供处理器212使用。
如果分组代表了新连接的开始(例如CAM搜索连接失败)，那么工作寄存器226被初始化(例如，设置为TCP中的“LISTEN”状态)，并且例如使用LRU(最近使用)算法或者其他分配方案将CAM 222和上下文数据存储器224的条目分配给所述连接。
可以选择连接系统206的不同组件的数据线的数量，以允许数据在单个时钟周期内在所连接的组件212-218之间传输。例如，如果某一连接的上下文数据包括n位的数据，那么系统206可被设计为使得连接数据存储器224可以向工作寄存器226提供n条线的数据。
因此，所示出的示例实现方式最多使用三个处理周期将连接数据载入工作寄存器226一个周期查询CAM 222；一个周期访问连接数据224；以及一个周期载入工作寄存器226。这一设计既可以节省处理时间，又可以节约对存储器结构222、224的功耗性访问。
在检索出用于某一分组的连接数据后，系统206可以对该分组执行协议操作，例如让处理器212执行存储在存储器216中的协议实现指令。当不使用处理器212以节省功率时，可以将处理器212编程为“空闲”。在接收到“唤醒”信号(例如当检索出或正在检索连接上下文时从输入定序器220接收到该信号)后，处理器212可以确定当前连接的状态，并且识别用于处置这一状态的指令的起始地址。然后，处理器212执行从该起始地址开始的指令。根据这些指令，处理器212可以更改上下文数据(例如通过更改工作寄存器226)，在发送缓冲器228中组装消息以进行接下来的网络传输，和/或可以使经过处理的分组数据对主机(未示出)可用。
由于不同的组件212-218可以接收不同的时钟信号，因此被称为“同步器”(未示出)的设备可被用来实现各组件之间(例如在连接数据存储器224和工作寄存器226之间)的通信。
不同的时钟信号可被路由到引擎206内的不同组件。例如，输入定序器220可以接收“1x”的时钟信号，处理器212接收“kx”的时钟信号，而连接数据存储器224和CAM 224(222)根据实现方式可以接收“1x”或“kx”的时钟信号。
图6更详细地描绘了处理器212。如图所示，处理器212可以包括ALU(算术逻辑单元)232，其解码并执行被载入到指令寄存器234中的微码指令。除了分支指令和起始地址初始化之外，指令214可以依次连续地从存储器214被载入(236)到指令寄存器234中。指令214可以指定对存储了解析后的分组数据的接收缓冲器230、工作寄存器226、发送缓冲器228和/或主机内存(未示出)的访问(例如读或写访问)。所述指令还可以指定对暂存(scratch)存储器、杂项(miscellaneous)寄存器(例如dubbed R0、cond和statusok寄存器)、移位寄存器等等(未示出)的访问。为了编程方便，可以向发送缓冲器228和工作寄存器226的不同字段分配标签以在指令中使用。此外，例如针对不同的连接状态可以定义各种常数。例如，“LOAD TCB[state]，LISTEN”指示处理器212将当前工作寄存器226中的上下文的状态改变为“LISTEN”状态。
图7描绘了一个微码指令集的实施例，该指令集可被用于编程处理器来执行协议操作。如图所示，所述指令集包括以下操作在系统内移动数据(例如LOAD和MOV)，执行算术和布尔运算(例如AND、OR、NOT、ADD、SUB)，比较数据(例如CMP和EQUAL)、操纵数据(例如SHL(左移))以及提供程序内的分支转移(例如BREQZ(如果前面运算的结果等于0则有条件地分支转移)、BRNEQZ(如果前面运算的结果不等于0则有条件地分支转移)和JMP(无条件跳转))。
所述指令集还包括专门为利用引擎206资源来实现协议操作而定制的多种操作。这些指令包括用于清除CAM中用于某一连接的条目的操作(例如，CAM1CLR)和用于在工作寄存器226和连接数据存储设备224之间为某一连接传输数据的操作(例如TCBWR)。其他实现方式还可以包括以下指令向存储与连接相关联的数据的CAM读写标识符信息的指令(例如，CAM1READ key→index)和CAM1WRITE key→index)和读连接数据224的指令(例如，TCBRD key→destination)。可替换地，这些指令可被实现为硬连线数字逻辑。
虽然有可能缺少传统的通用CPU可提供的很多指令(例如处理器212可能不具有用于浮点运算的指令)，但是所述指令集为开发者提供了对适用于网络协议实现的引擎206资源的简易访问。程序员可以使用所述微码指令直接对协议操作进行编程。或者，程序员可以使用多种代码开发工具(例如编译器或汇编程序)。
如上所述，引擎206指令实现了多种网络协议的操作。例如，引擎206可以实现诸如TCP的传输层协议的操作。在RFC(征求意见稿)793、1122和1323中可以找到完整的TCP规范以及可选的扩展。
简要地说，TCP向应用提供了以连接为导向的服务。即，就像接听电话时假定电话公司将做好一切工作一样，TCP向应用提供了简单的原语，例如用于建立连接的原语(例如CONNECT和CLOSE)和用于传输数据的原语(例如SEND和RECEIVE)。TCP透明地处置通信问题，例如数据重传、拥塞和流控制。
为了向应用提供这些服务，TCP对被称为段的分组进行操作。TCP段包括TCP头部，后面跟着一个或多个数据字节。接收方可以由接收到的段重新组装数据。段可能不是以正确的顺序到达它们的目的地，即使也有可能按正确的顺序到达(if at all)。例如，不同的段在穿过网络时可能经过特殊的路径(very paths)。因此，TCP向所传输的每个数据字节分配一个序列号。由于每个字节都被排序，因此每个字节都可以被确认来证实成功的传输。确认机制是累积性的，使得对某一特定序列号的确认可以指示出一直到那个序列号的所有字节都已被成功传递。
排序方案为TCP提供了管理连接的强有力的工具。例如，TCP可以使用被称为“滑动窗”的技术来确定发送方何时应当重传一个段。在“滑动窗”方案中，发送方在发射一个段后启动定时器。接收方在接收到后发回一个确认段，该段具有与接收方预期接收的下一序列号相等的确认号。如果发送方的定时器在发射字节的确认到达之前期满，则发送方再次发射所述段。所述排序方案也使得发送方和接收方能够基于网络性能以及发送方和接收方的能力来动态地协商用于调节被发送给接收方的数据量的窗大小。
除了排序信息外，TCP头部包括一组标志，它们使得发送方和接收方能够对连接进行控制。这些标志包括SYN(同步)位、ACK(确认)位、FIN(结束)位、RST(复位)位。包括SYN位“1”和ACK位“0”的消息(SYN消息)代表对连接的请求。包括SYN位“1”和ACK位“1”的应答消息(SYN+ACK消息)代表请求的接受。包括FIN位“1”的消息指示了发送方想要释放连接。最后，RST位为“1”的消息标识出由于某些原因(例如无效段或连接请求拒绝)应当被终止的连接。
图8描绘了代表在TCP连接的建立和释放过程中的不同阶段的状态图。该图描绘了不同的状态240-260以及在这些状态240-260之间的转移(用带箭头的线来表示)。用对应的事件/操作名称来标记各次转移，所述事件/操作名称标识出移动到下一状态240-260所需的事件和响应。例如，在接收到SYN消息并且以SYN+ACK消息作出响应后，连接从LISTEN状态242移动到SYN RCVD状态244。
在图8的状态图中，用实线转移示出了发送方(请求连接的TCP实体)的典型路径，而用虚线转移示出了接收方的典型路径。为了图示状态机的操作，接收方一般从CLOSED状态240开始，该状态指示了没有任何连接当前是活动的或者是未决的。在移动到LISTEN状态242等待连接请求后，接收方将接收到请求连接的SYN消息，并将用SYN+ACK消息来确认SYN消息，并且进入SYNRCVD状态244。在接收到SYN+ACK消息的确认后，连接进入ESTABLISHED状态248，该状态对应于正常的进行中的数据传输。ESTABLISHED状态248可以持续一段时间。最终，假设没有复位消息到达并且没有错误发生，那么服务器将接收并确认FIN消息，并且进入CLOSE WAIT状态250。在发出自己的FIN并进入LAST ACK状态260后，服务器将接收其FIN的确认，最后返回初始的CLOSED 240状态。
此外，状态图也管理着TCP发送方的状态。发送方路径和接收方路径共享上述很多相同的状态。然而，发送方还可以在请求连接后进入SYN SENT状态246，在请求释放连接后进入FIN WAIT 1状态252，在从服务器接收到释放连接的同意后进入FIN WAIT 2状态256，在客户端和服务器同时请求释放的情况下进入CLOSING状态254，在先前发射的连接段期满的情况下进入TIMED WAIT状态258。
引擎206协议指令可以实现上述属于RFC的很多TCP操作，即使不是所有操作。例如，所述指令可以包括用于选项处理、窗管理、流控制、拥塞控制、ACK消息生成和验证、数据分段、特殊标志处理(例如设置及读取URGENT和PUSH标志)、校验和计算等等的过程。协议指令还可以包括与TCP相关的其他操作，例如安全支持、随机数生成、基于TCP的RDMA(远程直接存储器访问)等等。
在配置为提供TCP操作的引擎206中，连接数据可以包括264位的信息，其中包括PUSH(用微码标签“TCB[pushseq]”来标识)、FIN(“TCB[finseq]”)和URGENT(“TCB[rupseq]”)序列号各占32位，还包括下一预期段号(“TCB[rnext]”)、当前通告窗的序列号(“TCB[cwin]”)、最后未确认序列号的序列号(“TCB[suna]”)和将成为下一个的下一段的序列号(“TCB[snext]”)。剩余位存储各种TCB状态标志(“TCB[flags]”)、TCP段代码(“TCB[code]”)、状态(“TCB[tcbstate]”)和错误标志(“TCB[error]”)。
为了图示被编程来提供TCP配置操作的引擎206，Appendix A给出了用于TCP接收方的源微码的一个例子。简要地说，例程TCPRST检查TCP ACK位，初始化发送缓冲器，并且初始化发送消息ACK号。例程TCPACKIN处理进入的ACK消息，并且检查ACK是不是无效的或者复制物。TCPACKOUT基于所接收和预期的序列号，响应于一个进入消息而生成ACK消息。TCPSEQ确定进入数据的首序列号和尾序列号，计算进入数据的大小，并且检查进入的序列号是否有效以及是否位于接收窗内。TCPINITCB初始化工作寄存器中的TCB字段。TCPINITWIN利用窗信息来初始化工作寄存器。TCPSENDWIN计算可包括到发送消息中的窗长度。最后，TCBDATAPROC检查进入的标志，处理“urgent”、“push”和“finish”标志，响应于消息来设置标志，并且将数据转发给应用或用户。
引擎206执行的另一项操作可以是分组重排序。例如，就像很多网络协议一样，TCP不假定TCP分组(“段”)将会按顺序到达。为了正确地重新组装分组，接收方可以跟踪所接收的尾序列号，并且等待接收到分配给下一序列号的字节。乱序到达的分组可以被缓冲，直到介于其间的字节到达。一旦所等待的字节到达，则潜在地可以从缓冲的数据中快速地检索出序列中的下面字节。
图9-13图示了可由系统206实现的、跟踪乱序分组的方案的操作。该方案允许在不使用传统排序算法的情况下对分组进行快速的“在传输过程中”的排序。如图所示，可以使用另一组内容可寻址存储器来实现所述方案，虽然这不是必要的。因此，使用这一技术的系统206可以包括两组不同的内容可寻址存储器——用来检索连接上下文数据的内容可寻址存储器222和用来跟踪乱序分组的内容可寻址存储器。为了图示说明，在TCP实现方案的环境中讨论图9-13。然而，该方案可广泛适用于多种分组重排序方案，例如编号分组(例如，协议数据单位片段)等等。
简要地说，当分组到达时，跟踪子系统300确定所接收的分组是否符合顺序。如果不是，则子系统300提请存储器识别一串与新到达的分组邻接的、相邻的先前接收的乱序分组，并且可以修改存储在存储器中的数据，以将新接收的分组添加到预先存在的串中。当分组按序到达时，系统可以访问存储器，以快速地识别出一串跟在新接收的分组之后的、相邻的先前接收的分组。
更具体地说，如图9所示，协议304(例如，TCP)将一组数据划分成若干通过网络308传输的分组306a-306d。在所示的实施例中，原始的数据组302中的15字节被分配在各个分组306a-306d中。例如，分组306d包括分配有序列号“1”到“3”的字节。
如图所示，跟踪子系统300包括内容可寻址存储器310、312，该系统存储着有关多串先前接收的相邻乱序分组的信息。存储器310存储由一个或多个乱序分组组成的相邻串的首序列号以及该串的长度。因此，当一个新的分组(这个分组在预先存在的串开始的地方结束)到达时，该新的分组可被添加到所述预先存在的串的顶部。同样，存储器312还存储由一个或多个分组组成的一个相邻分组串的末尾(尾序列号+1)以及该串的长度。因此，当一个新的分组(这个分组在先前存在的串的末尾处开始)到达时，该新的分组可被附加到所述先前存在的串的末尾，以形成一个更长串的相邻分组。为了图示这些操作，图10-13描绘了当分组306a-306d到达时所发生的一系列示例操作。
如图10所示，分组306b到达，其运送序列号从“8”到“12”的字节。假设接收设备300目前正在等待序列号“1”，则分组306b已算是乱序到达。因此，如图所示，设备300通过修改存储在其内容可寻址存储器310、312中的数据来跟踪乱序分组306b。由于在这个实施例中尚未存在任何串，所以分组306b不与先前接收的分组串邻接。因此，设备300存储起始序列号“8”以及该分组中的字节数“4”。设备300还存储所述分组的末尾的标识。在所示的实施例中，设备300通过给所接收分组的尾序列号加1(例如，12+1＝13)而存储结束边界。除了在内容可寻址存储器310、312中修改或添加条目外，设备300还可以存储所述分组或者对该分组的引用311b(例如指针)，以反映分组的相对顺序。这实现了在分组最终被发送给应用时对分组的快速检索。
如图11所示，设备300接下来接收到分组306a，该分组运送着从“13”到“15”的字节。再一次，设备300还是在等待序列号“1”。因此，分组306a也是乱序到达的。设备300检查存储器310、312，以确定所接收的分组306a是否与先前存储的任何分组串邻接。在这种情况下，新到达的分组306a并非结束在先前串开始的地方，而是开始于先前串结束的地方。换言之，分组306a与分组306b的“底部”邻接。如图所示，设备300通过增加预先存在的串的长度并且相应地修改它的首序列号数据和尾序列号数据，从而可以将分组306a合并到内容可寻址存储器数据中的所述串中。因此，虽然新串的长度从“4”增加到“7”，但是该新串的首序列号仍保持为“8”，不过该串的末尾序列号从“13”增加到“16”，以反映新接收的分组306a的字节。设备300还存储新的分组311a或者对该新分组的引用，以反映分组的相对顺序。
如图12所示，设备300接下来接收运送字节“4”到“7”的分组306c。由于这个分组306c不包括下一预期序列号“1”，所以设备300重复上述过程。即，设备300确定新接收的分组306c适合放在横跨分组306b、306a的分组串之上。因此，设备300修改存储在内容可寻址存储器310、312中的数据，以将该串新的起始序列号“4”以及该串新的长度数据“11”包括进来。设备300再次存储分组311c数据或者引用，以反映分组310c的相对顺序。
如图13所示，设备300最后接收到分组306d，其中包括下一预期序列号“1”。设备300可以立即将这一分组306d传输给某一应用。设备300还可以检查其内容可寻址存储器310，以确认其他的分组串是否也可被发送给所述应用。在这种情况下，所接收的分组306d与已横跨分组306a-306c的分组串邻接。因此，设备300可以立即以正确的顺序将串接分组中的数据转发给所述应用。
图9-13所示的系列示例突出了本方案的几个方面。首先，本方案可以防止乱序分组被丢弃以及由发送方重传。这可以提高整体吞吐率。本方案还使用非常少的内容可寻址存储器操作来处置乱序分组，节约了时间和功率。此外，当分组按照正确顺序到达时，单个内容可寻址存储器操作就可以识别出也可被发送给应用的一系列相邻分组。
图14描绘了用于实现上述方案的过程320的流程图。如图所示，在接收(322)分组后，过程320确定(324)该分组是否符合顺序(例如，该分组是否包括下一预期序列号或者下一预期分组号)。如果不是，过程320确定(332)所接收分组的末尾是否与现存分组串的起始处邻接。如果是的，则过程320可以修改(334)存储在内容可寻址存储器中的数据，以反映更大的、合并后的分组串，这个分组串从所接收分组处开始，在先前存在的分组串的末尾处结束。过程320还确定(336)所接收分组的起始处是否与现存分组串的末尾邻接。如果是的，则过程320可以修改(338)存储在内容可寻址存储器中的数据，以反映以所接收分组结束的、更大的合并后分组串。
潜在地，所接收的分组可以在两端与预先存在的分组串邻接。换言之，新接收的分组填补了两个串之间的一个洞。由于过程320对所接收分组的起始边界332和结束边界336都要检查，所以新接收的分组可能使得过程320将两个不同的串连接到一起，成为单条串。
如图所示，如果所接收的分组不与某个分组串邻接，那么过程320将数据存储(340)在内容可寻址存储器中以形成一条新的分组串，这条新的分组串至少在一开始仅包括所接收的分组。
如果所接收的分组是符合顺序的，则过程320可以查询(326)内容可寻址存储器，以识别出跟在所接收分组之后的邻接分组串。如果这样一个串存在，则过程320可以将新接收的分组与毗邻分组串中的其他分组的数据一起输出给某个应用。
可以使用硬件、固件和/或软件来实现这个过程。例如，图15和图16描绘了一种硬件实现方式。如这些图所示，所述实现方式以两个内容可寻址存储器360、362为特征——其中存储器360将乱序分组串的首序列号作为关键字(key)来存储，而另一个存储器362将所述串的尾序列号+1作为关键字来存储。如图所示，CAM 360、362还存储串的长度。其他实现方式可以使用单个CAM或者可以使用其他数据存储技术。
潜在地，相同的CAM可被用来跟踪很多不同连接的分组。在这些情况中，可以将连接ID附加到每个CAM条目上，作为分辨用于不同连接的条目的关键字的一部分。合并CAM中的分组信息，这样就可以用更小的CAM实现对更多连接的处理。
如图15所示，所述实现方式包括存储起始序列号350、结束序列号352和数据长度354的寄存器。图4中所示的处理器212可以访问这些寄存器350、352和354，以将分组数据载入到跟踪子系统300。处理器212还可以请求下一预期序列号，以包括在被发回发送方的确认消息中。
如图所示，所述实现方式基于以下控制信号进行操作，这些控制信号包括用于从CAM360、362读的控制信号(CAMREAD)、用于写CAM 360、362条目的控制信号(CAMWRITE)和清除CAM 360、362条目的控制信号(CAMCLR)。如图15所示，硬件可被配置为当寄存器350、352和354载入数据时同时将寄存器值写入CAM 360、362。如图16所示，对于给定的起始序列号或末尾序列号的“命中(hit)”，电路将“seglen”寄存器设置为匹配CAM条目的长度。电路(未示出)还可以在成功的CAM 360、362读操作后设置“seqfirst”350寄存器和“seqlast”352寄存器的值。所述电路还可以提供一个“CamIndex”信号，该信号标识CAM 360、362中的特定“命中”条目。
子系统300可以具有用于实现上述过程的附加电路(未示出)。例如，子系统可以具有它自己的独立控制器或者数字逻辑门，它们执行实现跟踪方案的指令。可替换地，处理器212可以包括用于所述方案的指令。潜在地，处理器212指令集(图7)可被扩展为包括对正在重排序的CAM 360、362进行访问的命令。这样的指令可以包括向正在重排序的CAM 360、362写数据的指令(例如CAM2FirstWR key←data for CAM 310和CAM2LastWR key←data for CAM 312)；从CAM读数据的指令(例如，CAM2FirstRD key→data和CAM2LastRD key→data)；清除CAM条目的指令(例如CAM2CLR index)，和/或如果查找失败则生成条件值的指令(例如CAM2EMPTY→cond)。
再有，多种实现方式可以使用上述技术中的一种或多种。例如，时钟定标器126可被设计为向芯片、芯片组或主板内的组件提供时钟信号。此外，定标器106可被集成到诸如网络适配器、NIC(网卡)或MAC(媒体访问控制)设备的组件中。潜在地，这里所描述的技术还可以用在微处理器中。
可以使用多种硬件和/或软件配置来实现这里所描述的技术的各个方面。例如，可以用计算机程序来实现所述技术。这些程序可被存储在计算机可读介质上，并且包括用于编程处理器的指令。
其他实施方案也在所附权利要求的范围内。
权利要求
1.一种用在分组处理中的方法，所述方法包括接收至少一个分组的至少一部分；以及基于所述至少一个分组的所述至少一部分，确定提供给处理所述至少一个分组的处理逻辑的时钟信号。
2.如权利要求1所述的方法，其中，所述确定时钟信号的步骤包括基于包括在所述至少一个分组的头部中的数据来确定所述时钟信号。
3.如权利要求2所述的方法，其中，所述数据包括所述分组头部中的长度字段。
4.如权利要求1所述的方法，其中所述确定时钟信号的步骤包括基于分组和有效载荷中的至少一个的大小来确定所述时钟信号。
5.如权利要求4所述的方法，其中所述确定时钟信号的步骤包括作出确定，使得较大的大小对应于较高频率的时钟信号。
6.如权利要求4所述的方法，其中所述确定时钟信号的步骤包括访问针对不同组的一个或多个大小标识出不同时钟信号的数据。
7.如权利要求1所述的方法，其中所述确定时钟信号的步骤包括基于所述处理逻辑用来处理所述分组的处理周期的数量来确定时钟信号。
8.如权利要求1所述的方法，其中所述确定时钟信号的步骤包括至少基于以下指示符之一来作出确定服务质量的指示符和优先级的指示符。
9.如权利要求1所述的方法，还包括将与所确定的时钟信号相对应的选择信号馈给多路复用器。
10.如权利要求1所述的方法，还包括提供所确定的时钟信号。
11.如权利要求1所述的方法，还包括在以第一时钟频率来提供时钟的接口处接收所述至少一个分组的至少一部分；并且其中所述确定时钟信号的步骤包括确定不同于所述第一时钟频率的时钟信号。
12.如权利要求11所述的方法，其中所述第一时钟频率包括对应于每秒10吉比特连接的频率。
13.如权利要求11所述的方法，其中所确定的时钟信号的频率是所述第一时钟频率的整数倍。
14.如权利要求1所述的方法，其中所述处理逻辑包括网络协议去负载引擎。
15.如权利要求14所述的方法，其中所述网络协议去负载引擎包括算术逻辑单元以及存储算术逻辑单元指令的至少一个存储器。
16.一种位于计算机可读介质上的的计算机程序产品，所述计算机程序产品用在分组处理中，所述程序包括使得处理器完成以下步骤的指令接收至少一个分组的至少一部分；以及基于所述至少一个分组的所述至少一部分，确定提供给处理所述至少一个分组的处理逻辑的时钟信号。
17.如权利要求16所述的程序，其中使得所述处理器确定时钟信号的指令包括使得所述处理器基于包括在所述至少一个分组的头部中的数据来确定所述时钟信号的指令。
18.如权利要求17所述的程序，其中所述数据包括所述分组头部中的长度字段。
19.如权利要求16所述的程序，其中使得所述处理器确定时钟信号的指令包括使得所述处理器基于分组和有效载荷中的至少一个的大小来确定所述时钟信号的指令。
20.如权利要求19所述的程序，其中使得所述处理器确定时钟信号的指令包括使得所述处理器确定所述时钟信号，使得较大的大小对应于较高频率的时钟信号的指令。
21.如权利要求20所述的程序，其中使得所述处理器确定时钟信号的指令包括使得所述处理器访问针对不同组的一个或多个大小标识出不同时钟信号的数据的指令。
22.如权利要求16所述的程序，其中使得所述处理器确定时钟信号的指令包括使得所述处理器基于所述处理逻辑用来处理所述分组的处理周期的数量来确定时钟信号的指令。
23.如权利要求16所述的程序，其中使得所述处理器确定时钟信号的指令包括使得所述处理器至少基于以下指示符之一来确定所述时钟信号的指令，所述指示符包括服务质量的指示符和优先级的指示符。
24.如权利要求22所述的程序，其中使得所述处理器确定时钟信号的指令包括使得所述处理器确定一个与被提供给接收分组位的接口的时钟信号具有不同频率的时钟信号的指令。
25.如权利要求24所述的程序，其中所确定的时钟信号的频率是所述第一时钟信号频率的整数倍。
26.如权利要求16所述的程序，其中所述处理逻辑包括网络协议去负载引擎。
27.一种系统，包括接收至少一个分组的至少一部分的第一组数字逻辑；以及基于所述至少一个分组的所述至少一部分，确定提供给处理所述至少一个分组的处理逻辑的时钟信号的第二组数字逻辑。
28.如权利要求27所述的系统，其中确定时钟信号的所述第二组数字逻辑包括基于包括在分组头部中的数据来确定所述时钟信号的数字逻辑。
29.如权利要求28所述的系统，其中，所述数据包括所述分组头部中的长度字段。
30.如权利要求27所述的系统，其中确定时钟信号的所述第二组数字逻辑包括基于分组和有效载荷中的至少一个的大小来确定所述时钟信号的数字逻辑。
31.如权利要求30所述的系统，其中确定时钟信号的所述第二组数字逻辑包括确定所述时钟信号，使得较大的大小对应于较高频率的时钟信号的数字逻辑。
32.如权利要求27所述的系统，其中确定时钟信号的所述第二组数字逻辑包括访问针对不同组的一个或多个大小标识出不同时钟信号的数据的数字逻辑。
33.如权利要求27所述的系统，其中确定时钟信号的所述第二组数字逻辑包括基于所述处理逻辑用来处理所述分组的处理周期的数量来确定时钟信号的数字逻辑。
34.如权利要求27所述的系统，其中确定时钟信号的所述第二组数字逻辑包括至少基于以下指示符之一来确定所述时钟信号的数字逻辑，所述指示符包括服务质量的指示符和优先级的指示符。
35.如权利要求27所述的系统，所述第二组数字逻辑包括将与所确定的时钟信号相对应的选择信号馈给多路复用器的数字逻辑。
36.如权利要求27所述的系统，其中所述第二组数字逻辑还包括提供所确定的时钟信号的数字逻辑。
37.如权利要求27所述的系统，其中所述第二组数字逻辑包括访问针对分组特性标识出时钟信号频率的数据的逻辑。
38.如权利要求27所述的系统，还包括其中所述第一组数字逻辑以第一时钟频率来提供时钟；以及其中确定时钟信号的所述第二组数字逻辑包括确定不同于所述第一时钟频率的时钟信号的数字逻辑。
39.如权利要求38所述的系统，其中所述第一时钟频率包括对应于每秒10吉比特连接的频率。
40.如权利要求39所述的系统，其中所确定的时钟信号的频率是所述第一时钟频率的整数倍。
41.如权利要求27所述的系统，其中所述处理逻辑包括网络协议去负载引擎。
42.一种系统，包括至少一个主机处理器；以太网媒体访问控制(MAC)设备；至少一个TCP(传输控制协议)去负载引擎，该引擎接收由所述MAC设备接收到的分组的至少一部分，并且为所述至少一个主机处理所述分组，所述引擎经由外设部件互连(PCI)类型的总线耦合到所述主机；以及数字逻辑，该数字逻辑基于所述至少一个分组的所述至少一部分来确定提供给所述TCP去负载引擎的至少一部分的时钟信号。
43.如权利要求42所述的系统，其中所述至少一个主机包括本地通用中央处理单元(CPU)。
44.如权利要求42所述的系统，其中，确定时钟信号的所述数字逻辑包括基于包括在所述分组的因特网协议头部中的数据来确定所述时钟信号的数字逻辑。
45.如权利要求44所述的系统，其中所述数据包括所述因特网协议分组头部中的分组长度字段。
46.如权利要求42所述的系统，其中所述去负载引擎包括第一组一个或多个内容可寻址存储器和第二组一个或多个内容可寻址存储器，所述第一组存储器存储用于不同TCP连接的数据，所述第二组存储器存储用于乱序到达的TCP分组的数据。
47.如权利要求42所述的系统，其中所述数字逻辑包括幅度比较器，其被馈予代表至少一个分组的至少一种特性的数据；以及耦合到所述幅度比较器的多路复用器，该多路复用器被馈予一组具有不同频率的时钟信号，来自所述幅度比较器的信号选择由所述多路复用器输出的时钟信号。
全文摘要
总的来说，本公开在一个方面描述了一种用于分组处理中的方法。所述方法可以包括接收至少一个分组的至少一部分，基于所述至少一个分组的所述至少一部分来确定提供给处理所述至少一个分组的处理逻辑的时钟信号。
文档编号H04J3/06GK1695363SQ03824962
公开日2005年11月9日 申请日期2003年9月3日 优先权日2002年9月3日
发明者斯利拉姆·范加尔, 亚丁·霍斯科特, 尼丁·博卡, 许建平, 瓦姗莎·厄拉根特拉, 谢克哈·博卡 申请人:英特尔公司