CN1677952A - 线速分组并行转发方法和装置 - Google Patents
线速分组并行转发方法和装置 Download PDFInfo
- Publication number
- CN1677952A CN1677952A CNA200410031867XA CN200410031867A CN1677952A CN 1677952 A CN1677952 A CN 1677952A CN A200410031867X A CNA200410031867X A CN A200410031867XA CN 200410031867 A CN200410031867 A CN 200410031867A CN 1677952 A CN1677952 A CN 1677952A
- Authority
- CN
- China
- Prior art keywords
- packet
- thread
- grouping
- forwarding
- descriptor
- 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.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供了一种线速分组并行转发的方法和装置。其中提供了相互分离的控制平面和转发平面,转发平面上具有多个转发引擎。还提供了两个存储器SDRAM和SRAM,其中SDRAM用于暂存分组,而SRAM用于存储分组描述符。SRAM中的分组描述符与SDRAM中的分组存放地址之间存在线性映射关系。当有分组到达入端口时,接收调度线程调度多个接收线程执行接收任务;接收线程将分组存放到一个分组描述符所对应的存放地址,修改该分组描述符,查找分组转发表后将其插入发送队列;发送调度线程调度多个发送线程轮流执行发送任务;发送线程从发送队列中取出一个分组描述符,将该分组描述符所对应的分组拷贝到TFIFO中。
Description
技术领域
本发明涉及分组转发方法和装置,特别涉及线速分组并行转发方法和装置。
背景技术
分组转发是构建因特网(Internet)的核心技术。尽管不同的厂家采用不同的技术设计各种型号的交换机和路由器,运行的操作系统和处理性能上也有很大的差别,但最核心的工作相同,就是进行数据的分组转发。分组转发的过程大体上可以概括为:接收分组,提取分组中的目的地址,查找转发表,决定分组下一跳的出端口,之后将分组从出端口中发送。对于任一分组,这几个过程一直在网络中持续下去,直到分组到达目的地。当前Internet中的数据处理设备多种多样,但处理分组的方式可以划分为两种:(1)非并行的分组处理方式。这是较为传统的分组处理,系统中的单个中央处理单元(CPU)通过运行分组处理进程来完成分组的转发,这种设备占领了数据产品市场的较大份额,但性能较差。文中针对这种分组处理设备的不足进行了深刻的剖析;(2)并行的分组处理方式。通过多个处理器并行地进行分组的处理,来提高系统的整体性能:提高吞吐量、减少时延、减少丢包率、减少实时业务的抖动等等。尽管实现并行分组转发的方法很多,但能达到线速处理的并行处理方法很少。本文介绍的并行分组处理方法经过F-Engine系列设备的多次测试,证明性能优异,并行分组处理能力能达到线速。
对分组处理的实现方法研究很多,大部分是采用非并行的分组处理方式。不少的路由器和交换机采用通用的CPU或是嵌入式的CPU(俗称通讯处理器)进行分组转发。在这种系统中,系统依靠唯一的处理器资源,运行系统中的多个进程来完成系统中的多项任务,如:进程调度、资源分配、异常处理、系统日志等,分组处理进程只是其中一个。当前较为流行的解决方案中,不少是采用Motorola MPC860或是Motorola MPC8240进行分组的处理。Cisco 2600路由器就是采用MPC860的一个典型的应用,与众不同的是,Cisco2600采用高速缓冲存储器(Cache)作为分组处理加速器,虽然如此,其10/100M以太网的处理能力仍然不能达到线速处理的能力。类似的实现方案还有:D-Link DI-1750,清华同方TFR2501和TFR2502,等等。QuidwayR3600E、港湾NetHammer M262均是基于MPC8240的实现,华为QuidwayR1760则采用了MPC8241进行分组处理。在市场感召力下,Intel也推出了通信处理器IXP425,其分组处理借助于嵌入式、低功耗ARM CPU来完成。IXP425也是通过采用加速的方式来提高分组的处理能力。这些分组处理的实现,均有一个共同点,就是CPU参与分组的处理,但处理能力不高,为了提高系统的处理能力,往往借助于Cache或其它的加速处理模块来提高系统的性能,但性能提升的幅度有限,不能达到线速处理,这种现象是此类设备的严重缺陷,它们占用了网络上的接口资源,同时又让这些接口成为数据转发的瓶颈。当前网络上众多的设备当中,不少的中低端交换机和路由器均是采用单CPU单分组处理进程的方式来完成分组转发的。
非并行的分组处理方法中,分组处理进程在运行一段时间后,可能由于别的原因(如系统中有中断产生)而被操作系统换出。如此一来,分组处理的进程就被挂起,放在分组缓冲区中的分组被无限的排队等候,此时有两种可能的情况发生:
(1)下次分组处理进程被操作系统调度时,继续分组的处理,这时分组已经在排队缓冲区中等候多时,造成了分组较大的时延,如图1A和1B所示。图1A和1B图解说明了传统路由器中分组时延的产生,其中图1A图示了连续发送的两个语音分组,而图1B图示了时延造成语音分组的抖动。用户端在t=0的时刻,发送了两个语音分组,间隔为Δt,在线路中经过了一跳(one hop)非并行的分组处理路由器,由于调度上的原因,分组到达接收端,分组间的间隔变成了χ·Δt,当χ·Δt>50ms时,接收端就会明显地感觉到语音抖动。在基于传统的分组处理方式上,出现上述现象是很常见的事情。
(2)分组处理进程被再次调度之前,网络接口中可能已经有大量的分组到来,放在队列中的分组被“淹没”,造成大量的分组丢失,这是实时业务传送中造成传输质量下滑的主要原因。图2A和2B图解说明了传统分组处理设备中分组的丢失,其中图2A图示了在某一时刻系统中的排队分组,而图2B图示了系统中的分组因处理不及时被“淹没”。在图2B中,图2A中的P2,P3,...,Pn分组被P8,P9,...,Pm分组所覆盖,对于实时语音业务而言,接收端就会感觉到语音不连贯;对于TCP连接,有可能造成连接丢失;对于动态路由协议,如OSPF,BGP等,长时间的网络拥塞,易出现邻居关系的丢失,造成路由的翻转,网络不稳定。
另外一种较大的缺陷就是系统的吞吐量小。非并行处理的情况下,系统的吞吐量大打折扣。假设系统中仅有5个进程,其中一个为系统调度进程,一个为资源管理进程,一个为日志进程,一个为输入输出处理进程,另一个是分组处理进程。这样的系统中,分组处理进程最多只能有20%的CPU时钟周期在进行分组的处理,其它大部分时间在执行系统中的其它处理。这是最简单的系统模型,在传统的路由器和交换机中,分组进程能拥有20%的处理机时间已经是理论极限值。总之,就是CPU无法专注做好“分组转发”这一任务,因此系统的吞吐量相对于多转发引擎上的并行分组处理来说,大为降低,而且整个系统中由于没有进行转发平面和控制平面的分离,致使系统的稳定性和安全性也较差。
综合上述,主要的弊端有以下几点:
(1)系统中CPU资源由于处理各种事务,如内核调度,中断处理等原因,导致分组处理进程被调出,致使分组的转发时延不确定;
(2)用于分组处理的时间短,容易导致大量的分组由于来不及及时处理而被丢失;往往使实时业务出现抖动,而非实时业务如TCP报文丢失,必须进行重传;
(3)系统的吞吐量小,不可能达到线速处理分组的能力;
(4)安全性较差。当系统中出现非法流量的攻击,如网络上较流行的冲击波病毒时,系统中的某些进程由于资源耗尽无法继续运行,如ARP进程,当出现这种状况时,系统只能借助重新启动才能恢复正常;
(5)稳定性较差。当存在设计上的逻辑错误时,如内存泄漏,非法地址操作等,就会导致整个系统(转发平面和控制平面)一起崩溃。
发明内容
本文的目的在于提供一种具有线速转发能力的并行分组处理方法及装置。
根据本发明的一个方面,提供了一种分组转发方法,用于将来自至少一个入端口的分组数据从至少一个出端口转发出去,该方法包括:提供相互分离的控制平面和转发平面,在控制平面中进行系统控制操作,而在转发平面中进行分组转发操作,在转发平面中提供至少一个并行的转发引擎,每个转发引擎上运行多个线程,所述线程包括至少一个接收线程和至少一个发送线程,由所述接收线程从所述入端口接收分组;以及由所述发送线程将所接收到的分组并行发送到出端口。
根据本发明的另一个方面,提供了一种分组转发装置,用于将来自至少一个入端口的分组数据从至少一个出端口转发出去,该装置包括:控制平面,用于进行系统控制操作;转发平面,和控制平面相互分离,用于进行分组转发操作,所述转发平面包括至少两个转发引擎,转发引擎包括:接收线程处理单元,用于产生至少一个接收线程,所述接收线程用于从所述入端口接收分组;以及发送线程处理单元,用于产生至少一个发送线程,所述发送线程用于将所接收到的分组并行发送到出端口。
本发明还提供了一种扩展分组转发装置,其通过使用交叉背板,将至少一个根据本发明的分组转发装置连接在一起。
相对于传统分组转发方法和装置的分析,本发明主要作出的改进有:
(1)控制平面和转发平面分离,增强系统的稳定性和安全性;转发线程只在数据平面运行,对非法的数据流造成的不稳定性在该平面中进行了隔离,不会波及到控制平面;同样,控制平面上的误操作(如非法地址访问,内存泄漏等)不会波及到转发平面;
(2)采用多处理器进行分组的并行转发;转发的执行单元为线程,相对于进程而言,运行过程中开销更小,速度更快,效率更高,对存储空间的访问采用直接定位的方式进行,而不需要操作系统进行地址分配(如:执行malloc操作);
(3)系统中的进程调度、中断处理、资源分配等任务全部在控制平面完成,转发平面只是并行地进行分组的处理;所有的转发线程只是专注完成同一个任务:处理分组;
(4)在同一处理器上,转发线程有多个,当其中的一个线程因访问系统中的资源等待完成,如存放分组,等待信号量时,它立刻进入“休眠”状态,切换出处理器,让其它的线程执行,进行分组的转发;当等待线程的等待事件发生时,“休眠”的线程立即被调度线程唤醒;
(5)调度线程非常简单,在调度的过程中,占用处理器的时间很短,不同于非并行转发方法中操作系统的调度机制,后者需要耗费大量的处理器时间;
(6)获取分组存放位置的方法简单,直接采用线性映射的方法完成;而非并行方法中,分组的存放位置由操作系统确定,进行分组存放时,必须运行系统中的资源分配进程,整个分组处理过程的效率大大降低。
附图说明
图1A和1B图解说明了传统路由器中分组时延的产生,其中图1A图示了连续发送的两个语音分组,而图1B图示了时延易造成语音分组的抖动;
图2A和2B图解说明了传统分组处理设备中分组的丢失,其中图2A图示了在某一时刻系统中的排队分组,而图2B图示了系统中的分组因处理不及时被“淹没”;
图3图示了实现并行分组转发的系统结构;
图4图示了分组并行通过转发引擎的逻辑视图;
图5图示了并行分组转发的软件体系结构;
图6图示了空闲分组描述符队列;
图7图示了线程的状态切换;
图8图示了对发送线程进行的发送调度;
图9图示了基于邮箱的线程间通讯;
图10图示了发送调度线程和发送线程之间的协调调度工作;
图11图示了单个分组的处理过程;
图12图示了并行度的扩展。
具体实施方式
下面参考附图3至图12详细描述本发明的线速分组并行转发方法和装置。
1.系统的体系结构
首先描述本发明所采用的系统的体系结构。本发明的算法主要是基于图3所示的网络并行处理器。值得一提的是,本发明的分组并行转发算法并不具有平台依赖性(Platform-independent),稍作修改就可以移植到其它的网络处理器上。为了讨论的方便,文中的叙述以以太网为例。
图3图示了实现并行分组转发的系统结构。图3中,μP是实现分组并行转发的微处理器(称之为转发引擎),多个微处理器上通过运行多个发送和接收线程来实现分组的并行处理。与转发引擎相连的SDRAM是实现存储转发的分组缓存,在SRAM中则驻留了为了实现高速分组查找的转发表(forwarding table)。本发明中作为示例采用了SDRAM和SRAM作为第一和第二存储器,但是应该明白,采用其它存储器也可以实现本发明的技术方案。为了进一步减少转发操作的时间,用于存储转发表以及下文中将提到的分组描述符的第二存储器的存取速度最好比用于存储分组的第一存储器快。主控CPU和μP之间提供了信令控制通道(Control Path),当转发引擎收到协议分组,如OSPF、BGP报文的时候,通过该通道传送到主控CPU,由主控CPU进行相关的处理。以太网接口接收链路上的帧,送到接收FIFO(先入先出)(RFIFO)中,等待转发引擎的进一步转发处理。分组经由转发引擎并行处理的逻辑视图可参考图4描述如下。其中,C表示分组的分类,F表示转发引擎上多个线程并行地对分组进行转发,S表示在接口上进行分组的发送。数据总线(data bus)可以根据具体的硬件配置进行适配,如我们采用的POS-PHY L3数据总线,64位宽,设定32位用来接收数据,32位用来发送数据,接收和发送时钟从60MHZ到104MHZ可配,在我们的系统设计原形中,我们选用了80MHZ的发送时钟和接收时钟。总线上的RSOP、REOP和TSOP、TEOP是POS-PHY L3数据总线上分组开始和结束的信号,前者是接收方向上的信号,后者是发送方向上的信号,考虑到文中的叙述容易辨别这两对信号,所以后面统称为SOP和EOP。
图5是并行分组转发的体系结构。其中接收线程的运行轨迹表明接收线程在进行分组处理时要完成的主要任务。发送线程的运行轨迹则表示发送线程在系统中要完成的发送任务。数据平面主要进行分组的处理,通常称之为快速通道。从数据平面到控制平面的路径就是图3中的控制通道(ControlPath),主要负责将控制分组从转发平面发送到控制平面,并由控制平面进行相应的处理。
2.数据结构
接下来,描述本发明所采用的数据结构。分组在系统中被分割成大小相等的数据块(cell),每块的大小为64字节。不足64字节的块称为残块。
在存储转发机制中,转发引擎在将分组发往出端口之前,分组必须在系统中暂存。为了提高系统的转发性能,需要迅速地确定分组的存放位置,在访问完转发表并进行IP头的修改之后,又必须快速的提取该分组,按照查找的结果进行发送。文献“Sundar Iyer,Amr Awadallah,and Nick McKeown,Analysis of a packet switch with memories running slower than the line-rate(有关使用运行速度低于线路速度的存储器的分组交换的分析),IEEE/ACMTransactions on Networking(TON),volumell,Issue(2),2003.4”的研究显示,存储器的存取速度会直接影响到系统的转发效率。所以为了提高转发性能,必须减少存储器的访问次数,特别是SDRAM的访问。为达到这一目的,我们定义了分组描述符,作为分组的索引,将其存放在SRAM中。分组描述符的数据结构如下:
struct pkt_descriptor{
unsigned int port:7; /*入端口号*/
unsigned int notused:1; /*未使用*/
unsigned int sop:1; /*分组起始(start of packets)*/
unsigned int eop:1; /*分组结束(end of packets)*/
unsigned int num_of_bytes:6;/*字节数*/
unsigned int num_of_cell:6; /*cell字节数*/
unsigned int res:10; /*保留*/
struct pkt_descriptor*p_dsc; /*指向下一个包描述符的指针*/
}
对于每一个分组,均有一个分组描述符进行表述,以反映其基本情况,分组描述符的num_of_cell和num_of_bytes定义了分组的大小,为(num_of_cell×64+num_of_bytes)字节。同一个分组的所有数据块(包括残块)按照固定的顺序存放在一起。SOP被置位,表示数据块是分组的第一个数据块,EOP被置位表示数据块是分组的最后一个数据块(或残块)。
系统在初始化的时候,所有尚未用于描述分组的空闲分组描述符通过指针链接在一起,形成一个队列,如图6所示。图6图示了空闲分组描述符队列,其中Header是队列头指针,而Tailor是队列尾指针。
分组描述符pkt_dsc在SRAM中的存储地址和分组在SDRAM中的存放地址pkt_buffer之间存在映射关系。映射函数f定义为:
pkt_buffer=f(pkt_dsc),
考虑到映射函数的效率,通常将其定义为线性函数,使映射过程能在有限的机器周期内完成,如pkt_buffer=((pkt_dsc-sram_descriptor_base)<<bufsize_factor)+sdram_base
其中,bufsize_factor为分组的大小因子,在实现中我们将每个分组的缓存大小定义为2K。sram_descriptor_base是描述符在SRAM中的基地址,而sdram_base是SDRAM中的基地址。通过将分组描述符在SRAM中的相对地址移位适当的分组大小因子bufsize_factor次,获得分组SDRAM中的相对地址,加上SDRAM中的基地址就是分组在SDRAM中的绝对地址。
由于上述的映射函数是线性函数,所以具有较高的转换效率,能在有限的机器指令周期内完成,通过分组描述符的地址来定位分组在SDRAM中的存放位置。值得一提的是,分组描述符的地址空间在SRAM中,这样安排的目的主要是由于系统会对分组描述符访问的次数较多,而SRAM的存取速度较快,在我们的实现中,SRAM与SDRAM的速度相差几倍以上。
除了分组描述符队列外,还为每个端口均形成了8个由分组描述符组成的发送队列,分别对应于8个不同的优先级。通过上面定义的映射关系,在完成转发表的查找后,发送线程能根据分组描述符很快地定位到分组存放的位置,将其从发送端口发送出去。
在接收分组时,从空闲分组描述符队列中取出一个分组描述符,将分组存放到该分组描述符所对应的存放地址,并根据所接收的分组的状况,填写该分组描述符,并在分组接收结束时,将修改后的分组描述符插入到对应的发送队列中。在发送分组时,从发送队列中取出一个分组描述符,相应地发送其所对应的分组,并在发送成功之后,将分组描述符回收到空闲分组描述符队列中。需要注意的是,将分组描述符从队列中“取出”或“插入”队列中的操作并不意味着改变分组描述符在SRAM中实际存储位置,而只是改变其在队列中指针指向关系。
3.并行转发处理
下面详细描述转发引擎上的线程并行转发分组的处理。
在转发引擎中,使用接收线程将分组从端口的RFIFO中接收到网络处理器内进行处理,而使用发送线程将分组从SDRAM中拷贝到TFIFO中。
转发引擎上的线程有三种状态,运行(executing)、休眠(sleeping)和就绪(ready)。为了达到实时分组处理的要求,线程间采用的是非抢占性的调度方式。正在执行的线程因等待I/O执行完成或收到上下文换出信号时进入休眠状态,当I/O执行完成或收到上下文换入时则转入就绪状态。引擎空闲时,调度线程将处于就绪状态的某个线程进行调度,转为运行状态,如图7所示。图7图示了线程的状态切换。通常转发引擎上的每个线程均有自己的上下文寄存器,可以实现零开销的上下文切换。
调度线程的调度有两种,一是接收线程的调度,它唤醒接收线程,接收状态机在相应端口的RFIFO中接受分组,接收线程则将分组传送到分组缓存中进行处理,并等待转发;二是发送线程的调度,它唤醒发送线程,将分组从计算出的分组缓存中移出到出端口的TFIFO中,等待发送。
图3所示的网络处理器中具有多个转发引擎,转发引擎并行工作,进行分组的处理。而每个转发引擎上并发运行着多个接收线程或发送线程,这些线程在调度线程的统一调度下,进行分组的存储转发。
基于实现上的考虑,调度线程分为两部分,即接收调度(接收调度线程)和发送调度(发送调度线程)。调度线程本身也要占用μP时间片和相应的资源,因此,提高调度的效率和合理安排线程运行的时间片对提高系统的吞吐量至关重要。
在转发引擎中,这些线程并行地对多个分组进行转发处理。而就一个分组的转发处理而言,包括以下几个步骤。首先,响应分组的到达,接收调度线程唤醒接收线程。接下来,接收线程将分组接收到SDRAM中。然后,发送调度线程向发送线程分配发送任务。最后,发送线程将分组从SDRAM拷贝到TFIFO中。下面以接收调度线程、接收线程、发送调度线程、发送线程的顺序依次描述这几个线程的处理。需要注意的是,这些线程在转发引擎中实际上是并行执行的。
3.1接收调度线程
接收调度线程轮询32位的接收控制寄存器Rev_control,当寄存器Rev_control中有相应的位被置位时,表示对应的端口有分组到达。接收调度线程就进行调度,唤醒一个接收线程,向其分配接收任务,同时将接收控制寄存器中对应的位清零,以便清除已经调度了的接收请求。可以为每个入端口提供对应的接收线程,当该入端口有分组到达时,如果其所对应的接收线程当前在休眠的话,就直接将其唤醒。接收线程与入端口也可以不对应,当有分组到达时,就寻找一个休眠的线程,并将其唤醒。其调度算法如算法1所示。
算法1接收调度算法
系统初始化;
while(1)
读Rev_control到rec_task中;
for(j=0;j<32,j++)
{
if(rec_task&&(1<<j))
thread_lock; /*实现调度过程中线程的原子切换*/
clear bitj in Rev_control; /*清除已经调度了的接收请求*/
signal rec_thread[j]; /*唤醒接收线程*/
thread_unlock;
context_swap; /*上下文切换,接收线程开始工作*/
endif
}/*end for*/
}/*endwhile*/
3.2接收线程(receiving_thread)
接收线程主要完成从端口的RFIFO中将分组接收到网络处理器内进行处理。接收线程由接收调度线程唤醒,表明某个物理端口有分组到达。接收线程被唤醒后首先使一个分组描述符出列,提供给该分组,计算该分组描述符对应的分组存放地址pkt_buffer,并向接收状态机发送一个接收请求,然后继续休眠,等待接收状态机的回应。接收状态机的回应再次唤醒接收线程,使之开始进行分组的接收处理。接收线程从指定的RFIFO单元读取数据块存放到SDRAM中。若是IP分组,就同时进行解析,查转发表,找到输出端口号,并将分组描述符在相应的出端口的输出队列中排队。若不是IP分组,则把分组送到主控CPU上,由主控CPU进行处理。在接收IP分组的同时,修改分组描述符中包的字节数等内容,以反映分组的状况,并根据查找转发表的结果将分组描述符插入到相应出端口相应优先级的发送队列中。在上述各步骤完成之后,IP分组的接收处理就已经完成。接收线程的算法用算法2描述如下。
算法2:接收算法
初始化信号量,寄存器初始化;
while(1)
{
sleep; /*等待被接收调度线程唤醒*/
使一个分组描述符(packet descriptor)出列(dequeue),计算该packet
descriptor对应的pkt_buffer;
发送接收请求; /*与接收状态机进行分组接收的交互*/
sleep; /*切换出处理器,等待被接收状态机唤醒*/
检查寄存器接收状态(rec_state),如果出错,就进行出错处理;
if(not SOP and not EOP)
更新packet_descripter中分组的字节数,并把RFIFO中的数据块
写到分组缓冲(packet_buffer)中的相应位置;
elif sop
则进行分组的处理:
提取IP报头(header);
验证IP header的正确性;出错,则丢弃;
进行IP header的修正处理,如减TTL,重新计算分组头校验和等;
提取目的IP;
查找转发表,确定分组的出端口,并提取出端口的MAC地址;
修改以太网帧的源MAC和目的MAC,重新进行以太网帧的封装;
将新的分组头(含以太网帧头)写回packet_buffer;
endif/*endif of(not SOP and not EOP)*/
if EOP
if(not discarded)
修改packet descripter中包的字节数;
根据查找转发表的结果将packet descripter插入到相应优先级
的发送队列;
else
丢弃处理;
endif
endif/*endif of EOP*/
} /*end of while*/
3.3发送调度线程
发送调度线程依次从低到高轮询发送向量寄存器XMIT_VECTOR,该向量寄存器由接收线程设置,其中的某一位置位表示对应端口的发送队列非空。如果发送调度线程轮询到XMIT_VECTOR中的某一位置位,则唤醒一个发送线程,并为其分配一个发送任务,指明要发送的端口,然后继续轮询。如果轮询到下一位为零,则为下一个发送线程分配空任务,依次反复。图8是发送调度线程thd 0通过发送信号1、2、3给发送线程thd 1、thd 2、thd 3轮流分配发送任务的示意图。如图8所示,当系统中有发送请求时,发送调度线程就向轮到接收发送任务的发送线程发送唤醒信号,使之就绪,并占领引擎资源开始运行。相应的算法如下。
算法3发送调度算法
常量定义;硬件寄存器初始化;
初始化三个发送线程;
while(1)
{
轮询发送向量寄存器XMIT_VECTOR第(i++mod 32)位;
if对应位为1
向(j++mod num_of_XMIT_thd)号发送线程分配一个发送任务;唤醒该
发送线程;
/*j为发送任务计数,循环分配给线程,
num_of_XMIT_thd为发送线程的数目*/
else
向(j++mod num_of_XMIT_thd)号发送线程分配一个空任务;唤醒该发
送线程;
/*j为发送任务计数,循环分配给线程,
num_of_XMIT_thd为发送线程的数目*/
context_swap;
......
}
3.4发送线程(transmitting_thread)
发送线程主要是以数据块为单位,将数据块从SDRAM中拷贝到TFIFO中。当数据块拷贝完毕,就发送相应的发送控制字,指示发送状态机进行发送。当发送调度线程为发送线程分配了发送任务时,发送线程从发送队列中取出一个分组描述符并更新分组描述符队列结构,确定该分组描述符所对应的SDRAM中的分组存放位置,并将SDRAM中与该分组描述符对应的存放地址暂存的分组拷贝到TFIFO中,同时修改该分组描述符中的长度计数,在发送结束后,回收一个分组描述符到空闲分组描述符队列中。发送线程的发送算法用算法4描述如下。
算法4发送算法
常量定义,相关寄存器初始化;
while(1)
{
等待发送任务并为该任务设置输出队列(output queue),TFIFO单元
(element)等信息;
if SOP
从发送队列中取一个分组描述符并更新分组描述符队列结构;
if EOP/*SOP and EOP*/
将最后一个cell传送到TFIFO element中;
设置发送状态控制字;
等待目标端口准备好,使目标TFIFO element有效;
if发送成功
回收一个分组描述符到空闲分组描述符队列中;
else
保存端口信息,下次重发;
endif
else /*SOP but not EOP*/
将数据写到TFIFO element中,设置发送状态控制字;
等待目标端口准备好,使目标TFIFO element有效;
if发送成功
更新发送相关信息,为发送下一个数据块作准备;
else
保存剩余的element数,状态字节以及buffer偏移量;
endif
endif /*SOP but not EOP*/
else /*not SOP*/
if EOP /*not SOP but EOP*/
将最后一个cell传送到TFIFO element中;
设置发送状态控制字;
等待目标端口准备好,使目标TFIFO element有效;
if发送成功
回收一个分组描述符到空闲分组描述符队列中;
更新端口信息;
endif
else /*not SOP and not EOP*/
将数据传送到TFIFO element中;
设置发送状态控制字;
等待目标端口准备好,使目标TFIFO element有效;
if发送成功
更新端口信息;
endif
endif/*not SOP and not EOP*/
endif/*end of SOP*/
} /*end of while*/
上面描述了接收调度线程、接收线程、发送调度、发送线程借助于分组描述符对分组进行并行转发的处理方法。从上面的分析可以看出,接收调度和发送调度的设计都很简洁。这样处理的主要目的是让调度过程尽可能的简单,较少地占用引擎资源,使引擎上运行的接收和发送线程有足够的处理机时间来进行分组的接收和发送,从而提高系统的吞吐量(throughput),减少分组的转发时延。
需要注意的是,这里所给出的算法1-4只是作为例子来说明本发明的实施例,而不是用于限制本发明。本领域一般技术人员完全可以对本文中所描述的调度线程、接收线程、发送调度、发送线程的处理做出各种修改和替换。这样的修改和替换同样落在本发明的范围之内。
4.线速分组并行转发装置
上文中描述的线速分组并行转发方法可以通过,例如,下文中描述的线速分组并行转发装置来执行。该分组转发装置具有相互分离的控制平面和转发平面。控制平面用于进行系统控制操作,而转发平面用于进行分组转发操作。转发平面包括至少两个转发引擎。转发引擎包括:接收线程处理单元,用于产生至少一个接收线程,所述接收线程用于从所述入端口接收分组;发送线程处理单元,用于产生至少一个发送线程,所述发送线程用于将所接收到的分组并行发送到出端口;接收调度线程处理单元,用于产生接收调度线程,以在有分组到达入端口时,向对应的接收线程分配接收任务;以及发送调度线程处理单元,用于产生发送调度线程,以在接收所述分组之后,向所述至少一个发送线程分配发送任务。
该分组转发装置通过线程分配装置,将所述接收调度线程以及所述至少一个接收线程分配在某一个引擎上,并将所述发送调度线程以及所述至少一个发送线程分配在另一个引擎上。
响应接收线程的指令,用于产生描述所接收到的分组的分组描述符的装置根据该分组填写分组描述符。响应接收线程的指令,用于将描述要由同一个端口发送的分组的分组描述符排成发送队列的装置将该分组描述符插入发送队列中。用于检测发送队列是否为空的装置响应发送调度线程的指令进行其操作。而用于在发送队列非空时,从发送队列中取出分组描述符,以便向出端口发送所述分组描述符所描述的分组的装置响应发送线程的指令进行其操作。
使用第一存储器(SDRAM)在将分组发送到出端口之前暂存所述分组。
在第二存储器(SRAM)中存储至少一个分组描述符,用于描述接收到的分组,所述分组描述符与所述分组在第一存储器中的暂存位置对应,本实施例中,两者存在线性映射关系。相应地为该分组转发装置提供一个装置,以在向出端口发送所述分组时,使用分组描述符确定所述分组在第一存储器中的暂存位置。
该分组转发装置具有:用于使尚未用于描述分组的至少一个空闲分组描述符形成空闲分组描述符队列的装置;用于形成发送队列的装置,所述发送队列由用于描述分组的分组描述符组成。所述用于形成发送队列的装置为所述至少一个入端口中的每一个提供了至少一个发送队列,各个发送队列具有不同的优先级。
该分组转发装置中还提供了:用于在从入端口接收到分组之后,从所述空闲分组描述符队列中取出一个分组描述符,并更新所述空闲分组描述符队列的结构的装置;用于将所述分组暂存到所述第一存储器中与用来对所述分组进行描述的分组描述符相对应的暂存地址的装置;用于修改所取出的分组描述符,以描述所述分组的装置;以及用于将修改后的分组描述符插入到发送队列中的装置。这些装置都响应接收线程的指令执行其操作。
该分组转发装置中还提供了:用于在所述发送队列非空时,从发送队列中取出一个分组描述符,并更新发送队列的结构的装置;以及用于在成功地发送了所取出的分组描述符所描述的分组之后,将所述分组描述符回收到所述空闲分组描述符队列中的装置。这些装置都响应发送线程的指令执行其操作。
5.线程间的通讯
引擎上的不同线程可以通过消息的方式进行彼此间的通讯。如,接收线程完成数据分组的处理之后,可以进入休眠状态,等待调度线程唤醒发送线程来完成分组的发送。它也可以通过写消息的方式,告知发送线程相关的发送事件,当发送线程被唤醒时,从邮箱(mailbox)中取出消息,进行相应的处理。存放消息的数据结构称之为邮箱,系统中所有的线程可以通过互斥的方式对邮箱进行访问。当邮箱中有多个消息事件时,就形成了基于邮箱的消息队列,如图9所示。图9图示了基于邮箱的线程间通讯。消息分成消息头和消息体,消息头中指明了发送线程和接收线程的线程号,而消息体则表明了具体的消息事件。
也就是说,在本发明的线速并行分组转发装置中,可以提供线程间通信装置,其形成上述消息队列。线程间通信装置响应接收线程的指令,向消息队列写入用于告知相关的发送事件的消息,并由发送线程读取。
6.多个μP间的并行性和同一个μP上多个线程的并发性
在实现的时候,必须充分地考虑到系统的开销。进行跨引擎的线程调度在实现上是可行的,但造成系统的延时却是不可预知。因此,采用静态的方法进行线程的引擎调度,虽然会使系统缺乏灵活性,但可以减少系统在调度过程中的开销,至少系统不必花大量的时间来收集当前多个引擎的运行状态。因此,在进行引擎上的线程分配时,采用先分类再分配的静态分配方式,即将接收线程(包括接收调度线程)分配到相同的引擎上,而将发送线程(包括发送调度线程)分配到相同的引擎上。在上述的调度算法中,体现了这一分配原则。另外,由于接收任务相对于发送任务来说要复杂,所以接收线程与发送线程的数目之比也直接影响到系统的吞吐量。经过多次实验,我们发现,当接收线程与发送线程的比例为2∶1时,发送与接收的配合最为协调,系统获得的吞吐量最大,分组转发时延最小。图10是这一引擎分配原则下,发送线程的并发示意图。图中,调度线程T0唤醒T1,进行分组P0发送任务的处理;假设这是P1发送任务已经到达,T2就被唤醒,执行发送任务P1,从而通过并发的方式完成系统中分组的发送。
图11中描述了分组在系统中的处理过程。其中的接收状态机将分组从链路上收入到RFIFO中,发送状态机则将分组发送到与出端口相连的链路上。可以看出,分组从进入系统开始,分成几个不同的处理阶段。就单个分组而言,这几个过程是串行执行的,但从多个分组的角度看,分组之间的处理是并行的。图中Δt1和Δt3是访问存储器引起的延迟,Δt2则是由于接收线程进行分组的处理如解析分组头、查找转发表等引起的延迟。S0、S1、S2、S3则分别表示整个分组转发的四个处理过程。其中响应接收信号Rcv_signal开始接收处理S1,而响应发送信号Xmit_signal开始发送处理S2。
7.采用本发明的效果:性能分析。
网络性能的评价通常是用一些具体的参数值来进行度量的。网络带宽、时延、吞吐率、及丢包率是进行网络性能评价的几个主要参数,也是检验并行分组转发算法的重要依据。在我们的测试平台中,主控CPU及转发引擎的时钟频率均为200M,SRAM和SDRAM总线的时钟频率均为100M,数据总线为64位的POS_PHY L3总线,时钟为80M。2001年,武汉烽火网络公司进行了文中算法的实现,并推出了F-engine系列交换和路由设备。表1-表3是用测试仪表SmartBits测出的性能参数。
表1.10/100M以太网并行分组转发带宽/吞吐量的性能测试
包长(bytes) | 吞吐量(packets/s) | 带宽(%) | 测试数据(packets/s) | 平均值(packets/s) | |||
5s | 10s | 15s | 20s | ||||
64 | 148810 | 100 | 148810 | 148810 | 148810 | 148810 | 148810 |
128 | 84459 | 100 | 84459 | 84459 | 84459 | 84459 | 84459 |
256 | 45290 | 100 | 45290 | 45290 | 45290 | 45290 | 45290 |
512 | 23496 | 100 | 23496 | 23496 | 23496 | 23496 | 23496 |
1024 | 11973 | 100 | 11973 | 11973 | 11973 | 11973 | 11973 |
1518 | 8127 | 100 | 8127 | 8127 | 8127 | 8127 | 8127 |
表2.10/100M以太网并行分组转发丢包率测试
包长(bytes) | 测试数据(%) | 平均值(%) | |||
5s | 10s | 15s | 20s | ||
64 | 0 | 0 | 0 | 0 | 0 |
128 | 0 | 0 | 0 | 0 | 0 |
256 | 0 | 0 | 0 | 0 | 0 |
512 | 0 | 0 | 0 | 0 | 0 |
1024 | 0 | 0 | 0 | 0 | 0 |
1518 | 0 | 0 | 0 | 0 | 0 |
表3.10/100M以太网并行分组转发的网络时延测试
包长(bytes) | 吞吐量(packets/s) | 此时带宽占用(%) | 测试数据(μs) | 平均值(μs) | |||
5s | 10s | 15s | 20s |
64 | 148810 | 100 | 10.900 | 11.200 | 10.800 | 11.100 | 10.975 |
128 | 84459 | 100 | 15.200 | 15.200 | 15.100 | 15.100 | 15.175 |
256 | 45290 | 100 | 15.000 | 14.800 | 14.900 | 14.900 | 14.888 |
512 | 23496 | 100 | 14.800 | 14.700 | 14.800 | 15.000 | 14.825 |
1024 | 11973 | 100 | 14.900 | 14.800 | 14.900 | 14.800 | 14.788 |
1518 | 8127 | 100 | 16.100 | 16.100 | 16.700 | 16.300 | 16.213 |
根据上表测试所得到的参数,我们可以进行两方面的讨论。
7.1吞吐量分析。
整个系统的测试结果表明,线程间的并发和引擎间的并行分组处理,使系统获得了较好的转发性能,每个端口均达到了线速处理分组能力,时延小,分组丢失率为0。按照我国《高端路由器的测试规范》,该系统的算法设计和实现均是成功的。如果以吞吐量作为性能指标,我们可以算出这种线程间并发、引擎间并行的分组处理,使整个系统获得的性能加速比。我们同时测定,非并行分组处理(单线程单引擎对单端口进行转发)时,其吞吐量的值如表4所示。
表4.单端口单引擎单线程时系统的吞吐量
包长(bytes) | 吞吐量(packets/s) |
64 | 734375 |
128 | 419921 |
256 | 234375 |
512 | 125953 |
1024 | 63016 |
1518 | 42819 |
注:上表中单线程的吞吐量测试是在过100M的链路上进行的
表1-表3中的值是在16端口的情况下单端口的吞吐量。就吞吐量而言,我们定义系统的性能加速比为:
其中,下标L表示分组的长度。
因此,不同包长的情况下,系统获得的加速比为:
从中可以看出,采用多引擎并发式的并行分组处理可以提高系统的处理能力。我们的实现中采用的是六引擎并行分组转发方式,从理论上分析,系统应该获得加速比为6的并行处理能力,但基于下列的一些制约因素,致使系统的性能维持在3以上。
(1)上述设计中引入了必不可少的线程调度,会占用引擎处理机时间,I/O操作的时间往往也较长,因此,当线程进行I/O操作时,通常立刻进行线程的切换;操作完成后再进行唤醒并调度;
(2)由于线程间是并行工作的,但使用的系统资源并不是彼此分离的,对许多资源的访问必须采用互斥的方式进行,如对分组描述符的访问就必须互斥进行,导致某些线程在对公共资源的访问时出现互斥等待的现象发生,从而较低了系统的吞吐量;
(3)对存储器的访问也是一个重要的制约因素。随着系统的吞吐量增加,存储器的制约因素就更加明显;并成为提高系统瓶颈的主要因素;
(4)从64字节的分组到1518字节的分组中,我们可以看出,系统的加速必呈现出减小的趋势,主要原因是,虽然分组数目的增加,导致分组头的处理时间加长,但相比之下小的分组存取时间短,因而性能更优。
(5)线程间的通讯也会占用参与通讯的引擎的处理机的时间,导致它们的工作在一段时间内与分组的收发无关,降低了系统的吞吐量。
7.2性能上的扩展。
文中所介绍的并行分组处理,可以实现100M、16个端口的全线速转发。但在大规模的组网应用上,存在端口密度不够的情形。但我们可以进一步进行并行分组处理的扩展,在系统结构上采用交叉背板(Switch Fabric)相连,文中所述的测试平台作为分组处理线卡的方式进行拓展,即采用分布并行的方式,使系统的并行处理能力进一步加强,如图12所示。图12图示了并行度的扩展。图中所示的扩展规模(即线卡数)受交叉背板容量的制约,扩展的设备可以用在网络核心层上。也就是说,可以采用交叉背板将多个根据本发明的分组转发装置连接在一起,以作为扩展分组转发装置使用。
7.3与非并行处理的对照
相对于非并行分组处理,吞吐量大、时延小、无抖动是本方法中并行分组处理的主要特征。最为主要的是,系统通过并行处理获得了线速分组处理的能力。不论分组的大小,时延均较小,最大平均时延与最小平均时延之差不足6μS,而且在满线速的情况下,分组丢失率为0。另外,简化调度机制,提高分组的处理能力,也是本方法的重要特征。
8.总结
分组转发是构建Internet网络的核心技术。本文首先分析了传统的分组处理方式的弊端,然后提出了一个并行的分组转发方法。文中就分组转发涉及到的数据结构进行了介绍,并就发送和接收分组的具体实现算法进行了详细的描述。着重阐述了多个转发引擎间的并行工作行为和单个引擎上的并发工作模式。线程调度是提高系统性能的关键,文中就发送和接收调度也作了详细的介绍。最后讨论了在该并行转发方法的基础上,设计的系统的性能,主要是测定了系统的吞吐量、时延、带宽和丢包率。测试的结果符合我国《高端路由器的测试规范》。根据测定的参数,计算了并行分组转发方法下系统的加速比,并与理想的并行值进行了对照,分析了两者之间差异的主要原因。由于篇幅的限制,文中对分组缓冲队列的管理、发送队列的调度及QOS的控制等略去。
尽管参考本发明的优选实施例具体展示和描述了本发明,但是本领域一般技术人员应该明白,在不脱离所附权利要求限定的本发明的精神和范围的情况下,可以对其进行形式和细节上的各种修改。
Claims (31)
1.一种分组转发方法,用于将来自至少一个入端口的分组数据从至少一个出端口转发出去,该方法包括:
提供相互分离的控制平面和转发平面,在控制平面中进行系统控制操作,而在转发平面中进行分组转发操作,
在转发平面中提供至少一个并行的转发引擎,每个转发引擎上运行多个线程,所述线程包括至少一个接收线程和至少一个发送线程,
由所述接收线程从所述入端口接收分组;以及
由所述发送线程将所接收到的分组并行发送到出端口。
2.如权利要求1所述的分组转发方法,其特征在于,所述线程还包括接收调度线程和发送调度线程,
当有分组到达入端口时,所述接收调度线程向接收线程分配接收任务;
所述发送调度线程向所述至少一个发送线程轮流分配发送任务。
3.如权利要求2所述的分组转发方法,还包括:
将所述接收调度线程以及所述至少一个接收线程分配在某一引擎上运行;以及
将所述发送调度线程以及所述至少一个发送线程分配在另一引擎上运行。
4.如权利要求1所述的分组转发方法,还包括:
接收线程填写用于描述其所接收到的所述分组的分组描述符;
将同一个出端口发送的分组的分组描述符排成发送队列;以及
发送线程从发送队列中取出分组描述符,以便向出端口发送所述分组描述符所对应的分组。
5.如权利要求1所述的分组转发方法,还包括接收线程通过写消息的方式,向发送线程告知相关的发送事件。
6.如权利要求1所述的分组转发方法,其特征在于,每个线程具有运行、休眠、就绪三种状态。
7.如权利要求1-6中任何一个所述的分组转发方法,还包括在将分组发送到出端口之前,将分组暂存在第一存储器中。
8.如权利要求7所述的分组转发方法,还包括:
对每一个分组提供分组描述符,所述分组描述符与所述分组在第一存储器中的暂存位置相对应;
在向出端口发送所述分组时,使用分组描述符确定所述分组在第一存储器中的暂存位置。
9.如权利要求8所述的分组转发方法,其特征在于,所述分组描述符存储在第二存储器中,所述第二存储器的存取速度比所述第一存储器快。
10.如权利要求9所述的分组转发方法,其特征在于,所述第一存储器为SDRAM,而所述第二存储器为SRAM。
11.如权利要求9所述的分组转发方法,其特征在于,所述分组在所述第一存储器中的暂存位置与所述分组描述符在所述第二存储器中的存储位置之间的对应关系为线性映射关系。
12.如权利要求9所述的分组转发方法,该方法还包括:
在所述第二存储器中存储至少一个分组描述符,每个分组描述符与所述第一存储器上的分组存储位置对应;
使尚未用于描述分组的至少一个空闲分组描述符形成空闲分组描述符队列;
形成发送队列;
在从入端口接收到分组之后,从所述空闲分组描述符队列中取出一个分组描述符,并自动更新所述空闲分组描述符队列的结构;
在将所述分组暂存到所述第一存储器的同时,修改所取出的分组描述符,以反映所述分组的状况;
经查表后,将修改后的分组描述符插入到发送队列中,
13.如权利要求12所述的分组转发方法,还包括为所述每个端口提供至少一个发送队列。
14.如权利要求13所述的分组转发方法,其特征在于所述每个端口的多个发送队列具有不同的发送优先级。
15.如权利要求12所述的分组转发方法,还包括:
当所述发送队列非空时,从发送队列中取出一个分组描述符,并更新发送队列的结构;
在成功地发送了所取出的分组描述符所描述的分组之后,将所述分组描述符回收到所述空闲分组描述符队列中。
16.一种分组转发装置,用于将来自至少一个入端口的分组数据从至少一个出端口转发出去,该装置包括:
控制平面,用于进行系统控制操作;
转发平面,和控制平面相互分离,用于进行分组转发操作,所述转发平面包括至少两个转发引擎,转发引擎包括:
接收线程处理单元,用于产生至少一个接收线程,所述接收线程用
于从所述入端口接收分组;以及
发送线程处理单元,用于产生至少一个发送线程,所述发送线程用
于将所接收到的分组并行发送到出端口。
17.如权利要求16所述的分组转发装置,其中所述转发引擎还包括:
接收调度线程处理单元,用于产生接收调度线程,以在有分组到达入端口时,向对应的接收线程分配接收任务;以及
发送调度线程处理单元,用于产生发送调度线程,以在接收所述分组之后,向所述至少一个发送线程分配发送任务。
18.如权利要求17所述的分组转发装置,还包括线程分配装置,用于将所述接收调度线程以及所述至少一个接收线程分配在某一个引擎上,并将所述发送调度线程以及所述至少一个发送线程分配在另一个引擎上。
19.如权利要求16所述的分组转发装置,还包括:
线程间通信装置,用于形成消息队列,以使所述线程之间可以通过发送消息的方式互相通讯。
20.如权利要求19所述的分组转发装置,其特征在于,所述线程间通信装置响应所述接收线程的指令,向消息队列写入用于告知相关的发送事件的消息,并由发送线程读取。
21.如权利要求16所述的分组转发装置,还包括:
用于产生描述所接收到的分组的分组描述符的装置;
用于将描述要由同一个端口发送的分组的分组描述符排成发送队列的装置;
用于检测发送队列是否为空的装置;以及
用于在发送队列非空时,从发送队列中取出分组描述符,以便向出端口发送所述分组描述符所描述的分组的装置。
22.如权利要求16-21中任何一个所述的分组转发装置,还包括第一存储器,用于在将分组发送到出端口之前暂存所述分组。
23.如权利要求22所述的分组转发装置,还包括:
第二存储器,其上存储了至少一个分组描述符,用于描述接收到的分组,所述分组描述符与所述分组在第一存储器中的暂存位置相对应;
用于在向出端口发送所述分组时,使用分组描述符确定所述分组在第一存储器中的暂存位置的装置。
24.如权利要求23所述的分组转发装置,其特征在于,所述第二存储器的存取速度比所述第一存储器快。
25.如权利要求24所述的分组转发装置,其特征在于,所述第一存储器为SDRAM,而所述第二存储器为SRAM。
26.如权利要求23所述的分组转发装置,其特征在于,所述第一存储器中暂存所述分组的位置与所述第二存储器中存储所述分组描述符的位置之间的对应关系为线性映射关系。
27.如权利要求23所述的分组转发装置,还包括:
用于使尚未用于描述分组的至少一个空闲分组描述符形成空闲分组描述符队列的装置;
用于形成发送队列的装置,所述发送队列由用于描述分组的分组描述符组成;
用于在从入端口接收到分组之后,从所述空闲分组描述符队列中取出一个分组描述符,并更新所述空闲分组描述符队列的结构的装置;
用于将所述分组暂存到所述第一存储器中与用来对所述分组进行描述的分组描述符相对应的暂存地址的装置;
用于修改所取出的分组描述符,以描述所述分组的装置;
用于将修改后的分组描述符插入到发送队列中的装置。
28.如权利要求27所述的分组转发装置,其特征在于,所述用于形成发送队列的装置为所述至少一个入端口中的每一个提供了至少一个发送队列。
29.如权利要求28所述的分组转发装置,其特征在于所述各个发送队列具有不同的优先级。
30.如权利要求27所述的分组转发装置,还包括:
用于在所述发送队列非空时,从发送队列中取出一个分组描述符,并更新发送队列的结构的装置;
用于在成功地发送了所取出的分组描述符所描述的分组之后,将所述分组描述符回收到所述空闲分组描述符队列中的装置。
31.一种扩展分组转发装置,包括:
至少一个如权利要求16所述的分组转发装置;以及
交叉背板,用于连接所述至少一个分组转发的装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA200410031867XA CN1677952A (zh) | 2004-03-30 | 2004-03-30 | 线速分组并行转发方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA200410031867XA CN1677952A (zh) | 2004-03-30 | 2004-03-30 | 线速分组并行转发方法和装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN1677952A true CN1677952A (zh) | 2005-10-05 |
Family
ID=35050264
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA200410031867XA Pending CN1677952A (zh) | 2004-03-30 | 2004-03-30 | 线速分组并行转发方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1677952A (zh) |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008148330A1 (fr) * | 2007-06-07 | 2008-12-11 | Huawei Technologies Co., Ltd. | Système et procédé d'acheminement de données |
CN101136854B (zh) * | 2007-03-19 | 2010-08-18 | 中兴通讯股份有限公司 | 一种实现数据包线速处理的方法和装置 |
CN101282303B (zh) * | 2008-05-19 | 2010-09-22 | 杭州华三通信技术有限公司 | 业务报文处理方法和装置 |
CN101594201B (zh) * | 2009-05-20 | 2012-05-23 | 清华大学 | 链式队列管理结构整合错误数据过滤的方法 |
CN103366471A (zh) * | 2013-06-26 | 2013-10-23 | 福建联迪商用设备有限公司 | 一种联机业务并发处理方法、系统及服务器 |
WO2015062536A1 (en) * | 2013-11-01 | 2015-05-07 | Hangzhou H3C Technologies Co., Ltd. | Data processing |
US9112708B1 (en) * | 2012-01-27 | 2015-08-18 | Marvell Israel (M.I.S.L) Ltd. | Processing multicast packets in a network device |
US9571541B1 (en) | 2013-10-03 | 2017-02-14 | Marvell Israel (M.I.S.L.) Ltd. | Network device architecture using cache for multicast packets |
WO2017032178A1 (zh) * | 2015-08-27 | 2017-03-02 | 深圳市中兴微电子技术有限公司 | 一种校验和的计算方法、网络处理器及计算机存储介质 |
CN106506392A (zh) * | 2016-12-19 | 2017-03-15 | 深圳创维数字技术有限公司 | 一种网络拥塞处理方法及装置 |
CN104584504B (zh) * | 2013-08-26 | 2017-09-26 | 华为技术有限公司 | 数据面的特性配置方法和装置 |
CN108809854A (zh) * | 2017-12-27 | 2018-11-13 | 北京时代民芯科技有限公司 | 一种用于大流量网络处理的可重构芯片架构 |
CN108833299A (zh) * | 2017-12-27 | 2018-11-16 | 北京时代民芯科技有限公司 | 一种基于可重构交换芯片架构的大规模网络数据处理方法 |
CN109565455A (zh) * | 2016-06-02 | 2019-04-02 | 马维尔以色列(M.I.S.L.)有限公司 | 具有高速缓存的分组存储器中的分组描述符存储 |
US10367758B2 (en) | 2016-09-12 | 2019-07-30 | Marvell World Trade Ltd. | Merging read requests in network device architecture |
CN111614758A (zh) * | 2020-05-20 | 2020-09-01 | 浩云科技股份有限公司 | 一种码流转发方法、装置、可读存储介质及计算设备 |
-
2004
- 2004-03-30 CN CNA200410031867XA patent/CN1677952A/zh active Pending
Cited By (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101136854B (zh) * | 2007-03-19 | 2010-08-18 | 中兴通讯股份有限公司 | 一种实现数据包线速处理的方法和装置 |
WO2008148330A1 (fr) * | 2007-06-07 | 2008-12-11 | Huawei Technologies Co., Ltd. | Système et procédé d'acheminement de données |
CN101282303B (zh) * | 2008-05-19 | 2010-09-22 | 杭州华三通信技术有限公司 | 业务报文处理方法和装置 |
CN101594201B (zh) * | 2009-05-20 | 2012-05-23 | 清华大学 | 链式队列管理结构整合错误数据过滤的方法 |
US9112708B1 (en) * | 2012-01-27 | 2015-08-18 | Marvell Israel (M.I.S.L) Ltd. | Processing multicast packets in a network device |
CN103366471A (zh) * | 2013-06-26 | 2013-10-23 | 福建联迪商用设备有限公司 | 一种联机业务并发处理方法、系统及服务器 |
CN104584504B (zh) * | 2013-08-26 | 2017-09-26 | 华为技术有限公司 | 数据面的特性配置方法和装置 |
US10015100B1 (en) | 2013-10-03 | 2018-07-03 | Marvell Israel (M.I.S.L.) Ltd. | Network device architecture using cache for multicast packets |
US9571541B1 (en) | 2013-10-03 | 2017-02-14 | Marvell Israel (M.I.S.L.) Ltd. | Network device architecture using cache for multicast packets |
CN104618304A (zh) * | 2013-11-01 | 2015-05-13 | 杭州华三通信技术有限公司 | 数据处理方法及数据处理系统 |
CN104618304B (zh) * | 2013-11-01 | 2017-12-15 | 新华三技术有限公司 | 数据处理方法及数据处理系统 |
WO2015062536A1 (en) * | 2013-11-01 | 2015-05-07 | Hangzhou H3C Technologies Co., Ltd. | Data processing |
WO2017032178A1 (zh) * | 2015-08-27 | 2017-03-02 | 深圳市中兴微电子技术有限公司 | 一种校验和的计算方法、网络处理器及计算机存储介质 |
CN106484503B (zh) * | 2015-08-27 | 2019-10-18 | 深圳市中兴微电子技术有限公司 | 一种校验和的计算方法及网络处理器 |
CN106484503A (zh) * | 2015-08-27 | 2017-03-08 | 深圳市中兴微电子技术有限公司 | 一种校验和的计算方法及网络处理器 |
CN109565455A (zh) * | 2016-06-02 | 2019-04-02 | 马维尔以色列(M.I.S.L.)有限公司 | 具有高速缓存的分组存储器中的分组描述符存储 |
CN109565455B (zh) * | 2016-06-02 | 2023-09-26 | 马维尔以色列(M.I.S.L.)有限公司 | 具有高速缓存的分组存储器中的分组描述符存储 |
US10367758B2 (en) | 2016-09-12 | 2019-07-30 | Marvell World Trade Ltd. | Merging read requests in network device architecture |
US11032216B2 (en) | 2016-09-12 | 2021-06-08 | Marvell Asia Pte, Ltd. | Merging read requests in network device architecture |
CN106506392A (zh) * | 2016-12-19 | 2017-03-15 | 深圳创维数字技术有限公司 | 一种网络拥塞处理方法及装置 |
CN108833299A (zh) * | 2017-12-27 | 2018-11-16 | 北京时代民芯科技有限公司 | 一种基于可重构交换芯片架构的大规模网络数据处理方法 |
CN108809854A (zh) * | 2017-12-27 | 2018-11-13 | 北京时代民芯科技有限公司 | 一种用于大流量网络处理的可重构芯片架构 |
CN108809854B (zh) * | 2017-12-27 | 2021-09-21 | 北京时代民芯科技有限公司 | 一种用于大流量网络处理的可重构芯片架构 |
CN108833299B (zh) * | 2017-12-27 | 2021-12-28 | 北京时代民芯科技有限公司 | 一种基于可重构交换芯片架构的大规模网络数据处理方法 |
CN111614758A (zh) * | 2020-05-20 | 2020-09-01 | 浩云科技股份有限公司 | 一种码流转发方法、装置、可读存储介质及计算设备 |
CN111614758B (zh) * | 2020-05-20 | 2023-05-02 | 浩云科技股份有限公司 | 一种码流转发方法、装置、可读存储介质及计算设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1677952A (zh) | 线速分组并行转发方法和装置 | |
CN1467965A (zh) | 分组处理装置 | |
CN1309224C (zh) | 信息包通信装置、系统及模块、数据处理器及转送系统 | |
CN101069161A (zh) | 调度方法、调度装置和多处理器系统 | |
CN102904871B (zh) | 流分配 | |
CN1272946C (zh) | 可伸缩的网络处理器及操作该网络处理器的方法和装置 | |
CN1148687C (zh) | 用于网络处理器的全匹配搜索方法和设备 | |
CN1204509C (zh) | 通信网络装置 | |
CN1201242C (zh) | 数据传送控制装置和电子装置 | |
CN1256681C (zh) | 从外围设备向主计算机系统传输中断的方法和装置 | |
CN1993674A (zh) | 多芯架构中的资源管理 | |
CN1204503C (zh) | 用于通信网络的装置、系统及其操作方法 | |
CN1432243A (zh) | 数据包丢弃 | |
CN1282094C (zh) | 数据传送控制装置及数据传送控制方法 | |
CN1750485A (zh) | 网络仿真测试系统及方法 | |
CN1402845A (zh) | 多线程并行处理器结构中所用的微引擎的存储器引用指令 | |
CN1925462A (zh) | 高速缓存系统 | |
CN1473300A (zh) | 智能网络存储接口系统和装置 | |
CN1910870A (zh) | 负载分散方法、节点和控制程序 | |
CN1695127A (zh) | 网络接口和协议 | |
CN1356831A (zh) | 用于支持服务质量保证的缓冲区管理和在数据交换中的数据流控制 | |
CN1698337A (zh) | 利用卸载单元处理tcp连接数据 | |
CN1859275A (zh) | 多端口以太网交换装置及数据传输方法 | |
CN1533102A (zh) | 数据分组通信设备 | |
CN1211128A (zh) | 短信元复用器 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |