CN100484136C - 网络协议引擎 - Google Patents
网络协议引擎 Download PDFInfo
- Publication number
- CN100484136C CN100484136C CNB2003101203664A CN200310120366A CN100484136C CN 100484136 C CN100484136 C CN 100484136C CN B2003101203664 A CNB2003101203664 A CN B2003101203664A CN 200310120366 A CN200310120366 A CN 200310120366A CN 100484136 C CN100484136 C CN 100484136C
- Authority
- CN
- China
- Prior art keywords
- frequency
- grouping
- tcp
- processor
- interface
- 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
- Communication Control (AREA)
Abstract
本发明公开的内容描述可由例如网络协议卸载引擎使用的分组处理技术。例如,这些技术可以用在针对所接收的分组为主机执行传输控制协议(TCP)操作的引擎中。
Description
技术领域
本发明涉及网络协议引擎。
背景技术
本申请涉及下述共同待审的申请:“基于分组的时钟信号(PACKET-BASED CLOCK SIGNAL)”、代理律师文档号42.P14951;以及“跟踪乱序的分组(TRACKING OUT-OF-ORDER PACKETS)”,代理律师文档号42.P14792。这些申请与本申请在同一天提交并指定相同的发明人姓名。
本申请中所包括的微代码指令,作者对这一材料保留适当的版权。
网络使计算机和其他电子设备能够交换数据,诸如电子邮件消息、网页、音频数据、视频数据等等。在通过网络进行传输之前,通常通过分组集合来分发数据。接收器在接收分组后,能将该数据重组到其原始形式。
除了正在发送中的数据(“有效载荷”)外,分组还包括“首部”信息。网络协议能定义在首部中存储的信息、分组结构以及过程应当如何处理分组。
不同的网络协议处理网络通信的不同方面。许多网络通信模型将这些协议组织成不同的层。例如,诸如,传输控制协议/网际协议(TCP/IP)模型和开放式软件协会(open software institute)(OSI)的模型定义如下层:“物理层”,用于处理在物理介质上的比特级别传输;“链路层”,用于处理在物理连接上提供可靠数据通信的低级别细节;“网络层”,诸如网际协议,用于处理在通过网络查找连接源和目的地的路径的过程中所涉及的任务;以及“传输层”,用于协调源和目的地设备间的通信,同时使“应用层”程序摆脱网络通信的复杂性。
在ATM网络中,使用不同的网络通信模型,异步传输模式(ATM)模型。ATM模型不仅定义物理层,而且还定义ATM和ATM适配层(AAL)层,来代替TCP/IP和OSI模型的网络、传输和应用层。
通常,为在网络上发送数据,为不同的通信层生成不同的首部。例如,在TCP/IP中,传输层过程通过将传输层首部添加到由应用提供的一组数据上来生成传输层分组(有时称为“段”);然后,网络层过程通过将网络层首部添加到传输层分组上来生成网络层分组(例如,IP分组);然后,链路层过程通过将链路层首部增加到网络分组上来生成链路层分组(也称为“帧”)。这一过程称为封装。用类推法,封装过程非常像将一系列信封在相互之间填塞
在分组行进通过网络后,接收器能拆封分组(例如,“拆开”信封)。例如,接收器的链路层过程可以验证所接收的帧,并将内封的网络层分组传递给网络层过程。网络层过程能使用网络首部来验证分组的正确传递并将内封的传输段传递给传输层过程。最后,传输层过程能根据传输首部处理传输分组,并将结果数据传递给应用。
如上所述,发送器和接收器均要进行相当多的处理以便处理分组。另外,网络连接速度持续快速增长。例如,能每秒传送10千兆比特、甚至更快的网络连接,可能不久就变得很平常。网络连接速度的这一增加给提供这种连接的设备提出了重要的设计问题。即,以这种速度,设备就非常可能无法应对迅猛增长的网络通信量。
附图说明
图1是网络协议引擎的框图。
图2是网络协议引擎的示意图。
图3是网络协议引擎的处理器的示意图。
图4是用于编程网络协议操作的指令集的图。
图5是TCP(传输控制协议)状态机的图。
图6-10示例说明跟踪乱序分组的方案的操作。
图11是跟踪乱序分组的过程的流程图。
图12-13是用于跟踪乱序且包括内容可寻址存储器的系统的示意图。
图14是具有不同时钟信号的特征的网络协议引擎的图。
图15是具有根据一个或多个分组特征使时钟信号特征化的网络协议引擎的图。
图16是用于根据一个或多个分组特征提供时钟信号的机制的图。
具体实施方式
许多计算机系统和其他主机设备具有用于处理各种任务的处理器(例如通用中央处理单元(CPU))的特征。通常这些处理器具有处理网络通信量的额外的责任。网络通信量和连接速度的增加已经对主处理器资源提出了更高的要求。为至少部分地降低主处理器上的网络通信负担,图1描述能为主机执行网络协议操作的网络协议“卸载”引擎106的例子。系统106能执行对应各种协议的操作。例如,能将系统配置成执行对应传输层协议(例如TCP和用户数据报协议(UDP))、网络层协议(例如IP)以及应用层协议(例如套接字编程)的操作。类似地,在ATM网络中,能将系统106配置成提供针对ATM分组(也称为“信元”)的ATM层或AAL层操作。能将该系统配置成提供其他协议操作,诸如与网际控制报文协议(ICMP)相关联的那些协议操作。
除通过处理协议操作节约主处理器资源外,系统106可以提供“线速”处理,即使对于非常快的连接,诸如每秒10千兆比特和每秒40千兆比特的连接也可以提供“线速”处理。换句话说,系统106通常可以在另一个分组到达之前完成一个分组的处理。通过跟上高速连接,系统106能潜在地避免或降低与排队大量积压的分组相关联的成本和复杂性。
所示的示例系统]06包括用于接收在一个或多个主机和网络102之间穿行的数据的接口108。对出去的数据,系统106接口108例如经提供网络连接(例如,以太网或无线连接)媒体访问控制(MAC)设备和PHY(未示出),从主机接收数据并生成用于网络传输的分组。对所接收的分组(例如经PHY和MAC接收的分组),系统106接口108能将分组处理结果递送到主机。例如,系统106可以经小型计算机系统接口(SCSI)或外围部件互连(PCI)型总线(例如PCI-X总线系统)与主机通信。
除接口108外,系统106还包括用于实现协议操作的处理逻辑110。与接口108一样,可以使用各种技术设计逻辑110。例如,可以将系统106设计成硬布线ASIC(专用集成电路)、FPGA(现场可编程门阵列)和或数字逻辑门的另一组合。
如所示,逻辑110也可以由系统106来实现,系统106包括处理器122(例如微控制器或微处理器)和用于处理器122能执行来实现网络协议操作的指令的RAM(随机访问存储器))或存储器126(例如ROM(只读存储器)。基于指令的系统106提供高度灵活性。例如,当网络协议经历改变或被替换时,能够通过替换指令而不是替换系统106本身来更新系统106。例如,主机可以通过如下方式来更新系统106,所述方式是:例如当主机启动时,将指令从母板上的外部闪速存储器或ROM中加载到存储器126。
尽管图1描述了为主机执行操作的单一系统106,但是也可以使用多个卸载引擎106来为主机处理网络操作,以便提供处理日益增加的通信量的可伸缩方法。例如,系统可以包括引擎106和用于将连接分配到不同的引擎106的逻辑的集合。为节约功率,可以执行这种分配来降低在指定时间有效支持进行中的连接的引擎106的数量。
图2是系统106的样例实施例。总体来看,在这一实施例中,系统106将对应不同连接的上下文数据(context data)存储在存储器112中。例如,对于TCP协议而言,这一数据被称为TCB(传输控制块)数据。对指定的分组,系统106在这一例子中经工作寄存器118查找存储器112中的对应的连接上下文并使这一数据可用于处理器122。使用上下文数据,处理器122执行一组相应的协议实现指令126。上下文数据,潜在地被处理器122加以修改,然后被返回给上下文存储器112。
更详细地说,所示的系统106包括用于解析所接收的分组首部(例如TCP/IP分组的TCP和IP首部)并暂时缓冲所解析的数据的输入序列发生器116。输入序列发生器116也可以启动将分组的有效载荷存储在主机可访问的存储器(例如经DMA(直接存储器访问))中。如下所述,输入序列发生器116可以以对应于网络连接的速度的速率被同步。
如上所述,系统106存储对应不同网络连接的上下文数据112。为了快速地从存储器112检索对应指定分组的上下文数据,所述的系统106包括内容可寻址存储器114(CAM),用于存储对应例如按分组的IP源和目的地地址以及源和目的地端口所标识的不同连接的不同连接标识符(例如索引号)。CAM能以比数据库根据关键字检索记录更快的方式根据内容值来快速检索所存储的数据。因此,根据由输入序列发生器116解析的分组数据,CAM114能快速检索连接标识符并将这一标识符馈送到上下文数据存储器112。接着,将对应于该标识符的连接上下文数据从存储器112传送到工作寄存器118,以供处理器122使用。
在分组表示新连接开始(例如CAM114搜索连接失败)的情况下,初始化工作寄存器118(例如,在TCP中设置成“侦听”态),以及例如使用LRU(最近最少使用)算法或其他分配方案,为该连接分配CAM114和上下文数据112条目。
可以选择连接系统106的不同部件的数据线的数量,以允许在单个时钟周期中在所连接的部件112-128之间传送数据。例如,如果对应连接的上下文数据包括n位数据,则可将系统106设计成连接数据存储器112可以向工作寄存器118提供n条数据线。
因此,所示的实施例至多使用三个处理周期来通过连接数据加载工作寄存器118:一个周期用来查询CAM114;一个周期用来访问连接数据112;以及一个周期用来加载该工作寄存器118。这一设计不仅能节约处理时间而且能节约在访问存储器结构112、114上的功耗。
在为分组检索连接数据后,系统106能通过如下方式来为该分组执行协议操作,所述方式例如是:处理器122执行在存储器126中存储的协议实现指令。当不使用时,为了节省功率,可以将处理器122编程为“空闲”。在接收(例如,当检索到或正检索连接上下文时来自输入序列发生器116的)“唤醒”信号之后,处理器112可以确定当前连接的状态,并标识指令的起始地址以便处理这一状态。然后,处理器122执行以该起始地址开始的指令。根据这些指令,处理器122能够(例如,通过修改工作寄存器118)修改上下文数据,将消息装配到发送缓冲器128中,以便后续地进行网络传输,和/或可使已经处理过的分组数据可用于主机(未示出)。再次,上下文数据,潜在地由处理器122加以修改,被返回到上下文数据存储器112中。
图3更详细地描述处理器122。如所示,处理器122可以包括ALU(算术逻辑单元)132,用于译码和执行已被加载到指令寄存器134中的微代码指令。指令126可以被从存储器126以顺序连续性的方式加载136到指令寄存器134中,除了转移指令和开始地址初始化以外。指令126可以指定对存储所解析的分组数据的接收缓冲器130、工作寄存器118、发送缓冲器128和/或主存储器(未示出)的访问(例如读或写访问)。这些指令也可以指定对暂时存储器、混杂寄存器(例如寄存器dubbed R0、cond、statusok)、移位寄存器等等(未示出)的访问。为方便编程,可对发送缓冲器128和工作寄存器118的不同字段分配供指令使用的标记。另外,例如可以为不同连接状态定义各种常数。例如,“加载TCB[状态]、侦听”指示处理器122将工作寄存器118中的连接上下文状态的状态改变成“侦听”状态。
图4描述可被用来编程处理器以执行协议操作的微代码指令集的例子。如所示,指令集包括如下操作:在系统内移动数据(例如,LOAD和MOV)、执行算术和布尔运算(例如AND、OR、NOT、ADD、SUB)、比较数据(例如CMP和EQUAL)、操纵数据(例如SHL(向左移位)以及提供在程序内的转移(例如BREQZ(如果在前操作的结果等于0,则条件性转移)、BRNEQZ(如果在前操作的结果不等于0,则条件性转移)以及JMP(无条件跳转))。
指令集还包括特别适合于用在通过系统106资源实现协议操作的操作。这些指令包括用于清除CAM114用于连接的条目(例如,CAM1CLR)和用于将上下文数据保存到上下文数据存储器112中(例如TCBWR)的操作。其他实现也可以包括读取并将标识符信息写到存储与连接相关联的数据的CAM114中的指令(例如,CAM1READ key-->index和CAM1WRITE key-->index)和读取上下文数据112的指令(例如,TCBRD index-->destination)。另外,这些指令可实现为硬布线逻辑。
尽管可能缺少由传统的通用CPU提供的许多指令(例如处理器122可以不具有用于浮点运算的指令的特征),但是该指令集为开发者提供了便于访问适合于网络协议实现的系统106资源。程序员可以使用微代码指令来直接编程协议操作。另外,程序员可使用各种代码开发工具(例如编译器或汇编器)。
如上所述,系统106指令能实现用于各种网络协议的操作。例如,系统106可以实现用于传输层协议诸如TCP的操作。能在RFC(征求意见文件)793、1122和1323中找到TCP和可选扩展的完整说明。
简单地说,TCP向应用提供面向连接的服务。即,非常像收听电话和假定电话公司将使一切工作一样,TCP为应用提供用于建立连接(例如CONNECT和CLOSE)和传送数据(例如,SEND和RECEIVE)的简单的原语。TCP透明地处理诸如数据重传、拥塞和流量控制的通信问题。
为向应用程序提供这些服务,TCP对称为段的分组进行操作。TCP段包括了跟随着一个或多个数据字节的TCP首部。接收器能从所接收的段重新装配数据。如果段完全可以到达的话,则段可能不以它们的正确次序到达它们的目的地。例如,不同段可以穿过网络上的非常不同的路径。因此,TCP为传送的每个数据字节分配序号。由于对每个字节排序,所以能确认每个字节以便肯定成功传送。确认机制是累积的,从而使得特定序号的确认表示已经成功地递送达到那个序号的字节。
排序方案为TCP提供用于管理连接的强大的工具。例如,TCP能使用称为“滑动窗口”的技术来确定发送器应当何时重传一个段。在“滑动窗口”方案中,发送器在传送一个段后启动定时器。在接收后,接收器向回发送具有等于接收器期望接收的下一序号的确认号的确认段。如果在所传送的字节的确认到达之前,发送器的定时器时间已到,则发送器再次发送该段。定序方案也使发送器和接收器能够根据网络性能和发送器和接收器的容量,动态地协商用于调整发送给接收器的数据量的窗口大小。
除排序信息外,TCP首部还包括使发送器和接收器能够控制一个连接的标志的集合。这些标志包括SYN(同步)位、ACK(确认)位、FIN(完成)位、RST(复位)位。包括SYN位“1”和SCK位“0”的消息(SYN消息)表示连接请求。包括SYN位“1”和ACK位“1”的应答消息(SYN+ACK消息)表示接受请求。包括FIN位“1”的消息表示发送器试图释放该连接。最后,具有RST位“1”的消息表示由于出现问题(例如无效段或连接请求拒绝),而应当终止连接。
图5描述表示在建立和断开TCP连接中的不同状态的状态图。该图描述不同状态140和160和这些状态140-160间的变迁(用箭头线表示)。用标识移动到后续状态140-160所需的事件和动作的相应的事件/动作的标示来标记这些变迁。例如,在接收SYN消息和用SYN+ACK消息应答后,连接从侦听状态142变迁到SYN RCVD状态144。
在图5的状态图中,用实线变迁表示用于发送器(请求连接的TCP实体)的典型路径,而用虚线变迁表示用于接收器的典型路径。为示例说明状态机的操作,接收器通常以表示目前没有活动或挂起的连接的已关闭状态140开始。在移向侦听142状态以等待连接请求后,接收器将接收请求连接的SYN消息和将用SYN+ACK消息确认SYN消息并进入SYN RCVD状态144。在接收SYN+ACK消息的确认后,连接进入对应于正常进行中的数据传送的已建立状态148。已建立状态148将持续一些时间。最后,假定没有复位消息到达和没有错误发生,则服务器将接收和确认FIN消息并进入关闭等待状态150。在发出它自己的FIN和进入最后的确认状态160后,服务器将接收它的FIN的确认和最后返回到最初的已关闭140状态。
而且,状态图还管理TCP发送器的状态。发送器和接收器路径共享许多如上所述的相同的状态。然而,发送器在请求连接后,还可以进入SYN发出状态146,在请求释放连接后,进入FIN等待1状态152,在接收来自接收器的用于释放连接的许可后,进入FIN WAIT2状态156,在发送器和接收器同时请求释放时进入关闭中状态154以及在先前发送的连接段到期时进入定时等待状态158。
系统106的协议指令可以实现如上所述和RFC中的许多TCP操作,即使不是全部。例如,指令可包括用于选择处理、窗口管理、流量控制、拥塞控制、ACK消息生成和验证、数据分段、专用标志处理(例如设置和读取URGENT和PUSH标志)、校验和计算等等的过程。协议指令也可以包括与TCP有关的其他操作,诸如安全性支持、随机数生成、TCP上的RDMA(远程直接存储器访问)等等。
在配置成提供TCP操作的系统106中,上下文数据可以包括每个连接的264位信息,包括:对于如下的各项均是32位,用于PUSH(由微代码标记“TCB[pushseq]”标识)、FIN(“TCB[finseq]”)和URGENT(“TCB[rupseq]”)序号、下一期望的段号(“TCB[rnext]”)、用于当前通知窗口(“TCB[cwin]”)的序号、最后一个未确认的序号(“TCB[suna]”)的序号,以及用于将作为下一个的下一段(“TCB[snext]”)的序号。其余位存储各种TCB状态标志(“TCB[flags]”)、TCP段代码(“TCB[code]”)、状态(“TCB[tcbstate]”)和错误标记(“TCB[error]”)。
为示例说明用于配置成执行TCP操作的系统106的编程,代码段A公开了用于TCP接收器的源微代码的例子。
代码段A
END: TCBWRindex
IDLE: JMP IDLE
LBLLISTEN: SUB rcv[len],HEADERLEN-->seglen
AND rcv[code],RST-->cond
BRNEQZ IDLE
AND rcv[code],ACK-->cond
BRNEQZ TCPRST
AND rcv[code],SYN-->cond
BRNEQZ TCPINITWIN
JMP TCPRST
LBLLISTEN1: LOAD wkreg[state]<--SYNRCVD
JMP END
LBLSYNRCVD: JMPTCPSEQOK
LBLSYNRCVD1: AND rcv[code],ACK-->cond
BREQZ IDLE
CMP wkreg[suna],rcv[ack]-->cond
BRNEQZ TCPRST
CMP rcv[ack],wkreg[snext]-->cond
BRNEQZ TCPRST
ADD wkreg[suna],1-->wkreg[suna]
JMP TCPDATAPROC
LBLSYNRCVD4: AND wkreg[flags],RDONE-->R0
EQUAL R0,0-->cond
BRNEQZ LBLSYNRCVD5
LOAD wkreg[state]<--CLOSEWAIT
JMP END
LBLSYNRCVD5: LOAD wkreg[state]<--ESTABLISHED
JMP END
LBLESTABLISHED: JMP TCPSEQOK
LBLESTABLISHED4: CMP wkreg[rbcount],75RBSIZE-->cond
BREQZ LBLESTABLISHED5
LOAD wkreg[rbcount]<--0
LBLESTABLISHED5:AND wkreg[flags],RDONE-->R0
EQUAL R0,0-->cond
BRNEQZ END
LOAD wkreg[state]<--CLOSEWAIT
JMP END
LBLCLOSEWAIT: JMP TCPSEQOK
LBLLASTACK: JMP TCPSEQOK
LBLLASTACK2: AND rcv[code],ACK-->con
BREQZ END
CMP wkreg[suna],rcv[ack]-->cond
BRNEQZ END
CMP rcv[ack],wkreg[snext]-->cond
BRNEQZ END
JMP TCBDEALLOCATE
TCPRST: LOAD snd[window]<--0
AND rcv[code],SYN-->cond
BREQZ LBL02
ADD seglen,1-->seglen
LBL02: AND rcv[code],FIN-->cond
BREQZ LBL03
ADD seglen,1-->seglen
LBL03: AND rcv[code],ACK-->cond
BRNEQZ LBL00
LOAD snd[seq]<--0
LOAD snd[code]<--RST|ACK
JMP LBL01
LBL00: MOV rcv[ack]-->snd[seq]
LOAD snd[code]<--RST
LBL01: ADD rcv[seq],seglen-->snd[ack]
EQUAL wkreg[state],LISTEN-->cond
BRNEQZ IDLE
EQUAL wkreg[state],SYNRCVD-->cond
BREQZ TCBDEALLOCATE
AND rcv[code],SYN-->cond
BRNEQZ TCBDEALLOCATE
JMP IDLE
TCBDEALLOCATE: CAM1CLR index
JMP IDLE
TCPINITWIN: LOAD wkreg[code]<--SYN
MOV rcv[window]-->wkreg[swindow]
MOV rcv[seq]-->wkreg[lwseq]
MOV rcv[seq]-->wkreg[rnext]
ADD rcv[seq],RBSIZE-->wkreg[cwin]
JMP TCPDATAPROC
TCPSENDWIN: CMP wkreg[lwseq],rcv[seq]-->cond
BRNEQZ LBL11
EQUAL rcv[seq],wkreg[lwseq]-->cond
BREQZ LBL10
CMP wkreg[lwack],rcv[ack]-->cond
BRNEQZ LBL11
LBL10: MOV rcv[window]-->wkreg[swindow]
MOV rcv[seq]-->wkreg[lwseq]
MOV rcv[ack]-->wkreg[lwack]
LBL11: EQUAL wkreg[state],ESTABLISHED-->cond
BRNEQZ LBLESTABLISHED4
OR wkreg[flags],SNDFIN-->wkreg[flags]
JMP TCPACK
TCPSEQOK: LOAD statusok<--0
SUB rcv[len],HEADERLEN-->seglen
AND rcv[code],SYN-->cond
BREQZ LBL20
ADD seglen,1-->seglen
LBL20: AND rcv[code],FIN-->cond
BREQZ LBL21
ADD seglen,1-->seglen
LBL21: SUB RBSIZE,wkreg[rbcount]-->rwindow
EQUAL rwindow,0-->cond
BREQZ LBL22
EQUAL seglen,0-->cond
BREQZ LBL22
EQUAL wkreg[rnext],rcv[seq]-->cond
BREQZ LBL25
LOAD statusok<--1
JMP LBL25
LBL22: EQUAL rwindow,0-->cond
BRNEQZ LBL25
ADD wkreg[rnext],rwindow-->seqwin
ADD rcv[seq],seglen-->seqlast
EQUAL seglen,0-->cond
BRNEQZ LBL23
CMP seqlast,wkreg[rnex t]-->cond
MOV cond-->statusok
CMP seqlast,seqwin-->cond
NOT cond-->cond
AND cond,statusok-->statusok
LBL23: CMP wkreg[rnext],rcv[seq]-->cond
BRNEQZ LBL25
CMP seqwin,rcv[seq]-->cond
OR statusok,cond-->statusok
LBL25: AND rcv[code],SYN-->cond
BREQZ LBL26
SUB seglen,1-->seglen
LBL26: AND rcv[code],FIN-->cond
BREQZ LBL27
SUB seglen,1-->seglen
LBL27: EQUAL statusok,0-->cond
BRNEQZ TCPACKOUT
AND rcv[code],RST-->cond
BRNEQZ TCBDEALLOCATE
AND rcv[code],SYN-->cond
BRNEQZ TCPRST
EQUAL wkreg[state],SYNRCVD-->cond
BRNEQZ LBLSYNRCVD1
JMP TCPACKIN
TCPACKOUT: CMP seglen,0-->cond
BRNEQZ LBL30
AND rcv[code],SYN|FIN-->cond
BREQZ IDLE
LBL30: LOAD snd[code]<--ACK
MOV wkreg[snext]-->snd[seq]
MOV wkreg[rnext]-->snd[ack]
SUB RBSIZE,wkreg[rbcount]-->rwindow
CMP wkreg[state],SYNRCVD-->cond
BREQZ LBL35
SHL2 rwindow-->R0
CMP RBSIZE,R0-->cond
BRNEQZ LBL32
CMP RMSS,rwindow-->cond
BREQZ LBL33
LBL32: LOAD rwindow<--0
LBL33: CMP wkreg[cwin],wkreg[rnext]-->cond
BREQZ LBL34
SUB wkreg[cwin],wkreg[rnext]-->R0
CMP rwindow,R0-->cond
BRNEQZ LBL34
MOV R0-->rwindow
LBL34: ADD wkreg[rnext],rwindow-->wkreg[cwin]
LBL35: MOV rwindow-->snd[window]
JMP END
TCPACK: AND wkreg[flags],SNDFIN-->R0
EQUAL R0,0-->cond
BRNEQZ LBL60
OR wkreg[code],FIN-->wkreg[code]
LBL60: OR wkreg[code],ACK-->snd[code]
AND wkreg[flags],~NEEDOUT-->wkreg[flags]
MOV wkreg[snext]-->snd[seq]
AND wkreg[code],SYN|FIN-->cond
BREQZ LBL61
ADD wkreg[snext],1-->wkreg[snext]
LBL61: MOV wkreg[rnext]-->snd[ack]
SUB RBSIZE,wkreg[rbcount]-->rwindow
CMP wkreg[state],SYNRCVD-->cond
BREQZ LBL65
SHL2rwindow-->R0
CMP RBSIZE,R0-->cond
BRNEQZ LBL62
CMP RMSS,rwindow-->cond
BREQZ LBL63
LBL62: LOAD rwindow<--0
LBL63: SUB wkreg[cwin],wkreg[rnext]-->R0
CMP rwindow,R0-->cond
BRNEQZ LBL64
MOV R0-->rwindow
LBL64: ADD wkreg[rnext],rwindow-->wkreg[cwin]
LBL65: MOV rwindow-->snd[window]
AND wkreg[code],0-->wkreg[code]
EQUAL wkreg[state],LISTEN-->cond
BRNEQZ LBLLISTEN1
EQUAL wkreg[state],SYNRCVD-->cond
BRNEQZ LBLSYNRCVD4
EQUAL wkreg[state],ESTABLISHED-->cond
BRNEQZ TCPSENDWIN
EQUAL wkreg[state],CLOSEWAIT-->cond
BREQZ END
LOAD wkreg[state]<--LASTACK
JMP END
TCPACKIN: AND rcv[code],ACK-->cond
BREQZ LBLA1
CMP rcv[ack],wkreg[suna]-->cond
BREQZ IDLE
CMPrcv[ack],wkreg[snext]-->cond
BRNEQZ TCPACKOUT
MOV rcv[ack]-->wkreg[suna]
AND wkreg[code],SYN-->cond
BREQZ LBL40
AND wkreg[code],~SYN-->wkreg[code]
AND wkreg[flags],~FIRSTSEND-->wkreg[flags]
LBL40: AND wkreg[code],FIN-->cond
BREQZ LBL41
EQUAL wkreg[snext],rcv[ack]-->cond
BREQZ LBL41
AND wkreg[code],~FIN-->wkreg[code]
AND wkreg[flags],~SNDFIN-->wkreg[flags]
LBL41: EQUAL wkreg[state],CLOSEWAIT-->cond
BRNEQZ TCPSENDWIN
EQUAL wkreg[state],ESTABLISHED-->cond
BRNEQZ TCPDATAPROC
EQUAL wkreg[state],LASTACK-->cond
BRNEQZ LBLLASTACK2
JMP END
TCPDATAPROC: MOV rcv[code]-->statusok
MOV rcv[seq]-->seqfirst
AND statusok,URG-->cond
BREQZ LBL51
ADD seqfirst,rcv[urgptr]-->R0
AND wkreg[flags],RUPOK-->rwindow
EQUAL rwindow,0-->cond
BRNEQZ LBL50
CMP R0,wkreg[rupseq]-->cond
BREQZ LBL51
LBL50: MOV R0-->wkreg[rupseq]
OR wkreg[flags],RUPOK-->wkreg[flags]
LBL51: AND statusok,SYN-->cond
BREQZ LBL52
ADD wkreg[rnext],1-->wkreg[rnext]
OR wkreg[flags],NEEDOUT-->wkreg[flags]
ADD seqfirst,1-->seqfirst
LBL52: SUB RBSIZE,wkreg[rbcount]-->rwindow
ADD wkreg[rnext],rwindow-->seqwin
ADD seqfirst,seglen-->seqlast
CMP wkreg[rnext],seqfirst-->cond
BREQZ LBL53
SUB wkreg[rnext],seqfirst-->R0
SUB seglen,R0-->seglen
MOV wkreg[rnext]-->seqfirst
LBL53: CMP seqlast,seqwin-->cond
BREQZ LBL54
SUB seqlast,seqwin-->R0
SUB seglen,R0-->seglen
AND statusok,~FIN-->statusok
LBL54: EQUAL seqfirst,wkreg[rnext]-->cond
BREQZ LBL55
CMP seglen,0-->cond
BREQZ LBL56
ADD wkreg[rnext],seglen-->wkreg[rnext]
ADD wkreg[rbcount],seglen-->wkreg[rbcount]
LBL512: CAM2EMPTY cond
BRNEQZ LBL511
CAM2LLKUP seqlast
BREQZ LBL511
CAM2CLR[cam2_idx]
ADD wkreg[rnext],seglen-->wkreg[rnext]
ADD wkreg[rbcount],seglen-->wkreg[rbcount]
LBL511: EQUAL wkreg[finseq],wkreg[rnext]-->cond
BRNEQZ ALLDONE
CMP wkreg[pushseq],wkreg[rnext]-->cond
BRNEQZ NEXT
OR statusok,PSH-->statusok
LOAD wkreg[pushseq]<--0
JMP NEXT
ALLDONE: OR statusok,FIN-->statusok
NEXT: OR wkreg[flags],NEEDOUT-->wkreg[flags]
LBL56: AND statusok,FIN-->cond
BREQZ LBL58
OR wkreg[flags],RDONE|NEEDOUT-->wkreg[flags]
ADD wkreg[rnext],1-->wkreg[rnex t]
LBL58: AND statusok,PSH|URG-->cond
BREQZ NEXTP1
OR wkreg[flags],PUSH-->wkreg[flags]
JMP NEXTP1
LBL55: AND statusok,FIN-->cond
BREQZ LBL59
ADD seqfirst,seglen-->wkreg[finseq]
LBL59: AND statusok,PSH|URG-->cond
BREQZ LBL510
ADD seqfirst,seglen-->wkreg[pushseq]
LBL510: AND statusok,~(FIN|PSH)-->statusok
CAM2LLKUP seqlast
BREQZ LBL515
CAM2CLR[cam2_idx]
ADD seqlast,seglen-->seqlast
SUB seqlast,seqfirst-->seglen
LBL515: CAM2RLKUP seqfirst
BREQZ LBL516
CAM2CLR[cam2_idx]
SUB seqfirst,seglen-->seqfirst
SUB seqlast,seqfirst-->seglen
LBL516: CAM2WR seglen
OR wkreg[flags],NEEDOUT->wkreg[flags]
NEXTP1: AND wkreg[flags],NEEDOUT-->R0
EQUAL R0,0-->cond
BREQZ TCPACK
EQUAL wkreg[state],LISTEN-->cond
BRNEQZ LBLLISTEN1
EQUAL wkreg[state],SYNRCVD-->cond
BRNEQZ LBLSYNRCVD4
EQUAL wkreg[state],ESTABLISHED-->cond
BRNEQZ TCPSENDWIN
JMP END
简单地说,例程TCPRST检查TCP ACK位,初始化发送缓冲器,并初始化发送消息的ACK号。例程TCPACKIN处理输入的ACK消息并检查ACK是无效还是复本。TCPACKOUT响应一个输入消息,根据所接收和所期望的序号,生成ACK消息。TCPSEQ确定输入数据的第一和最后一个序号,计算输入数据的大小并检查输入序号是否有效以及是否处于接收窗口中。TCPINITCB初始化在工作寄存器中的TCB字段。TCPINITWIN用窗口信息初始化工作寄存器。TCPSENDWIN计算要包括在发送消息中的窗口长度。最后,TCBDATAPROC检查输入标记,处理“UGENT”、“PUSH”和“FINISH”标志,响应消息设置标志以及将数据转发给应用或用户。
由系统106执行的另一操作可以是分组重定序。例如,与许多网络协议一样,TCP假定TCP分组(“段”)将不按照次序到达。为正确地重组分组,一个接收器能跟踪所接收的最后一个序号并等待接收被指定给下一序号的字节。能够缓冲乱序到达的分组,直到干预字节到达为止。只要所等待的字节到达,就能够从缓冲的数据快速检索出序列中的接着的字节。
图6-10示例说明能够由系统106实现的跟踪乱序分组的方案的操作。该方案允许分组的快速“实时”定序,而不采用传统的排序算法。该方案可以使用另一组内容可寻址存储器510、512来实现,不过这是不要求的。因此,使用这一技术的系统106可以包括两个不同组的内容可寻址存储器—用来检索连接上下文数据的内容可寻址存储器114和用来跟踪乱序分组的内容可寻址存储器。
为了说明的目的,在实现TCP的情况下讨论图6-10。然而,该方案可广泛地适合于各种分组重定序方案,诸如编号的分组(例如协议数据单位段)。因此,虽然下述的说明讨论TCP序号的存储,但是用于编号的分组的实施例也能替代地存储分组号。
简单地说,当分组到达时,分组跟踪子系统确定所接收的分组是否是按次序的。如果不是,子系统参考存储器来标识以最新到达的分组为边界的先前接收的乱序分组的邻近组,并能修改在存储器中存储的数据,以便将该分组添加到所述组中。当分组按序到达时,子系统能够访问存储器以便快速地标识在最新接收的分组后的在前接收的分组的一个邻近链。
更详细地说,如图6所示,协议504(例如TCP)将一组数据502划分成用于在网络508上传输的分组506a-506d的集合。在所示的例子中,15字节的原始数据组502分布在分组506a-506d上。例如,分组506d包括指定序号“1”至“3”的字节。
如所示,跟踪子系统500包括存储有关所接收的乱序分组的信息的内容可寻址存储器510、512。存储器510存储一个或多个乱序分组的邻近链的第一序号和该链的长度。因此,当新分组到达预先存在的链开始的那个终点时,能将该新分组添加到预先存在的链的顶部。类似地,存储器512也存储一个或多个分组的邻近分组链的尾部(最后一个序号+1)和该链的长度。因此,当新分组到达在先前存在的链的尾部的那个起始点时,将该新分组追加到先前存在的链的尾部,以形成更大的邻近分组链。为示例说明这些操作,图7-10描述当分组506a-506d到达时发生的一系列示例操作。
如图7所示,分组506b携带具有序号“8”至“12”的字节到达。假定子系统500目前等待序号“1”,分组506b已经乱序到达。因此,如所示,设备500通过修改在其内容可寻址存储器510、512中存储的数据来跟踪乱序分组506b。分组506b不以先前所接收的分组链作为边界,因为在这一例子中还没有链存在。因此,子系统500存储起始序号“8”,和分组中的字节数“4”。子系统500还存储分组的尾部的标识。在所示的例子中,设备500通过将所接收的分组的最后一个序号加1(例如,12+1=13)来存储结尾边界。除修改或添加内容可寻址存储器510、512中的条目外,设备500能存储分组511b或分组511b的引用(例如指针)来反映分组的相对次序。这允许当将分组最后发送给应用时,快速检索分组。
如图8所示,子系统500接着接收带有字节“13”至“15”的分组506a。同样,子系统500仍然等待序号“1”。因此,分组506a也是乱序到达。子系统500检查存储器510、512,以便确定所接收的分组506a是否邻近任何在前存储的分组链。在这种情况下,该新到达的分组506a不在先前链开始的地方结尾,但却开始于先前链结尾的地方。换句话说,分组506a与分组506b的“底部”邻近。如所示,设备500通过增加链的长度和由此修改它的第一和最后一个序号数据,将分组506a合并到内容可寻址存储器数据的先前存在的链中。因此,新链的第一序号仍然保持为“8”,不过长度从“4”增加到“7”,而该链的尾部序号从“13”增加到“16”,以反映新接收的分组506a的字节。设备500还存储新的分组511a,或该新分组的引用以反映该分组的相对次序。
如图9所示,设备500接着接收带有字节“4”至“7”的分组506c。由于这一分组506c不包括下一个所期望的序号“1”,所以设备500重复如上所述的过程。即,设备500确定新接收的分组506c在跨越分组506b、506a的分组链的“顶部”。因此,设备500修改存储在内容可寻址存储器数据510、512中的数据以便包括用于该链的新起始序号“4”,以及用于该链的新长度数据“11”。设备500再次存储分组511c数据的引用来反映分组511c的相对次序。
如图10所示,设备500最后接收包括下一所期望的序号“1”的分组506d。设备500能立即将这一分组506d传送给应用。设备500也能检查它的内容可寻址存储器510,以查看是否还能将其他分组发送给应用。在这种情况下,所接收的分组506d与已经跨越分组506a-506c的分组链相邻。因此,设备500能立即将链状分组的数据以正确的次序转发给应用。
如图7-10所示的示例序列突出该方案的几个方面。第一,该方案能防止乱序分组被发送器丢下和重传。这能提高整体吞吐量。该方案还使用非常少的内容可寻址存储器操作来处理乱序分组,节约时间和功率。另外,当分组以正确次序到达时,单个内容可寻址存储器操作能识别还能发送给应用的一系列邻近分组。
图11描述用于实现如上所述的方案的过程520的流程图。如所示,在接收522分组后,过程520确定524分组是否是按次序(例如,分组是否包括下一所期望的序号)。如果不是,过程520确定532所接收的分组的尾部是否与现有的分组链的起始邻近。如果是,过程52能修改534存储在内容可寻址存储器中的数据,以反映以所接收的分组开始和以在前现有的分组链的尾部结束的更大的、合并的分组链。过程520还确定536所接收的分组的起始是否在现有的分组链的尾部。如果是,过程520能修改538存储在内容可寻址存储器中的数据以反映以所接收的分组结束的更大的、合并的分组链。
潜在地,所接收的分组可以将预先存在的分组链的两端作为边界。换句话说,新接收的分组填充两个之链间的空白处。由于过程520检查所接收的分组的起始532和尾部536的边界,新接收的分组可以使过程520将两个不同的链结合在一起以形成单个整体链。
如所示,如果所接收的分组不与一个分组链相邻,过程520将数据存储540在至少初始地仅包括所接收的分组的新分组链的内容可寻址存储器中。
如果所接收的分组是按次序的,过程520能查询526内容可寻址存储器以便识别在所接收的分组后的相邻分组链。如果存在这样的一个链,过程520能将新接收的分组连同邻近的分组链中的其他分组数据输出到应用。
这一过程可以使用各种硬件、固件和/或软件来实现。例如,图12和13描述以上所述方案的硬件实现。如这些图中所示,该实现具有两个内容可寻址存储器560、562—一个560存储乱序分组链的第一序号作为关键字以及另一个562存储该链的最后一个+1序号作为关键字。如所示,CAM560、562还存储链的长度。
其他实施例可以使用单个CAM。同样,其他实施例实现使用根据地址的存储器或其他数据存储器而不是内容可寻址存储器。
潜在地,能使用相同的CAM来跟踪许多不同连接的分组。在这些情况下,可以将连接ID追加到每个CAM条目上作为关键字的一部分,以便区别不同连接的条目。将分组信息与CAM560、562中的链合并允许通过更小的CAM560、562处理更多的连接。
如图12所示,该实施例包括存储起始序号550、结尾序号552和数据长度554的寄存器。如图2所示的处理器122可以存储这些寄存器550、552、554来与子系统500通信。例如,处理器122能将新接收的分组的数据加载到子系统500数据中。处理器122还可以请求下一所期望的序号以便包括在向回发送到发送器的确认消息中。
如所示,该实现对控制信号进行操作,以便从CAM560、562读取(CAMREAD)、写入CAM560、562(CAMWRITE)和清除CAM560、562条目(CAMCLR)。如图12所示,可以将硬件配置成当寄存器550、552、554被加载数据时,同时将寄存器值写到CAM560、562中。如图13所示,对“命中”指定起始或结尾序号,电路将“seglen”寄存器设置为匹配CAM条目的长度。电路(未示出)也可以在成功的CAM560、562读取操作后,设置“seqfirst”550和“seqlast”552寄存器的值。电路也可以提供标识CAM560、562中的特定“命中”条目的“CamIndex”信号。
为实现如上所述的分组跟踪方法,子系统500可以具有执行实现该方案的指令的其自己的独立控制器的特征或可能具有硬布线逻辑的特征。另外,处理器122(图1)可以包括该方案的指令。潜在地,可扩展处理器122的指令集(图4)以包括访问子系统500 CAM560、562的命令。这些指令可以包括将数据写入CAM560、562的指令(例如,用于CAM510的CAM2FirstWR key<--data和用于CAM562的CAM2LastWR key<--data);从CAM读取数据的指令(例如,CAM2FirstRD key-->data和CAM2LastRD key-->data);清除CAM条目的指令(例如CAM2CLR key),和/或如果查找失败,生成条件值的指令(例如CAM2EMPTY-->cond)。
参考图14,潜在地,可以以相同的速度对接口108和处理110逻辑部件同步。时钟信号基本决定了逻辑网络将以多快操作。不幸地是,由于对指定分组可以执行许多指令的事实,为了以线速操作,系统106可以以远超过连接速率的非常快的速率被同步。以单独的非常快的时钟运行整个系统106不仅会浪费大量功率而且会产生可以影响热敏硅的行为的高温。
相反,如图14所示,可以以不同速度来同步接口108和处理110逻辑中的部件。例如,接口108部件可以对应于网络连接的速度的速率“1x”同步。由于可以编程处理逻辑110以便执行多条指令来实现用于指定分组的适当的网络协议操作,所以可以以快于接口108的速率对处理逻辑110部件同步。例如,处理逻辑110中的部件可以接口108时钟频率的几倍“k”同步,其中“k”足够高以便为处理器122提供足够的时间来完成执行用于分组的指令而不会落后于线速。使用“双时钟”方法的系统106可以具有允许不同时钟的部件来通信的称为“同步器”(未示出)的设备的特征。
作为“双时钟”系统的例子,对具有16位宽的接口108数据系统106来说,为了实现每秒10千兆比特,应当以625MHz的频率对接口108同步(例如[每个周期16位]×[每秒625,000,000周期]=每秒10,000,000,000位)。假定最小分组为64字节(例如,仅具有IP和TCP首部、帧校验序列以及硬件资源和目的地地址的分组),会花费16位/625MHz接口10832周期来接收分组位。潜在地,分组间的间隙在下一分组到达之前可以提供另外的时间。如果使用最大为n的一组指令来处理分组和每个周期可以执行不同的指令,则可以以k·(625MHz)的频率对处理块110同步,其中k=n-指令数/32周期。为方便实现,k的值可以四舍五入为整数值或2n值,不过这些中的任何一个均不是严格要求。
由于按更快的时钟运行的部件通常比以较慢的时钟运行的相同部件消耗更多的功率和产生更多的热,所以根据它们的需要以不同速度同步不同部件108、110能允许系统106节省功率和保持较低温。这不仅能降低系统106的功率需求并且能降低对昂贵的冷却系统的需要。
能更进一步降低功率消耗和热生成。即,图14中所述的系统106具有以由“最糟糕”情况下确定的不同的、固定速度同步的系统106逻辑部件的特征,以确保处理块110跟上线速。同样地,需要最快处理的最小分组充当过对处理块110时钟速度的约束。然而,实际上,大多数分组,几乎95%具有较大分组大小的特征,并为系统106提供更多的时间来在下一分组到达之前进行处理。
因此,代替使系统106永久地适合处理困难的情况,图15描述了一个系统106,该系统106能够根据一个或多个分组特征动态改变的频率为处理逻辑110部件提供时钟信号。例如,系统106可能使用标识分组大小的数据(例如,IP数据报首部中的长度字段)来缩放时钟频率。例如,对更大的分组,处理器122使用更多的时间来在下一分组到达之前处理分组,从而可以降低频率而不会落后于线速。同样地,对更小的分组,可增加频率。当处理较大分组时,对不同的输入分组“实时”适应性地缩放时钟频率,能够通过降低操作频率来减小功率。反过来,这会导致可以避免产生硅“热点”和/或昂贵系统的冷却系统的冷却器运行系统。
如图15所示,缩放逻辑124接收分组数据并相应地调整提供给处理逻辑110的频率。尽管如上所述在分组大小上操作,但可使用各种其他的量度来调整频率,诸如有效载荷大小、服务质量(例如,更高的优先级分组可以接收更高的频率)、协议类型等等。另外,代替单个分组的特性,可使用总的特性来调整时钟速率(例如,所接收的分组的平均大小)。为节约另外的功率,当网络空闲时,可暂时禁止时钟。
可用各种硬件和/或软件方案来实现缩放逻辑124。例如,图16描述使用除法器408a-408c来提供可用频率(例如,32x、16x、8x和4x)范围的硬件方案。将不同频率信号馈送到多路复用器410,用于根据分组特征来选择。例如,选择器412可具有将分组大小与不同预先计算的阈值进行比较的幅值比较器的特征。例如,比较器可以对达到大小64字节(32x)、64和88字节(16x)间、88和126字节(8x)间和126至236字节(4x)的分组使用不同的频率。可以确定这些阈值,以便处理逻辑块频率满足下述等式:
[(块大小/数据宽度)/接口时钟频率]>=(接口时钟周期/接口时钟频率)+(指令的最大数/处理时钟频率)。
尽管图16示例说明了四种不同同步信号,但是其他实施例可具有n个同步信号。另外,所提供的不同频率间的关系未必是如图16所示的另一个的统一分数。
能将结果时钟信号发送到处理逻辑110内的不同部件。然而,并非处理逻辑110和接口10块内的所有部件都需要以相同时钟频率运行。例如,在图2中,尽管输入序列发生器接收“1x”时钟信号和处理器122接收“kx”时钟信号,但是根据该实施例,连接数据存储器112和CAM114可以接收“1x”或“kx”时钟信号。
将缩放逻辑124物理地放在频率源附近能降氏功率消耗。另外,以全局时钟分布点调整频率不仅节约功率而且降低用于提供时钟分布的逻辑需要。
另外,各种实施例可以使用如上所述的一种或多种技术。另外,系统106可以各种形式出现。例如,可以将系统106设计成单个芯片。潜在地,这种芯片可以包括在芯片组中或在母板上。另外,系统106可以被集成到部件中,诸如网络适配器、NIC(网络接口卡)或MAC(媒体访问设备)。潜在地,在此描述的技术可集成到微处理器中。
系统106也可以提供用于不止一种协议的操作。例如,系统106可以提供用于网络和传输层协议的操作。可使用系统106来执行用于各种主机,诸如存储开关和应用服务器的网络操作。
其他实施例在下述权利要求书的范围内。
Claims (26)
1.一种传输控制协议TCP卸载系统,所述系统包括:
第一接口电路,用于接收封装了TCP段的网际协议分组的至少一部分;并且从至少包括网际协议源地址、网际协议目的地址、源端口和目的端口的所述网际协议分组的所述至少一部分提取数据;其中,所述第一接口电路被以具有第一频率的第一时钟信号同步;
至主处理器的第二接口;以及
卸载系统处理器,用于为所述主处理器处理所述TCP段,所述卸载系统处理器至少为所接收的TCP段产生TCP确认ACK消息并且经由所述第二接口把所述TCP段的有效载荷传送给所述主处理器,所述卸载系统处理器被以具有不同于所述第一频率的第二频率的第二时钟信号同步,其中,所述第二频率根据分组大小加以确定。
2.如权利要求1所述的系统,其中,所述第二频率包括比所述第一频率更高的频率。
3.如权利要求1所述的系统,其中,所述卸载系统处理器包括用于执行下述操作中的至少一个操作的卸载系统处理器:为不同连接维持TCP状态机,和为不同连接确定TCP窗口。
4.如权利要求1所述的系统,其中,所述第二接口包括至外围部件接口PCI总线的接口,所述外围部件接口PCI总线将系统连接到所述主处理器。
5.如权利要求1所述的系统,其中,所述第二频率包括根据所述卸载系统处理器为一分组要执行的指令的数目而选择的频率。
6.如权利要求1所述的系统,其中,所述第二频率根据一个或多个分组特征加以确定。
7如权利要求6所述的系统,其中,所述第二频率根据分组大小加以确定。
8.如权利要求1所述的系统,进一步包括用于存储不同连接的标识符的内容可寻址存储器。
9.如权利要求5所述的系统,进一步包括用于存储连接上下文数据的存储器,所述存储器耦合到所述内容可寻址存储器。
10.如权利要求1所述的系统,其中,所述第一接口接收经媒体访问控制MAC设备接收的分组数据。
11.如权利要求1所述的系统,其中,所述卸载系统处理器包括算术逻辑单元和用于存储以供执行的指令的存储器。
12.如权利要求11所述的系统,其中,所述指令包括根据所述TCP协议处理所述TCP段的指令。
13.如权利要求11所述的系统,其中,所述指令包括来自微代码指令集的指令,所述微代码指令集包括用于访问连接数据的至少一条指令。
14.如权利要求11所述的系统,其中,所述指令包括来自微代码指令集的指令,所述微代码指令集包括指定内容可寻址存储器操作的至少一条指令。
15.如权利要求1所述的系统,其中,所述第一频率包括:为以每秒10千兆比特的速率处理接收数据的网络连接而选择的频率。
16.如权利要求1所述的系统,其中,所述卸载系统处理器进一步包括至少一个内容可寻址存储器,用以跟踪乱序接收的数据分组。
17.如权利要求1所述的卸载系统,其中,所述第二频率是所述第一频率的整数倍。
18.如权利要求1所述的卸载系统,其中,所述第一接口包括用于根据在内容可寻址存储器中的所述被提取的数据执行查找的接口,所述内容可寻址存储器存储指示所述卸载系统是否存储了与所述分组相关联的传输控制块TCB的数据。
19.一种系统,所述系统包括:
至少一个主处理器;
以连接速度提供网络连接的以太网媒体访问控制MAC设备;
耦合到所述MAC设备和所述至少一个主处理器的传输控制协议TCP卸载引擎,用于为所述至少一个主处理器执行TCP操作,所述网络协议卸载引擎包括:
至外围部件互连PCI总线的接口,所述外围部件互连PCI总线连接所述网络协议卸载引擎和所述至少一个主处理器;
电路,用于:
从所述MAC设备接收封装了TCP段的网际协议分组的至少一部分,和
从至少包括网际协议源地址、网际协议目的地址、源端口和目的端口的所述网际协议分组的所述至少一部分提取数据;其中,所述电路由第一时钟信号以第一频率同步,所述第一频率对应于所述连接速度;以及
卸载引擎处理器,至少用于为所接收的TCP段产生TCP确认ACK消息并且经由至所述PCI总线的所述接口把所述TCP段的有效载荷传送给所述主处理器;
其中,所述卸载引擎处理器由第二时钟信号以不同于所述第一频率的第二频率同步,其中所述第二频率根据分组大小加以确定。
20.如权利要求19所述的系统,其中,第二频率包括基于至少一个分组的一个或多个特征的频率。
21.如权利要求19所述的系统,其中,所述系统包括:
至少一个内容可寻址存储器的第一组,用于存储与不同网络连接相关联的数据;以及
至少一个内容可寻址存储器的第二组,用于跟踪乱序接收的分组。
22.如权利要求16所述的系统,其中,至所述PCI总线的接口包括至PCI-X总线的接口。
23.一种从主处理器卸载传输控制协议操作的方法,所述方法包括:
在由具有第一频率的第一时钟信号同步的电路,接收封装了TCP段的网际协议分组的至少一部分;
在由所述第一时钟信号同步的所述电路,从至少包括网际协议源地址、网际协议目的地址、源端口和目的端口的所述网际协议分组的所述至少一部分提取数据;以及
在包括卸载处理器的处理电路处理所述TCP段,所述卸载处理器至少用于为所接收的TCP段产生TCP确认ACK消息并且经由第二接口把所述TCP段的有效载荷传送给所述主处理器,所述卸载处理器由具有不同于所述第一频率的第二频率的第二时钟信号的源加以同步,其中,所述第二频率根据分组大小加以确定。
24.如权利要求23所述的方法,其中,用以经由第二接口把所述TCP段有效载荷传送给所述主处理器的所述处理器包括用以经外围部件互连PCI总线把所述TCP段有效载荷传送给所述主处理器的处理器。
25.如权利要求23所述的方法,进一步包括确定所述第二频率。
26.如权利要求23所述的方法,进一步包括在由第一时钟信号同步的所述电路,访问内容可寻址存储器以检索对应所述分组的连接的标识符。
27.如权利要求23所述的方法,进一步包括访问内容可寻址存储器以跟踪乱序接收的分组。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2003101203664A CN100484136C (zh) | 2003-10-27 | 2003-10-27 | 网络协议引擎 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2003101203664A CN100484136C (zh) | 2003-10-27 | 2003-10-27 | 网络协议引擎 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1612566A CN1612566A (zh) | 2005-05-04 |
CN100484136C true CN100484136C (zh) | 2009-04-29 |
Family
ID=34761521
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2003101203664A Expired - Fee Related CN100484136C (zh) | 2003-10-27 | 2003-10-27 | 网络协议引擎 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100484136C (zh) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007174644A (ja) * | 2005-12-22 | 2007-07-05 | Intuitive Surgical Inc | 同期データ通信 |
WO2008115537A1 (en) * | 2007-03-20 | 2008-09-25 | Marvell World Trade Ltd. | Synchronous network device |
CN101741870B (zh) * | 2008-11-07 | 2012-11-14 | 英业达股份有限公司 | 因特网小型计算机接口的储存系统 |
CN103546424A (zh) * | 2012-07-10 | 2014-01-29 | 华为技术有限公司 | 一种tcp数据传输方法、tcp卸载引擎及系统 |
CN104601484B (zh) * | 2015-01-20 | 2017-10-31 | 电子科技大学 | 一种tcp卸载引擎的发送单元 |
WO2019219184A1 (en) * | 2018-05-16 | 2019-11-21 | Huawei Technologies Co., Ltd. | Receiving device and transmitting device for tcp communication |
-
2003
- 2003-10-27 CN CNB2003101203664A patent/CN100484136C/zh not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
CN1612566A (zh) | 2005-05-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7181544B2 (en) | Network protocol engine | |
US7324540B2 (en) | Network protocol off-load engines | |
US7916632B1 (en) | Systems and methods for handling packet fragmentation | |
US7773599B1 (en) | Packet fragment handling | |
US8526441B2 (en) | System and method for handling out-of-order frames | |
JP4504977B2 (ja) | オフロードユニットを使用したtcp接続のためのデータ処理 | |
US7782857B2 (en) | Logical separation and accessing of descriptor memories | |
US8085780B1 (en) | Optimized buffer loading for packet header processing | |
US20040044796A1 (en) | Tracking out-of-order packets | |
US20040001484A1 (en) | Method and apparatus for implementing alterations on multiple concurrent frames | |
US8462804B2 (en) | Self-cleaning mechanism for error recovery | |
US20050135415A1 (en) | System and method for supporting TCP out-of-order receive data using generic buffer | |
CN114844826A (zh) | 在网络的节点之间的异步套接字复制 | |
CN110838935A (zh) | 高可用sdn控制器集群方法、系统、存储介质及设备 | |
US7239630B1 (en) | Dedicated processing resources for packet header generation | |
CN100484136C (zh) | 网络协议引擎 | |
EP1460804B1 (en) | System and method for handling out-of-order frames (fka reception of out-of-order tcp data with zero copy service) | |
US7158520B1 (en) | Mailbox registers for synchronizing header processing execution | |
US7180893B1 (en) | Parallel layer 2 and layer 3 processing components in a network router | |
US7016354B2 (en) | Packet-based clock signal |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20090429 Termination date: 20191027 |