如何将higig口配置成rxaui xaui接口

高速网络中用于可重新配置的位流处理的全协议引擎的制作方法
专利名称高速网络中用于可重新配置的位流处理的全协议引擎的制作方法
技术领域本发明大体而言涉及网络中的数据通信领域。更具体而言,本发明涉及一种可 配置的、与协议无关的位流处理引擎,以及涉及相关的系统和数据通信方法,其适 用于以至少每秒钟10吉位的速度运行的高速网络。
背景技术传统上,己基于给定网络的用途将网络划分为不同种类的基础设施或架构。因 此,己针对存储器网络、通信网络和处理器网络开发了不同种类的网络,每一种网 络都具有不同的协议和不同的网络要求,且每一种网络都经设计以满足在该架构内 进行数据通信的特定要求。
4对于处理器网络,网络性能是高性能集群计算(high-performan HPCC)应用中的关键要素。通常,高性能集群计算应用长时间运行, 且需要在各处理器之间以及客户机和服务器之间通过网络持续地输入/输出(I/O) 大数据集。可预计地,基础设施必须能够支持数吉位带宽、低延时、可用率极大的 服务,这些都是高端集群进程间通信的绝对需求。按照惯例,高性能集群计算网络 利用交换式吉位以太网。诸如Myrinet、 InfiniBand和Quadrics等专用协议在连 接高性能集群计算环境下的处理集群中也具有广泛的用途。
对大量数据的需求使得有必要将高性能集群计算应用中的联网处理器(例如) 有效地连接到存储器网络架构。按照惯例,高性能集群计算支持基础设施包括存储 器附连网络(stor SAN)交换架构或基于吉位以太网的网 络附连存储存(netw NAS)环境。由于具有针对在客户机 和存储器装置之间移动大量块存储器数据而最优化的数吉位速度和传输协议,光纤 信道是存储器附连网络架构的主要协议和传输信道。
互联网协议(Internet P IP)通信网络往往是在不同的高性能集群 计算应用之间通信以及通过更广泛的因特网架构在客户机和服务器之间进行一般 通信的主要架构。 一些存储器网络己采用适用于通过互联网协议存储器网络(如因 特网SCSI (iSCSI)、因特网光纤信道协议(iFCP)、基于互联网协议的光纤信 道(FCIP))移动块存储器数据的搭载协议(piggyback protocols)。然而,这 些搭载协议不一定允许在通信网络和存储器网络之间进行直接的互操作。
在这些不同种类的网络架构之间提供架构间互操作的目标是众所周知的目标。 尽管在网络中所需的所有处理均可利用标准的可编程处理器来完成的低速网络中 肯定可实施该目标,但此解决方案在以每秒钟10吉位和更高速度运行的高速网络 所需的高通信速度下绝对不可行。在多数情况下,已采用专用适配器在架构上的具 体协议与中央交换机节点的普通协议之间进行转换。尽管本方法对终端用户而言可 能是透明的,但所属领域.的技术人员易于理解,该适配器修补工作会在数量不断增 长的协议方面带来指数性爆炸问题。在至少部分网络设备制造商看来,提供能够处 理多个协议的高速网络交换机是不可能的解决方案。Silvano Gai,"关于用于 L AN/WAN/WLAN/S AN交换机和路由器的统一架构"第23页,HSPR2003,CiscoSystem 公司(注意,尚不具备10吉位/秒的廉价LAN交换机)。因此,人们需要找到一种 解决方案来实现在网络之间提供架构间互操作的目标,该解决方案对高速网络而言 既高效、又可扩展。
本发明提供一种可重新配置的与协议无关的位流处理引擎,以及相关的系统和 数据通信方法,所述可重新配置的且与协议无关的位流处理引擎以及相关的系统和
数据通信方法适合于实现在以至少每秒钟10吉位的速度运行的高速网络之间提供
架构间互操作的目标。位流处理引擎作为全协议、多级处理器运行,其能够配置用 于合适的交换机和相关的网络组件,以形成不仅使在现有的通信协议之间有可能进 行互操作、而且能够适应未来的协议的无缝网络架构。本发明的方法和系统适用于 包括存储器网络、通信网络和处理器网络的网络。
在本发明的一个实施例中,全协议处理引擎作为数据流处理引擎运行,其包括 入口部分和出口部分两者,每一部分均带有至少一个位流级处理器。较佳地,每一 级处理器都针对数据流中的某一特定级进行最优化。从概念上讲,数据流处理引擎
的工作非常类似于生产装配线当数据流移动通过处理引擎时,在该装配线的不同 阶段完成不同的处理,且所有处理都相对于数据流定时。对通过处理引擎的数据流 确定一个速率,该速率允许处理引擎以与处理引擎相连的网络的线速度连续运行。 在本实施例中使用的数据流模型避免了在传统的协议处理器中所需要的为跟踪数 据所需的密集、广泛的缓冲器管理需求。另外,任何级中的引擎均固有地可级联, 以支持可扩展性。
在全协议处理引擎(omini- OPE)的一个实施例中,多级包 括至少一入口级位流处理器、 一辅助级状态机、 一讯务处理器、 一调度器和一出口 级位流处理器。入口级位流处理器与数据流的物理层介接,并根据针对位流确定的 协议来确定位流的帧及/或流量。辅助级状态机根据所确定的协议、较佳利用以流 水线方式产生密钥的可编程超长指令字(VLIW)流量分类器对所述帧/流量进行剖 析。讯务处理器进行帧/流量处理。调度器管理来自讯务处理器的数据流输出,且 出口级位流处理器与来自全协议处理引擎的数据流的物理层介接。所有级都可动态 重新配置和重新编程,以使全协议处理引擎与协议无关。
在一个实施例中,辅助级状态机和讯务处理器使用新型密钥査找布置,以提高 全协议处理引擎的效率。讯务处理器可实施为多区段数据流处理器布置,其中讯务 处理器中的各区段取决于帧/流量的给定协议进行实施。在讯务处理器的实施例中, 多区段数据流处理器实施裁决及/或时分多路复用(TDM)方法来访问帧的数据流/ 流量所驻留的公用共享缓冲存储器。通过这种方式,,每一数据流处理器不需要将帧/流量中的部分或所有数据复制到该处理器内的内部缓冲器中以处理该数据。另外, 数据流处理器可通过级抽象和时钟抽象两者而级联并可扩展。
在本发明的一个实施例中,使用与一个SPI4.2数字交换机介接的四个全协议
处理引擎来实施全协议、48端口、非闭锁QoS吉位交换机。在本实施例中,每一 全协议处理引擎都与12个SerDes端口介接以进行外部连接,且与3个SPI 4.2 端口介接以连接到SPI4.2数字交换机。当定位在存储器网络、高性能集群计算处 理器集群、内部网和因特网通信网络的中间时,所述交换机有效地用作一统合架构 (convergent fabric),其允许在任何和所有上述网络之间进行与协议无关的网 络连接。本发明的该实施例提供一种智能型交换解决方案,其中,交换机即时可编 程且可重新配置,使每一包都能够根据即时重新编程/重新配置的全协议处理引擎 被不同地处理(即,例如以10 Gbps的速度100%地逐个包路由),所述全协议处 理引擎包括"端口处理器"或形成中央交换机架构的数字交换机。通过这种方式, 该交换解决方案提供高性能(每个端口带宽aOGbps)、低延时(交换&5|^)、与 协议无关、基于策略的交换,所述交换可扩展到数千个节点、与现有网络基础设施 彼此协作,并以成本有效的方式提供telco可靠性/容错能力(即99,999%的可用 率)。
在本发明的另一实施例中,全协议处理引擎和相关联的网络组件都可使用带有 图形用户界面管理系统的寄存器访问控制和子模块访问控制布置进行动态重新配 置和编程,所述管理系统管理代码产生、流量控制、性能描绘和统计,以及系统的 诊断和维护。在一个具体实施例中,图形用户界面管理系统包括实际上进行系统设 计的模块、能够以"所见即所得"的方式对设计好的架构的预期性能进行仿真的仿 真引擎和产生微代码以对全协议处理引擎和任何其它可重新编程/重新配置的网络 装置(如果需要)进行重新编程的代码产生器(微代码管理器)。
图1A和1B为根据本发明的一个实施例的全协议引擎的功能方框图; 图2为图1的全协议处理引擎的入口数据流的更详细方框图; 图3为实施为图2所示的入口数据流之一部分的包状态机的状态图; 图4为图1的全协议处理引擎的出口数据流的更详细方框图; 图5和6为包括根据本发明的一个实施例的多级引擎的初始部分的前置处理器 包成帧系统的简要表示;图7为实施前置处理器的根据本发明的位流级处理器的一个实施例的方框图;
图8A和8B为来自XGMII的通用以太网格式和以太网的通用格式的简图; 图9-11为多级全协议处理引擎的所选部分的简图; 图12为本发明的一个实施例的可编程状态机的简图; 图13为图12的可编程状态机的示例性可扩展表;
图14为图12的可编程状态机的示例性状态图; 图15为可编程解码表的示例性表;
图16显示前置处理器成帧器的基本功能的更完整的图式;
图17图解说明增加输入选择及使状态内具有子状态的能力的方法;
图18图解说明扩展来自状态机的输出控制的方法;
图19显示可由状态机选择的掩码比较逻辑;
图20是可由该状态机编程的以太网流程图实例;
图21是根据本发明的一个实施例的总流程控制的方框图22是图解说明运行寄存器访问控制/子模块访问控制器以监视和控制全协
议处理引擎的互连级的运行的简图23是在根据本发明的入口装置处遇到的标准以太网帧的简图24和25是显示根据本发明的一个实施例的可编程状态机和掩码和比较电路
的运行配置的简要表示;
图26简要绘示根据本发明的一个实施例的示例性帧分类器。 图27图解说明根据本发明的一个示例性实施例在反馈回路内运行的级0和级 1引擎;
图28是根据本发明的具体实施例的可扩展帧处理器的简图,其中所述帧处理 器包括P-SerDes和核心引擎;-
图29、 30和31简要绘示带有本发明的全协议引擎的HPC端口卡; 图32是使用第三方FPGA以实施交换架构的示例性交换机的实施例; 图33是根据本发明的通用实施例的交换机的简图34A和34B是图解说明根据本发明的具体实施例的ATMCA mTCA粗管道交换 机的简图35A和35B是示例性编程模型和环境;
图36A和36B显示描绘根据本发明的主要实施例的搁架管理控制器的方框图; 图37A图解说明根据本发明的示例性I2C硬件有限状态机实施方案;
8图37B是图解说明使用不同的接口桥接装置的示例性实施方案的方框图38图解说明根据本发明的一个实施例的位流协议处理器的一个实施例的方 框图39图解说明根据本发明的一个实施例的位流协议处理器的另一实施例的方 框图40是根据本发明的一个实施例的数据流布置的方框图;以及 图41是本发明各种0SI层的抽象的方框图。
具体实施例方式
本发明包括斥于网络中的线速数据路径处理的新型装置、系统和方法。图1A 图解说明根据本发明的系统的一个实施例的方框图。本实施例的中心是全协议引 擎。全协议处理引擎是一种与协议无关的位流、多级处理器,其包括双重功能1) 将位流中的各位根据相关的协议汇编到适当界定的协议数据单元中;及2)对汇编
好的协议数据单元进行处理以无论遇到什幺协议都提供线速吞吐量。与现有技术中 流行的专用适配器不同,全协议处理引擎中的所述两个功能都是动态可编程的。因 此,给定协议的任一或两个协议数据单元或适用于协议数据单元的处理规则都可以 动态的方式改变。
除非另有说明,否则本发明中的术语"协议"系指具有界定的控制位和数据或 信息位(其可为空)分组的序列化包通信协议,所有控制位和数据或信息位都遵循 一组标准的指令或规则。表1提供了根据本发明的全协议引擎的一个实施例的某些 属性的摘要。表1
属性详细说明
1即时(on-the-fly)可编 程性例如,在进程中重新定义机器指令集
2可编程/动态多协议支持"标准"和"增强"以太网 IPv4, IPv6, MPLS Infinibsnd 高级交换/PCI-Express 光纤信道 SONET/ATM 用户定义的、定制协议
3可编程更高层特征层2至层4可编程类别 使用老化规则支持1M流量到64Kbps量化度 可编程讯务管理、成型和控制 协议封装 VLAN、 VSAN、 VCAN支持流量控制、拥塞管理
4应用支持灵活TCP/IP卸载 iSCSI、 iSER、 R腿 MPLS、 DiffServ
5工业标准MIB工业标准管理信息基础,即一组符合因特网标 准MIB II或其它因特网标准MIB的变量。MIB II可见于RFC 1213 "Management Information Base for Network Management of TCP/IP-based Internets: MIB-II"中。
如图1B所示,全协议处理引擎是多级处理器布置,其中其包括多个独特的处 理块。针对全协议流量处理功能对每一块进行最优化。每一处理块沿数据路径提供
"门"以便以线速进行更多的处理。"门"接口使用高速串行i/o信道和高速并行
信道两者来满足处理块的延时要求。每一处理块的状态、特征和功能参数较佳地可 如下文中所述"实时"编程。因此,全协议处理引擎既可重新编程,又可重新配置。
参见图41,在基本层上,可在组成部分、各部分之间的数据流相关性和改变 所述数据流相关性的控制结构方面对每个级或处理块进行抽象化。在最高抽象层,
10每一级都实施通用接口 ,该通用接口实施控制结构,以使级能够接收输入包流对象, 并输出处理后的包流对象以及与输入和处理后的包流中任一者或两者相关联的元 数据对象。每一级都是基本类别中的一个成员。每个基本类别实施一个接口,所述 接口由针对所述基本类别实施的方法集规定。在中间抽象层,可通过增加额外模块 来扩展每个基本类别,所述额外模块对基本类别的功能进行扩展并形成一个子类。 每一子类实施其自己的子类接口 ,该子类接口提供额外的方法来扩展基本类别方法 的功能。在最低的抽象层,可通过提供其它方法及/或通过增加子模块以提供基本 类别中不存在的部分来进一步扩展子类提供的接口。通过改变方法和该方法将作用 的对象可重新配置类及其子类。通过这种方式,可对位流处理器的每一级通过编程 进行重新配置,以提供有差异的资源和服务。通过这种方式,将各个级配置成带有 与协议无关的架构的数据(包)流机器。
将帧定义为位流,其中每一和每个位的含义由一个或多个预定义的协议成帧规 则界定。抽象模型具有将输入接受作为位流的方法。每一和每个位的含义由方法进 行抽象,以使每一级能够接收位流。协议处理由另一方法界定,所述方法基于定位 在位流中任何位置的位流的一个或多个位中的信息来执行一组操作。可实施的任何 类或子类,(例如方法)可潜在地执行协议处理步骤。在一替代实施例中,每一类或 子类经编程以通过在由所述类或子类提供的通用接口内实施方法来处理特定的协 议。因此,能够将所述实施方案的细节"隐藏"在一种或多种方法的后面,以便能 够重新使用代码和部分。抽象的结果是数据流架构实质上是一系列铺设的管道, 可预测的延时级经布置为使给定级内的处理在包间间隔时间内(即,在下一个包到 达之前)完成。
对每一级进行抽象使得有可能向每一级增加一个或多个流水线子级。一级流水 线内的每一子级在等于包到达时间除以一级内的子级的数量的时间内完成对包的 操作。因此,第一级可包含实施用于包解码(即,其产生有关数据包的元数据)的 方法的子类。元数据可包含有关输入包流内的取决于特定协议的位模式的位置的信 息。在这方面,包解码器对帧(界定的位流)进行"分析"。注意,本文中所用的 术语"实施"表示在一个或多个固件和硬件方面的实施方案。可使用实施上述基本 功能的任何固件、硬件或固件-硬件组合来实施上述方法。例如,可将包解码级实 施为带有比较加速器的可编程状态机。在给定一种协议类型时,可编程状态机提取 级处理器进行(例如)地址査找所需的包内的字段。包解码器进行层2/层3/层4 剖析,以从所述三层的报头中提取信息。因此,可对实施该功能的方法进行定制,以处理所述三层的协议,且因此扩展了基本类别。
在一个实施例中,数据流处理引擎的入口部分和出口部分中每一个都具有与多端口数据流包存储器介接的多个位流级处理器。每一位流级处理器都提供有独特的指令存储器。在一个实施例中,第一交换机总线连接在数据流包存储器与交换接口和处理器接口之间,且第二交换机总线连接在数据流包存储器和多个位流级处理器之间。在本实施例中,第三交换机总线连接在多个位流级处理器和公共存储器接口之间。公共存储器接口可与外部存储器或与内容可寻址存储器(Content-addressable-M CAM)接口连接。
在一个实施例中,全协议处理引擎支持最常遇到的协议所需的一组普通处理块。通过增加专有的可编程、多功能处理块可实施额外的功能,如计算密集型协议处理。这些计算处理块还能够具有"即时"可编程性,从而赋予全协议处理引擎在任何协议环境下运行所需的可扩展性,而不会引起现有技术在试图达到统合式网络架构时所特有的成本类型或性能损失。事实上,通过提供多协议处理功能,亦即,能够将计算中心的不同组件组合到一起而不需在不同的高速协议之间使用网关和交换机,全协议处理引擎能够实现统合架构。全协议处理引擎解决方案在0SI第2-7层上工作。
在一个实施例中,较佳地利用名称为"用于对可编程电路进行图形编程的方法和装置"的美国专利第6, 671, 869号中所述的基于图形用户界面的代码产生器来对全协议处理引擎的处理块进行编程,美国专利第6, 671, 869号中所揭示的内容以引用的方式并入本文中。显示协议模板,将对具体子段的操作拖放到操作工具,由此系统产生"通信引擎代码"。另外,图形用户界面以"所见即所得"的方式显示引擎的预期性能。系统向用户提示为获得最大的性能所需的操作。在芯片环境中,使用这些功能来选择适当的链接速度。在可编程平台环境,例如FPGA中,可选择更大容量的芯片。
在如图35A和35B中图解说明的该基于图形用户界面的代码产生器的具体实施例中,显示协议模板,并将对具体字段的操作拖放到操作工具。系统产生"通信引擎代码"并以"所见即所得"的方式显示引擎的预期性能。该系统向用户提示为获得最大的性能所需的操作。在芯片环境中,可使用这些功能来选择适当的链接速度。在可编程平台环境(例如先前的FPGA实例)中,可选择更大容量的芯片。
可通过例如现场可编程门阵列结合一个或多个共享公共局部总线的通用目的处理器(CPU)来提供"即时"功能。在名称为"可重新配置的网络接口架构"的美国专利第6, 721, 872号中揭示了一种这样的方法,所述美国专利的揭示内容以引用的方法并入本文中。在美国Cambridge, MA 02139,麻省理工学院媒体实验室(MITMedia Lab)的Bove Jr等人所着的"使用微处理器的局部总线上的现场可编程门阵列进行媒体处理"中描述了一种提供所述"即时"功能的替代方法,所述文件中揭示的内容以引入的方式并入本文中。 .
现在参见图2,将描述图1中所示的全协议处理引擎的"入口运行"的一个实施例。端口统合涉及到PHY和MAC装置所特有的物理层协议成帧以及将具体媒体的包数据转换为SPI4. 2突发帧。将来自多个端口的小SPI4. 2突发以循环、时分多路复用的方式传递到SPI4. 2引擎。基于统合的端口数量将SPI4. 2信道划分为时隙;8端口统合器将SPI4. 2信道划分为8个相等的部分。在总线上为不工作或没有数据供传输的槽口 /端口产生空闲的突发。
本实施例中的MAC装置是8xlGbE MAC芯片("MAC芯片")。以称为"突发交错(burst-interleaved)"的模式对MAC芯片进行配置,"突发交错"模式意味着以循环(端口 0到端口 9)的方式对来自每个1GbE的以太网包数据的可配置字节数量(例如,32字节)予以调度,以传输到SPI-4.2接口。然后,对来自1GbEMAC的突发(burst)进行交错并在SPI-4. 2总线上进行传输。小突发(小于32个字节的突发)可能位于包起点和结束定界符处。由MAC芯片对以太网包执行的操作包括(1)剥除前同步码和帧起点定界符(Start of Frame D SFD);及(2)保持FCS。
SPI-4. 2引擎较佳地包括提供SPI-4. 2引擎的实质性功能的核心,所述实质性功能将SPI-4. 2成帧转换为类似于SPI4. 1的内部成帧格式。数据从SPI4. 2以16位突发到达,突发的第一个16位字包含控制字,所述控制字包含有关突发的信息;包括突发是包的起点、包的结束还是包的接续,以及产生突发的信道号。将来自信道的高达8个16位数据字汇编成64位字并进行传递,同时将16位控制字转换为"内部路由标记"。
在本实施例中,当帧移动通过转发逻辑时,"内部路由标记"连同包突发数据在内部总线上传递。"内部路由标记"包含表示"数据有效"的1位、表示"包起点"的1位、表示"包结束"的1位、表示"数据错误"的1位、表示突发大小的3位(0-7分别指示突发大小为1-8)以及表示"信道地址"的3位。"信道地址"指示与突发相关联的端口。在另一个实施例中,"内部路由标记"可基于网络层优先级或VLAN指定的优先级而包括Q0S/C0S信息。
13帧处理器进行帧处理时需要识别网络包的有趣特性。这些特性包括目标地址和
源地址、包类型、层3和层4数据报以及会话寻址。另外,帧处理器对转发逻辑处理的每一包维持一状态机。
如图3所示,"包状态机"跟踪数据流的组成。对于HPC解决方案,数据流由包数据的多个突发组成,所述多个突发将基于SPI4.2控制字中的位字段分类。为在SPI4. 2接收或从SPI4. 2传输的每个包例示了一个包状态机。当认定"SPI有效(PACKET—VALID)"信号时,包进入"有效"状态。当认定"SPI包起点"信号时,包进入"包起点"状态,且"SPI包结束"导致跃迁到"包结束"状态。如果错误状态指示错误,则状态机进入ERROR状态,否则状态机跃迁到INIT。
再参见图2,剖析引擎(剖析器)的任务是利用帧处理器提供的信息来构建多字节组分类器密钥。在一个实施例中,产生"分类器密钥"仅需要目标地址。在替代实施例中,可增强"查找引擎",以在构建"分类器密钥"时还包括任何数量的包特性,从而当交换机转发单个包或包流时修改交换机的性能。
通过使用剖析器产生的"分类器密钥","査找引擎"将杂乱进入转发内容可寻址存储器,以査找出口目标端口。出口目标端口放置在"内部路由报头"中。在一个实施例中,"内部路由报头"完全由出口端口号组成。或者,"内部路由报头"可包括其它信息。诸如基于S廳P的管理站等管理实体将可访问转发内容可寻址存储器条目。
"讯务导向器"负责基于在"内部路由报头"发现的端口地址向CPU转发及/或复制帧。在转发逻辑和FPGA中的微处理器之间提供合适的接口逻辑。
"排队引擎"负责处理交换机架构与"端口卡"的帧处理逻辑之间的数据流。"排队引擎"在8端口卡交换机中包含交换机架构中每一 1GbE MAC的虚拟队列,该8端口卡交换机中将其相加成多个虚拟队列。每一虚拟队列很大,足以容纳多个大型(9K)包。为每一虚拟队列维持一个索引,以跟踪下一 64位数据将放置在虚拟队列中的哪个位置,所述索引称为VQ排队索引。查询VQ出队列(VQ dequeue),以确定需要传递给调度器的下一64位数据。于是,将来自"讯务导向器"的数据以VQ出队列索引指示的偏移放入目标端口的VQ中。相反,使用VQ出队列索引来确定将哪个数据传递给调度器。"排队引擎"还提供交换机架构与"虚拟队列"之间的"速率变化"FIF0,以及显示交换机架构与转发逻辑之间的背压的流量控制机制。
在传递帧至交换机架构时,调度器使用"排队引擎"的出队列机制。以循环的方式(从端口 0到端口 31)对将要传递到交换机架构的帧进行调度。出队列涉及在"XAUI核心"将帧转换为XAUI之前封装XGMII中的帧。在转换期间,使用"内部路由标记"和"内部路由报头"。
现在参见图3,将描述全协议处理引擎的"出口运行"的一个实施例。"排队引擎"提供位于入口相反侧的出口一侧的排队。"XAUI核心"将来自交换机架构的XAUI帧转换为XGMII。基于XGMII帧中的端口号将XGMII帧排队到"虚拟队列"中。
调度器以与入口非常相似的方式完成入口调度。以循环的方式使帧出队列,但必须将出口数据帧转换为局部总线接口,并产生"内部路由标记"。在一个实施例中,调度器设计为自适应和探试式,以便仅通过查找广播并使用源地址更新内容可寻址存储器来减少带外转发内容可寻址存储器更新。
图4中所示的出口 SPI4. 2转换与入.口相反。使用专有核心将局部成帧格式转换为SPI4.2。出口端口统合涉及将SPI4.2帧突发数据汇编到媒体包中,并通过SPI4.2帧突发数据的寻址出口接口将其传输出去。这些接口也较佳地为上文中所述的MAC芯片。出口的运行与入口相反。来自SPI-4.2的以太网包数据以交错的以太网包数据突发(端口0到端口9)接收到出口FIFO内。当出口FIFI接收到5个突发时(或者取决于包长度当EOP到达时),出口 FIFO将启动向1GbEMAC的传输。较佳地,出口帧处理还维持端口状态机,所述端口状态机执行帧状态检查,例如帧老化、VLAN报头剥除、内部转发报头移除以及类似操作。由MAC芯片对以太网包执行的操作包括(1)增加前同步码;及(2)增加帧起点定界符(SFD),以及可选的(3)增加FCS。
在图5和6中图解说明的示例性实施例中,全协议处理引擎提供所选的取名为级0、级1、级2…级n的流水线化级引擎序列。取决于是针对哪一个功能配备的全协议处理引擎,每一级引擎可具有不同的、可扩展的和可重新编程的架构。因此,与现有技术的处理器(其中对包以其携带的软件指令进行表征)不同,本发明是带有专门级的装配线的数据流架构,所述专门级可即时例示,以反映沿线流动的数据的变化。
尽管本发明不限制入口处端口的数量,但最好就到达单个端口的数据包并跟踪沿通过全协议处理引擎的数据路径的包的寿命来描述本发明。重要的是要注意到,这些数据位流中的每一个的宽度可为数位。所述宽度提供了在流水线的每一级引擎处可用的处理时间(或时钟周期)的量度,从而能够实现线速吞吐量。如果看上去任何一级引擎处的处理不可能在初始级内设定的时间限制内实现,则通过增加组成每一级的引擎的数量来将每一级引擎限制在特定的时间范围内运行。
图7绘示了本发明的一个实施例,所述实施例提供级0引擎,所述级0引擎实质上是部分包括可编程状态机的前置处理器包成帧器。由于每次到来的包的宽度为
64位,成帧器识别并区分图1中所示的各种类型的帧。成帧器由以下部分组成
可编程存储器基本状态机、快速存储器基本查找表、带有可装载数值的各种比较器以及选择逻辑。状态机选择所关心的包字段,将其与设定值或其它帧数据进行比较,这将驱动状态机算法,所述算法对所关心的帧进行标记并确定帧的类型。然后,将该信息传递到剖析器,帮助指令剖析器如何对帧进行剖析。
为更详细地描述前置处理器位流处理器的此实施例,参考附录A,附录A中所揭示的内容以引用的方式并入本文中。另请参考附录B,附录B中所揭示的内容以引用的方式并入本文中,其详细说明了 "转发逻辑寄存器文件"的一个实施例。
全协议处理引擎较佳地包括至少一个可预测的可编程状态机(ProgrammableState M PSMs)。在一个实施例中,每一可编程状态机是一 32状态机,在156MHz内部时钟频率下每可编程状态机的时间为50ns,相当于每10条指令5ns。然而,每一可编程状态机可具有数量可变的时钟。通过将相对较快的串行位流转换为相对较慢的并行n位宽数据流,级0引擎设置带宽处理停留时间。根据线速调整带宽处理停留时间。例如,为处理10Mbps的数据率,停留时间是每级全协议处理引擎为50ns。
较佳地,基本寄存器由可编程查找表组成,所述可编程查找表预设置有作为配置的一部分装入的数值。然后,这些寄存器经选择以与作为完整的级引擎运行之一部分的掩码、比较器和计数器一起使用。级引擎配置的一个示例性配置说明如下可编程査找表包含多达34个要比较的16位数值。表输出位即对应于该比对(如果进行比对的话)。在本实例中,可能有4个8位宽的比较器,两个降值计数器(对于最大降值计数256,最大可装载数值为8位)。包数据选择宽度可为l字节,且寄存器值字段大小由16个8位宽预置寄存器表示。状态机指令可为单字指令(Single Word I SWI)。单字指令组可从包含设置、试验和跳转的集合中选择,其中每条指令的每个字段可呈现为如下所示的存根字段,其中每一存根字段用逗号隔开,且每一主字段用分号隔幵,例如,SWI: setl, set2, set3, . .testl, test2, test3,.… brl, br2, br3, …
在运行中,状态机将基于可选择的矢量输入进行条件跳转。因此,例如,条件
16(帧字节2==R2)将对8个包位置字节中的字节2与预置寄存器R2数值进行比较。所述跳转通常决定下一控制状态,但也可用于改变可编程状态机的当前状态的运行模式。
现在参见图8A和8B,其中图解说明了将前置处理器包成帧方法应用于来自XGMII接口的输入以太网包。从该处,XGMII接口块剥离前同步码,并将32位接口转换为"图8B:以太网的一般格式"中所示的内部64位表示。
当64位宽包流过流水线时,状态机选择它想要将哪个16位字段发送到可编程解码RAM。参见"图9:包类型选择"和"图10:可编程解码RAM"。
状态机还从待与可编程寄存器进行比较的包选择其它信息,并将结果反馈回状态机,如图IO所示。图IO例如显示了 VLAN和SNAP输入被选中并与所选的寄存器进行比较,且将结果反馈回状态机进行分析。
根据本发明的一个实施例的状态机的用途是控制协议层报头信息的提取。所述状态机由可编程块存储器组成,5个输出数据线反馈回到5个地址输入内以进行下一状态计时。状态机其它输出控制各种功能,例如,待捕获的帧数据、帧层偏移检测和各种用于比较逻辑的输入选择,以及至状态机本身的下一个输入。图12中显示了该状态机。图13显示了一个状态机表实例以有助于对此进行图解说明。
所述可编程状态机的一个任务是控制解码和包数据的提取。图14中的状态图显示了如何设置该状态机来处理以太网包。在本实例中,状态机仅操作以太网层2,但也可继续一直操作例如层4。
解码RAM提供一种对所选的字段进行快速可编程解码的方法。至该解码R認电路的输入是来自包的可选16位字段,且输出是4位"类型"解码,如前文中的图10所示。进行所述操作的一种方法是首先使用所有零填充存储器,然后针对你想要解码的"类型"写入解码位。16位地址对应于"类型",且数据对应于该类型所期望的解码值。在正常情况下,仅设置2位,1位用于端口B, 1位用于端口A。对于端口B和端口A两者,解码位应为相同的值。这方面的一个实例可能是,如果需要0x809B AppleTalk Phase 1为解码值T , 0x8137 IPX (Novell Netware)为解码值"2" , 0x8847 MPLS Unicast为解码值"3",且0x8848 MPLS Multicast为解码值"4"。上述结果如图15所示。
图16显示前置处理器成帧器的基本功能块的更全面的图。
图17图解说明一种增加输入选择及使状态内能够具有子状态的方法。
图18图解说明一种扩展来自状态机的输出控制的方法。图19显示可由状态机选择的掩码比较逻辑。图20是可由该状态机编程的以太网流程图实例。
再参见图5和图6,前置处理器成帧器可经配置以在进行包选择中提供更大的
灵活性,或能够在流水线选择中可选择性地后退一步。如果需要更强的功能,则始
终可通过增加一个或多个额外的状态机及/或可编程解码RAM来提供所述功能。另外应注意,所显示的RAM作为块RAM嵌入在XILINX中,且可以不同的方式配置和分组等,且该设计仅显示使用了两个块RAM, 一个用于状态机,另一个用于TYPE解码。最小的Xilinx XC2VP2具有12个块RAM,下一规格的Xilinx XC2VP2具有28个块RAM,且最大的Xilinx XC2VP2具有556个块RAM。
在如图26所示的本发明的一个普通实施例中,全协议处理引擎流水线的数据路径是从级O.引擎到级1引擎。级1引擎对包实施基于规则的分类。可将多个引擎级联以获得所需的结果,因为分类须在Stage—0 (级0)处定义的时间间隔内发生,从而具有真正的线速吞吐量。每一引擎都基于数据流模型,而不是传统的存储-转发模型。该级的一个输出是基于先前了解包的相关内容的基础上来产生密钥。在当前的实施方案中,该级将需要两个指令周期。每一引擎都采用单个缓冲器。与浮点协处理器不同,所有引擎都是动态可编程的,即,指令是可编程的,以使它们适合于具体的应用。通常,级1将包含至少一个超长指令字处理器。在一替代实施例中,级1引擎可以前文中所述的任务定制处理器方式进行配置。
在如图27所示的本发明的一个具体实施例中,级0和级1引擎在反馈循环内运行,使用可编程状态机的级0位流处理的状态信息被传递到级1分类引擎,且来自分类器的信息被反馈回来以将引擎的运行通知给级0。前馈/后馈引擎架构使得有可能从全协议处理引擎可支持的多个流中获得任何给定流的内容位流,当数据流过引擎时对内容进行剖析(或分类),且将所述操作获得的信息反馈回到前一级,以使下一操作基于先前状态及先前状态的分类结果进行。
此一方法可有利地用于(例如)处理可变长度/可变协议包,对失去序列的包进行动态排序,或者用于其它错误控制功能。数据的基本单元变为l位,反馈和前馈提供系统存储器或粘接,使每一位都与已到达其前面的和跟随在其后面的每一位相关联。可对此范式进行扩展,以将"存储器"注入宏单元数据结构系统(例如,字节、字、帧或完整的会话,这取决于级的具体任务)内,但不会引起存储-转发结构的延时和硬件开销。上述宏单元数据结构可为瞬间的---其在数据具有特定的特性时存在,且用于针对所有后续的数据流对全协议处理引擎的性能进行重新编程。与传统协议处理器的运行是硬接线的不同,通过这种方式,全协议处理引擎是一种可改作的硬件装置,其以判定性方式适应于不断变化的数据流,亦即,本发明提供的解决方案克服了现有技术通过扩展状态机和状态的数量以应对增加的数据流来试图提供解决方案所特有的"状态爆炸"的缺点。
图40显示了一个针对多级位流处理器实施本发明的一个实滩例的数据流布置实施例。
多级技术的一个引人注意的功能在于,各"级"引擎的参数有效去耦。例如,在各级之间不需要公共的时钟。这极大地简化了全协议处理引擎的设计。可为每一级提供根据该级在任何给定时间的运行需求定制的一个或多个引擎。可对每一引擎进行即时重新编程,以赋予其与全协议处理引擎在特定时刻遇到的数据流的特性相匹配的功能。
在本发明的一般实施例中,级2引擎后面跟有级3引擎。级3引擎提供更高级的控制平面功能,例如路由、信令、协议堆栈、策略定义、表维护、与数据平面接口等。与先前的级类似,级3具有专门的引擎,其可复制以与施加在全协议处理引擎上的处理时间和功能要求相匹配。图28-31图解说明带有P-SERDES和核心引擎的可扩展帧处理器和带有本发明的全协议处理引擎的HPC端口卡。
在一个实施例中,前文中所述的插图显示了 (例如)交换机中每一端口卡上的一个32条目x48位内容可寻址存储器。每一条目代表交换机内的一个特定端口。因此,端口卡转发内容可寻址存储器中的第一条目代表交换机的端口 1。应注意,可增大这些内容可寻址存储器的尺寸,以适应附接的LAN区段上的多个节点。较佳地,定义一老化机制,其将仅保留端口卡的转发内容可寻址存储器中的实际条目。由于高性能集群计算不使用LAN区段,所以可能不需要老化机制。 '
由于设计目标之一是能够通过S丽P访问转发内容可寻址存储器,所以在搁架管理器上运行的SNMP代理将需要对驻留在载体卡上的转发内容可寻址存储器高速缓存进行读/写访问。对转发表高速缓存进行的任何改变将通过更新的内容可寻址存储器IPMI信息下推到端口卡,并如上文中所述进行处理。
动态MAC地址学习。为使交换机在任何两个交换机端口之间转发包,必须对目标MAC地址进行查找,以找到将要发送输入包的目标交换机端口。查找表(也称为转发表)较佳地包含48位值,所述48位值包含目标MAC地址及6位交换机端口标识符。由交换机维持的转发表在各单个端口卡上管理的转发表之间分配。需要殖入这些转发表(其在硬件中由内容可寻址存储器实施)。有两种方法来殖入转发表动态和静态。通过经由类似于RFC 1493中所述的转发数据库的SNMP企业MIB将转发内容可寻址存储器暴露给管理实体来实现对这些内容可寻址存储器的静态殖入。
本设计的一个目标是调节广播包和多播包。这是因为广播帧在带宽和交换机资源方面很昂贵,且多播帧更加昂贵。人们进行了穷举搜索,以找到一种方法使交换机可动态了解附接在每个交换机端口上的LAN区段上的MAC地址,而不论交换机可能布置为哪种拓朴,且不需使用广播包和多播包以及不需要对附接的端口网络逻辑进行修改。目前,有单一方法或成组步骤使交换机能够在所有情况下动态确定可连接到交换机端口的所有MAC地址。简而言之,IEFT RFC定义的因特网或以太网要求交换机/网桥/路由器要幺主动了解MAC地址,要幺交换机/网桥/路由器提供一种管理机制以静态殖入转发表。
因此,根据本发明的本实施例的交换机将模仿自学式网桥的性能。将对输入广播(例如图23中所示的标准以太网帧)进行剖析并将源地址放入合适的转发内容可寻址存储器中。这将由独立于FPGA内的包转发逻辑的嵌入式FPGA微处理器完成。下文详细介绍了动态MAC地址新发现
在交换机入口端口处接收到广播包。包通过转发逻辑传递,直到讯务导向器将帧经由帧FIFO将帧传递给移动式管理控制器(Mobile Management CMMC)。
移动式管理控制器将提取数据链路层报头的源地址。
移动式管理控制器将封装源地址,并将交换机端口号导入IPMI消息且经由基于SPI的IPMI总线将所述消息转发到载体卡(IPMC)上的微处理器。
IPMC将捕获转发表高速缓存中的源地址和交换机端口号,基于S醒P的管理实体可经由寄存器访问控制访问所述转发表高速缓存。
IPMC将内容可寻址存储器更新消息广播给交换机内所有其它的移动式管理控制器。
内部微处理器将接收内容可寻址存储器更新消息,并通过将所述内容可寻址存储器更新消息的MAC地址以交换机端口号表示的偏移放入内容可寻址存储器条目中来更新其转发内容可寻址存储器。
应注意,可能需要大范围修改所述整个转发表程序,以支持鲁棒性更大的拓朴,即,所附接的LAN区段上的多个节点。
较佳地,内部微处理器读取32位宽FIF0,以访问数据流中所选的帧。转发逻辑将"内部路由标签"和最前面的32字节输入包写入FIF0。读取状态寄存器以确
20定FIFI何时为空。
如前所述,可通过寄存器访问控制机制访问FPGA控制和状态寄存器,由此将 IPMI封装的消息导向到FPGA中的微处理器,然后,所述FPGA执行实际的寄存器 读或写。在一个实施例中,微处理器作为寄存器访问控制器,其解释寄存器访问控 制消息、确定消息寻址到哪个转发逻辑组件/子模块访问控制器(子模块访问控制 器)以及便于子模块访问控制器的寄存器访问。将所得到的状态/响应返回消息来 源。图22显示子模块访问控制器总线的一个实施例的方框图。应了解,子模块访
问控制器总线对子模块而言是独特的且可能采用多种形式。
IEEE规范规定,可将PAUSE包的目标地址或者设定为要暂停的站的唯一 DA, 或者设定为全局分配的多播地址01-80-C2-00-00-01 (十六进制)。另外,网桥将 不会转发带有PAUSE包多播地址的包,以确保帧不会传播到局部链路区段以外。MAC 控制参数域指定要暂停的位时间数量,从O到65535。在先前的"暂停"时间到时 之前收到的"暂停"将导致新位时间值代替当前的"暂停"时间值。这使"暂停" 时间能够被重置为O,从而使讯务能够恢复。
较佳地,MAC芯片适应两种流量控制模式。当配置为全双工模式时,MAC芯片 能够自动地产生"暂停"包。通过设置合适的高、低水印,MAC芯片将管理"暂停" 信令的开始和停止,来自SPI-4. 2总线的背压促使MAC芯片入口以FIFO充满。第 二种模式绕过FIFO,并依靠SPI-4. 2流量控制消息传递来产生"暂停"开始和停 止包。
将为端口卡上的每一交换机端口维持一端口状态机。FGPA逻辑和微处理器两 者都可访问状态机。本文件中所述的状态机包含三个基本元素事件、定义的状态 及在进入该状态时执行的操作。上文中定义的事件触发状态跃迁到状态,而所述状 态又会执行图24所示的图示和图25中的状态图所示的操作。
图32显示一个实施例,其中通过将可改作的硬件装置,亦即Virtex LX 200 通信引擎,耦接到构成入口和出口 "端口"的Virtex Pro 4通信引擎来将其配置 为48端口交换机。该配置的问题在于,交换机布置仅限于通过将由Virtex Pro 4 通信引擎支持的交换机布置来处理用于所交换的数据包的单个协议。
图33显示根据本发明的一个交换机的具体架构,其中形成端口处理器引擎和 数字交换机的全协议处理引擎可能要幺是Virtex LX 200通信引擎,要幺是形成智 能、可再编程交换架构的专用全协议处理引擎。与图32中所示的交换机布置不同, 图33中利用根据本发明的全协议处理引擎的实施例提供了一种全协议交换机/网桥布置,所述布置能够处理全协议处理引擎支持的多个协议中的任何协议的数据 包。图33简要图解说明了本发明的交换机的具体配置。
除了在进入状态时所产生的事件之外,微处理器需监视MAC芯片、SFP,并倾 听IPMI事件和消息,以提供导致交换机端口状态跃迁的事件。注意,任何事件可 能在任何状态下发生,且必须被捕获并适当地处理。为简明起见,所述状态图并未 显示所有可能的状态跃迁。另外,大多数事件跃迀导致产生IPMI事件消息,且SNMP 可能截留。
INIT状态是例示端口状态机的交换机端口的初始状态。当首次输入该状态时, SFP启用,且产生TX一ENABLE事件,除非所述端口已被管理人员禁用。
当交换机端口进入ENABLED状态时,进行检査以确定是否存在SFP。如果存在 SFP,则产生MOD—DETECT事件。
将进入FAULTED状态的交换机端口视为停机。为跃迁出该状态,需要人为干预。
MOD—EXISTS-当进入此状态时,对光信号进行检查。如果信号正常,则产生 SIGNAL—DETECT事件。
在SIGNAL状态验证字同步。如果信号已同步,则产生SIGNAL—SYNC事件。
SYNCed。在信号同步后,进行检查,以确定以太网自动协商是否已完成。如果 已完成以太网自动协商,则产生AUT0一NEG—DONE事件。
在UP状态中,交换机端口是UP,且能够将帧转发到交换机架构。然而,尚未 了解所连接的节点的MAC地址。
在READY状态下,交换机端口是运行的。
在本发明的另一个实施例中,沿与论文"下一代互联网协议流量路由"(由 CTO Caspian Networks公司创始人Lawrence G. Roberts博士在于 日在意大利L, Aquila召开的SSGRR 2003S国际会议上提供)中所述的流量路由相 同的路线、但使用已论述过的全协议引擎配置来实施无损失包交换。所述论文的内 容以引用的方式并入本文中。另外,该论文中的内容可扩展至在本发明的全协议处 理引擎中实施端到端流量控制,以符合IEEE 802. 3 AR工作组关于流量控制和拥塞 管理的建议。
应用于包含本文中所揭示的全协议处理引擎的一个实施例的级,根据QOS水平 的"暂停"可利用引擎(由三级处理器组成(a)附装到两个所需的XAUI接口中 每一个的位流处理器;(b)为进行流量识别产生查找密钥或基于规则的讯务优先
级识别流量分类级;(C)用于向更高层协议堆栈或缓冲器管理器产生合适的背压
22通知的处理器级)来实施,以符合IEEE 802. 3 AR工作组关于流量控制和拥塞管理 的预期建议。在Asif Hazarika (ahazirik@)禾口 Bob Bru匿r (Robert. Brunner@ericsson. com)发表的论文"为什幺选择基于优先级/类的"暂 停"来进行拥塞管理(Congestion Management Why Priority/Class Based PAUSE is Required ) " P802. 3ar中重点介绍了优先级识别的需求,所述论文的内容以 引用的方式并入本文中。
于是,块具有两个XAUI接口以及一个或两个使用级处理器实施的SPI 4.2接 口。在增加讯务导向器或交换级后,块也可用于识别输入流量并导向Crypto引擎, 或者基于VLAN标记或带标识中的任何其它标记来处理引擎。这可利用8 SerDes PortXilinx (FX-40)来实施。或者,可使用AMC。该卡也满足第三要求(或者从 RTM、或者从前面板选择XAUI进行1/0)。
应理解,在由本发明的全协议处理引擎进行流量处理方面,如果能够在每个时 钟周期改变电路的功能,则称所述电路是可编程的。通常将其称为处理器。使用指 令集架构(ISA)和寄存器文件(RF)来定义处理器。这就是被称为程序设计员观 点的处理器,且是构成处理器的硬件与在所述处理器上执行的软件之间的接口。参 见Thomas Henriksson的"包内数据流协议处理器(Intra-packet Data-Flow Protocol Processor) ,, (Link6ping Studies in Science and Technology, 第 813号专题论文)和John L. H印essy与David A. Patterson的"计算机架构: 定量方法(Computer Architecture: A Quantitative Approach) ', (Morgan Kaufman Publishers, Inc., ISBN 1-, 1996年第2版),所述论文的内容以 引用的方式并入本文中。在本发明背景下,每个周期变为一个数据到达间隔时间, 必须在所述间隔时间内处理数据。类似于ISA,可将全协议处理引擎的级定义为流 量PSA-流量处理集架构-且将RF定义为流水线寄存器文件。 一个ISA是一组宏代 码,其执行取(指令及/或数据)、解码、递延(以获得更多的数据)、(对数据) 执行(指令)、存储序列(冯,诺依曼模型)。可类似地表示流量PSA的功能。
下文描述将所有IPM控制器连接到本发明的一个实施例中的机箱所用的IPMI 扩展的一个实施例。为更详细地说明本发明的实施例的该方面,参考前文中给出的 名称为"带有硬件/软件实施的双重冗余配置的搁架管理控制器(Shelf Management Controller with Hardware/Software Implemented Dual Redundant Configuration)的临时专利申请案。
图36A和36B绘示了根据本发明的一个实施例的搁架管理控制器或搁架管理控制器230的方框图。如图36A和36B的方框图所示,本发明提供第一搁架管理控 制器310,其与对称布置的第二搁架管理控制器315以通信方式耦接在一起,以 利用具有自动故障转移的工作/备用架构来提供冗余的搁架管理功能。在第一实施 例中,搁架管理控制器310和315中的每一个在架构上是相同的。每一搁架管理 控制器310(315)包括运行小规模操作系统(0S)325(例如,带有薄堆栈的ucLinux 操作系统)的独立处理器320。搁架管理控制器310 (315)依靠独立的电源工作, 且通过自动轮询智能平台管理控制器(IPMC) 235来获得系统正常变量。搁架管理 控制器310 (315)经配置以检测异常、记录事件、产生并传输警告以向系统通知 异常并启动恢复操作。
如图36A所示,每一搁架管理控制器310 (315)都连接到至少两个I2C/IPMB 总线IPMB-A 270和IPMB-B 275。搁架管理控制器310 (315)可布置成主动-主动 或主动-被动12C/IPMB故障转移模式。本发明的该实施例设想统一的消息系统,其 传递抽象化信道(AbCh)上的消息。在本发明的此实施例中,信道是物理链路,例 如12C、 JTAG、更新信道和自由空间。按照AbCh的观点,每一信道具有诸如客户 机服务器信道、对等信道、指示查询和响应方向的主从信道、带宽方面的容量、延 时、以及CoS或QoS、主路径、替代路径、反馈信道(例如,响应或肯定应答消息 传递)等属性。假设属性可编程或硬件得到(例如)缓冲器协助。可随意检査所有 属性状态,所以其能够支持(例如)寄存器。AbCh使消息传递系统能够随意或随 着系统变化的需求路由消息。较佳地,可使用图形用户界面编程工具来为给定的硬 件平台创建一个或多个信道,以将属性传递至硬件平台以及测量性能、运行仿真等。 本领域的技术人员容易地认识到,在EEPROM上执行指令的能力使应用程序能够扩 展。
再参见图36A,将根据本发明的IPMI消息传递系统模型绘示为双重客户机-月艮 务器消息传递系统。在多个搁架部件之间的客户机-服务器消息传递方案使用信道 抽象层来维持层的独立性。搁架管理控制器310通过专用的更新信道330和工作 控制信道335与搁架管理控制器315以通信方式耦接在一起。更新信道330适合 在搁架管理控制器310 (315)之间双向传输健全和状态信息。基于客户机-服务器 的消息传递系统的两个例子在每一搁架管理控制器310 (315)上运行。在例示性 实施例中,在(例如)系统启动时可指定工作搁架管理控制器310 (例如)作为服 务器,此不背离本发明的范围。然后,将搁架管理控制器315指定为客户机。工 作搁架管理控制器310在接收到来自IPMC 235的状态信息时执行命令集以实施搁架管理功能。
在图36A和36B图解说明的实施例中,搁架管理控制器310 (315)的独立处 理器320经设置为与位流处理器(Bit Stream P BSP) 340进行通信, 位流处理器(BSP) 340配备有至少一个处理器接口,所述处理器接口对于所有物 理接口类型(包括但不限于IPMB上的IPMI、串行端口上的命令行接口 (Command Line I CLI) 、 Telnet和SSH Secure Shell)是通用的。在一个实施例 中,搁架管理控制器310(315)包括使用,例如位流处理器340,实施的RCMP-IPMI 桥312,位流处理器340桥接RMCP和IMPI消息。在从系统管理器接收到RMCP消 息包时,打开包并检查UDP端口号。如果UDP端口号与IPMI消息匹配,则剥除包 的报头,且封装IPMI报头(如果有)。然后,将消息发送到合适的接口。搁架管 理控制器内核可能请求"复制回来"。封装发送至系统管理器的IPMI消息并通过 系统管理器物理端口发送。
图37A和37B显示使用BSP 440的I2C硬件有限状态机475的示例性实施方案。 在本实施例中,BSP是根据本发明所述的全协议位流处理器。配置BSP,以对IPMB-A 270和IPMB-B 275总线上的位流进行线速包数据路径处理。BSP适合将位流中的位 汇编到定义的协议数据(信息)单位,并对汇编好的协议数据(信息)单位进行处 理,以便无论遇到的协议如何都提供线速吞吐量。上述两种功能都可使用(例如) 如下所述的寄存器访问控制/子模块访问控制器(487/489)进行动态可编程。因此, 协议的信息单位或者适用于协议数据(信息)单位的处理规则都固有地可以动态方 式更改。
在一个实施例中,硬件有限状态机475包括配置有所选的流水线级引擎序列 的位流处理器440。每一级引擎都带有不同的、可扩展的且可重新编程的架构,对 于向硬件有限状态机475传输消息(例如系统正常、温度、风扇转速等)的每一 IPMC 235,所述架构均形成实例化的装置有限状态机(device
DFSM) 480。 DFSM 480较佳针对通往BSP 440的级引擎的数据流通信进 行配置,所述级引擎适合形成消息传递有限状态机(MFSM) 485的实例。通常,硬 件有限状态机(以及DFSM和MFSM)使用三个基本结构。硬件有限状态机维持操 作表,其包含当FSM处于给定状态时在接收到给定事件时要实施的操作;下一状态 表,其包含当FSM处于给定状态时在接收到给定事件时要输入的下一状态;事件处 理程序,其在遇到事件时驱动进行事件处理、查找并实施所需的操作,以及更新当 前的状态信息。通过寄存器访问控制487机制可访问级机器(或BSP或FPGA)控制和状态寄存器文件,由此将IPMI封装的消息导向级机器(或BSP或FPGA)中的 微处理器,然后,所述级机器(或BSP或FPGA)执行实际的寄存器读或写。微处 理器作为寄存器访问控制器,其解释寄存器访问控制消息,决定将消息寻址到哪个 转发逻辑组件/子模块访问控制器489,并便于子模块访问控制器的寄存器访问。 将所得到的状态/响应返回消息来源。寄存器访问控制/子模块访问控制器487/489 提供即时设置或修改每个装置(即IPMC 235)的消息传递方法的方式,从而提供 一种实施本发明的可编程性水平和灵活性的机制。
在一个实施例中,硬件有限状态机475适合检测I2C总线故障及装置故障。 如果确定故障是在由IMPC 235的其中一个所监视的装置上,则搁架管理控制器310 (315)禁止该装置访问背板。
再参见图36A,客户机315使用更新信道330监视工作搁架管理控制器310 的查询和响应,并计算交易的状态,以及使这些状态与工作搁架管理控制器310 同步。如果客户机搁架管理控制器315检测到搁架管理控制器310中的错误条件, 则其将所述事件报告给系统管理器265,系统管理器265作为裁判且动作以移除工 作搁架管理控制器310,并使备用搁架管理控制器315能够完成故障转移而不需 进行耗时的状态更新。尽管本发明很好地适合在AdvancedTCA顺从系统上运行,但 其也可在MicroTCA环境中(其中三态备用如图36B中规定)工作。
在另一实施例中,搁架管理控制器310(315)由瘦硬件协助的协议堆栈增强。 系统的另一实施例实施OS绕过方案,以确保得到超小型和可管理的搁架管理控制 器实施方案。主要实施例包括EEPR0M以执行指令,例如使用片上系统 (System-0n-C S0C)概念的带有超小型芯片的EEPR0M,其能够使搁架管理控 制器处理器320的功能在节约成本的基础上得到扩展。
在一个实施例中,使用双重冗余搁架管理控制器310 (315)配置来引入搁架 管理控制器的容错运行。在第一实施例中,通过在硬件有限状态机475中增加额 外的校验点状态来插入校验点。当硬件有限状态机475中的当前状态是校验点状 态时,可启动校验点过程。在指示错误时,硬件有限状态机475可通过专用总线 335启动向搁架管理控制器315的故障转移,且在搁架管理控制器310上启动恢 复过程,而不会在ATCA搁架中引入异常。可通过重放以其原始顺序存储在搁架管 理控制器315上的记录状态来重新产生搁架管理控制器310的故障前状态以恢复 搁架管理控制器310的内部故障状态来完成恢复过程。在另一实施例中,可使用 额外的搁架管理控制器492来增强搁架管理控制器310 (315),且通过在保持于三个或更多个搁架管理控制器之间的三个或更多个状态备份之间进行表决来获得 正确的状态。在一个实施例中,将表决结果装载入每一硬件有限状态机475的寄 存器中,以便解决任何冲突的表决。
在图38所示的本发明的一个实施例中,显示了向XUAI双向桥架构提供SPI 4.2 的位流协议处理器(或者称为基于位流协议处理器的桥,或简称为位流协议处理 器)。第一种类型的串行数据传输接口相当于SPI4.2接口,且第二种类型的串行 数据传输接口是XAUI接口。
本实施例的位流协议处理器向XAUI桥提供双重SPI 4. 2。SPI 4. 2提供并行的、 点对点、双向接口。 SPI4.2成帧支持高达最多256个端口。使用16个LVDS数据 信道,以一个完整的包或多个数据突发,将数据通过SPI4.2帧发送。附加在子信 道数据上的控制字报头描述突发。使用控制字中的包起点位(S)和包结束状态位
(E0PS)来标识可能由多个突发组成的完整包。使用地址位
来定义子信道。 对于每个子信道,将流量控制和状态信息传输出带。接口带宽范围可从10Gbit/s
(对于低开销应用)到20Gbit/s (对于诸如需要带宽加速以支持开销信息的交换 机架构等应用)。
应看到,对于10GgiE,每一位流协议处理器可每端口支持10Gbps全双工,使 得有可能达到2.560Tbps交换吞吐量容量。对于40GgiE,每一位流协议处理器可 每端口支持40Gbs全双工,使得有可能达到10Tbps交换吞吐量容量。通常,应认 识到,根据本发明的全协议引擎的可重新配置和可编程性允许处理器在多个时钟速 度范围内固有地可扩展。
应认识到,根据本发明的一个实施例的位流协议处理器能够在(例如)PC的 系统处理器(CPU)和系统存储器之间提供N个互联。N个互联中的每一个都可经 配置以40Gbps的速度传输数据,从而导致扩展的ION Gbps吞吐量。SPI 4. 2是彼 此定位在几英寸内的装置之间的点对点接口。在系统内,通常期望互连通过背板定 位在机箱(Intra-Chassis)内不同卡上或定位在不同机箱(Inter-Chassis)上的 SPI4.2装置。在这些情况下,有利的是使用本发明的串行点对点链接,其提供在 Intra-Chassis和Inter-Chassis环境下的高带宽连接。示例性串行链接包括使用 PCI-Express的ASI、使用XAUI的以太网,以及使用IB的Infiniband。这实际上 转化为使用"虚拟线"接口连接数百个地理上隔离的SPI 4.2装置中的任何两个。 在一个实施例中,本发明可经配置为单板计算机(PC)。在另一实施例中,本发明 提供带有可拆除的附装刀片的工业标准(例如picoTCA)机箱,当进行终端用户升
27级时,能够现场买到所述刀片。
为使用串行链路或经由虚拟线以传输控制字(包括端口地址、数据和并行SPI 4.2接口上可用的带外流量控制信息),利用隧道协议。为确保高带宽利用,这些
隧道协议较佳为轻重量。可将隧道功能嵌入到SPI 4. 2装置或可与SPI 4. 2装置结 合使用来提供该转换的桥芯片中。为支持利用使用日益成熟的隧道协议的各种串行 接口对SPI4.2装置之间进行该桥接,所述桥是可编程的。在本实施例中,基于位 流协议处理器的桥提供与XAUI的SPI 4. 2接口和用于各种隧道协议的其它串行接 口和灵活手段。位流协议处理器提供附录A中所述的动态编程和功能扩展性,附录 A全文并入本文中。
现在参见图39,其中显示了位流协议处理器的另一实施例。在本实施例中, 位流协议处理器直接与前端总线(Front Side B FSB)接口,由此多少省去了 结合图38所述的位流协议处理器中的转化过程。另外,图39中的位流协议处理器 提供细管和粗管并行-串行转换器两者,因此允许针对粗管配置对一个或多个以太 网端口进行选择性统合。
在一个实施例中,位流协议处理器使得能够进行线速QoS包交换,利用所述线 速QoS包交换来在以太网内实施基于单令牌(token)的通信。使用源地址(Source A SA)和目标地址(Destination A DA)和诸如VLAN标签的E型 来协商通信链路上端点之间的唯一令牌。E型扩展可为例如,请求"唯一标识符" 或"令牌许可";与许可的令牌进行数据通信以及请求收回令牌。 一旦令牌得到许 可,使用使用源地址和目标地址字段连同E型来传递短日期。这也可扩展到包括用 于STA和SAS的大数据块。在其它实施例中, 一旦在端点和连接这些端点的中间节 点之间协商好唯一标识符,则使用固定的帧大小来给链路赋予传输固定帧时的可预 测性能,且因此满足各种延时要求。例如,可使用使用源地址/目标地址对来传输 12字节数据、2个E型字节和2字节"标志",而不是用于常规以太网包的传统的 64字节负载。为更详细地说明本扩展以太网通信技术的一个实施例,参考前文中 标识的标题为"用于受限邻域内基于唯一标识符的缩短数据帧的增强以太网协议" 的临时专利申请案。
在另一实施例中,所述同一接口可为Disc (数据遵循E-Type和TAG)提供固 定的2K块大小的帧。在这方面,本发明能够实现可编程的帧大小以太网结构,而 不是现有技术的可变帧大小结构。此功能在iTDM类型的应用中尤其有用,因为其 能够实现在ATCA的范围内封装TDM讯务。在一个实施例中,以太网VLAN报头用作隧道协议,以使工业标准以太网交换
机能够被用来交换位于"机箱内"或"机箱间"环境中的任何两个SPI 4.2装置。 本发明的主要实施例使用吉位以太网(GbE)作为第二数据传输协议。可使用其它 协议,而不背离本发明的范围。将SPI4.2控制字和流量控制信息转换为标准以太 网VL緒报头。在入口将SPI 4.2子信道数据与报头信息封装起来。在出口,剥除 以太网帧的报头信息并将其转换回SPI 4. 2帧,并将流量控制信息转化为SPI 4. 2 电信号。另外,位流协议处理器提供用于嵌入服务信息的"类"的有效方式,以及 用于产生并传播拥塞管理消息的可编程方式。
在一个实施例中,位流协议处理器经配置以支持诸如GbE、 PCI-E邓ress、 RGMII、 PCI总线和串行总线等接口,以使其成为在ATCA和microTCA系统中使用 的理想通用装置。本领域技术人员应认识到,也可使用其它互联技术(例如,来自 MorethanIP公司的XS4 10吉位以太网和HiGig SPI4. 2桥)将SPI4. 2接口桥接到 XAUI接口,以满足多个设计要求,例如装置桥接(例如,NPU桥接到以太网交换机)、 串行背板应用、S0NET/SDH上的包或S0NET/SDH上的以太网应用。
本发明提供的互连通过背板定位在"机箱内"的不同卡上或定位在"机箱间" 的SPI 4.2装置的功能使本发明的一个实施例能够实现基于标准的PC,例如,基 于picoTCA或microTCA标准的PC架构。
图38和39中图解说明的位流协议处理器的一个实施例有利地利用寄存器访问 控制/子模块访问控制器控制器,其将动态编程和功能可扩展性赋予给位流协议处 理器。使用寄存器访问控制/子模块访问控制器控制器结构对位流协议处理器进行 即时编程。可使用此功能对位流协议处理器驻留在其上的刀片(板)进行配置。在 一个实施例中,使用即时动态编程功能来接通或关闭刀片(板),由此将刀片纳入 到移出计算机系统。在另一实施例中,可使用即时动态编程功能来改变桥的特性, 以便使其桥接在(例如)SPI 4. 2和PCI-Express之间。本领域技术人员将认识到, 可使用寄存器访问控制/子模块访问控制器控制器在本发明范围内实施其它配置变 化。例如,可使用可编程性来针对通过计算机系统的不同讯务流量实施真实的端对 端QoS 。
在另一实施例中,位流协议处理器能够实现按优先序排列的交换。结合前一段 中所述的模块化和可扩展picoTCA PC架构,本发明使得能够形成多处理器的N层 分层,其中N既独立于硬件,又可通过改变给予位流协议处理器仲裁架构中不同处 理器子集的优先级来动态选择。本实施例使PC能够被配置为共享存储器型机器以
29及消息传递型多处理器机器。或者,可将根据本发明的一个实施例的PC配置为服 务器、存储区域网络控制器、基于网格计算的模型中的高性能网络节点或电信网络 中的交换机/路由器。应认识到,在需要时,可将同一基本机器通过编程方式或手 动方式改变为前文所述的特殊目的机器中的一种或多种。
本领域技术人员在阅读本揭示内容后易于对所述方法进行各种变更。本发明 的范围不受上文中的内容限制,其仅受前文中的权利要求限制。附录A
代理档案号
1)状态机(假定第63位为最低存效位(msb),并假定第O字节为最高有效位(MSB))
输入(地址IO位)
状态(5位〉状态变量,允许32种状态。通常只是状态输出(下一状态)的寄存形式,其可根据
査找结果等而发生变化。参见下一状态(Next Layer/State)部分。 输入(5位)状态机的控制输入。这5位是多路复用器的输出,该多路复用器用于选择各种比较器
输出、來自前一状态的旗标、以及数据等等。
(49位)5位开放
状态(5位)状态变量。馈送至下一状态逻辑。参见状态输入部分的说明。
RegWn (3位)寄存器写入启用信号,兼甩于层码(LayerCode)寄存器与内用寄存器。(64位寄存器)
0:写入被禁用
1:写入通用寄存器。RegVal是要写入的数据的位置。
2:写入LayerCode2。 RcgVal是值。
3:写入VLAN。 RegVal是VL八N的数量
4:写入MPLS。 RegVal是MPLS标记的数量
5:写入LayerCodc3。 RcgVal是直。
6:写入LayCTCode4。 RcgVal是值。
7:写入LaycrCodeN, RegVal是值。该寄存器是用户自定义的。
RegVal: (4位)若RcgWr/二1,则这是要写入寄存器中的值。
若RegWr^.则这是要写入的数据的末尾四位字节(右对齐)。
r关f " 7mA游凝要说银,
(1位)査找it机存取存储器(LookUp RAM)(及比较器)的启用 0:启用Comp0a及CompLT 1:启用LU及Compl
LU—siz'e: (l位)所耍执行的査找(LookUp)的大小 0: 8位
(l位)用亍査找的流水线级选择器。
LU—nib: (4位)所要査找的数据的末尾四位字节(右对齐)。
(1位)比较器的启用。
0:启用Comp0a、 Comp0b及CompLT 1:启用Compl及Comp2
Comp8yte:' (3位)Comp0a、 CompLT及Compl的末尾字节
CompByte2: (3位)Comp0b及Comp2的末尾字节
(3位)用千ConipOa、 CompLT及Compl的寄存器阵列中的比较值/掩码选择器CompSel2:
(3位)用于CompOb及Comp2的寄存器阵列中的比较值/掩码选择器
CountSize:
(2位)规定计数值字段中的(直的单位人小
0: 8位??? 2: 32位(IPv4, TCP)
1: 16位??') 3: 64位(IPv6)
(1位)选择如何填充计数器寄存器
0:计数器寄存器被写入CountVal中的值。
I: if数器寄存器被写入以CountVal所指向的四位字节结尾的数据(右对齐)。
(4位)老CountSel = 0,则该值写入到计数器寄存器。
若CountSel二l,则四位字1T'Et量(右刘齐)写入到计数器寄存器。 由芈零值启用写入..
CountStage: (2位)用于写入到计数器寄存器的流水线级选择器.,
SOL: (2位)指示新的层于目前数据字中的何处开始。馈送SOL输入。
Tag: (5位)标签(Tag)指示吝层开始及结束于何处,,其定义参见第胖部分。
Error:(l位)错误麻标。(待决定(TBD):编码可被共享或专用。)&image&image see original document page 34&/image&2)比较器/査找配置表(己过时)
元件启川炎,人小
Comp0a!CompEn32
Comp0b!CompEn32
CompL丁!CompErt&L丁, GT32
Comp1CompEn32
Comp2CompEn32
LU—enLook Up( U—SiZ8
末尾7节/ 与下列
四位T.节 相比较
CompByte CompSef CompByte2 。ompSei2 Co/ripByle CompSel
Comp已yte CompSel Comp8yte2 CompSel2 LU—nib
CompA CompB LU hit*
CompA CompB UJ hit
'ConipLT及LU不能问时山现
enable 二 IC卿En
32位数据,在字 节边界上右对开
比较器详图
353. Look UP/Next State (査找/下一状态)逻辑
查找(Look Up)协议的最终输出是决定有限状态机(FSM)的下一状态。对于这2个端口中的每 一端口,査找区块随机存取存储器(LookUp BRAM)的输出均为18位。对于大于IO位的查 找项(例如E-type),査找数据将在这些端口之间划分。这2个端口的输山向^^各被进行及 (AND)运算,并以o加-hot方式对各结果行(result lines)进行解码,从而允许存在18种独 特的协议。(将区块随机存取存储器从lkxl8改变成512x36将可提供36种可能的协议,但 是定对...)。存在包含"下一状态"的一组18个寄存器,其中每一寄存器均对应于一输出 行/助'议。数据包起点(Start of P SOP)及数据包结尾(End of P EOP)也将具 有对应的状态寄存器。或斧,査找区块随机存取存储器的输出可以是一种直接处于最低5 位中的状态。这是通过对上端口输出进疗编码加以指示。该编码被馈送至比较器,以参照 一寄存器进行核对。这两个状态向量被馈送^下一状态多路复用器。来自有限状态机的下 一状态向下一状态逻辑提供第三输入状态。数据包起点及数据包结尾具有对应的状态寄存 器,这些状态寄存器也属于输入。然后,寄存该结果状态并将其反馈给有限状态机。
&image&image see original document page 36&/image&4.以太网状态图实例
&formula&formula see original document page 37&/formula&5.以太网指令的实例
以下是i舒旨令实例中字节顺序的位/字节基准:
&table&table see original document page 38&/column&&/row&&table&
&table&table see original document page 38&/column&&/row&&table&v副 (级o)CompOa GompOc SOL(0}(f CompOa and CompOc 〈V湖s》 Compare bytes 7:6 for V园(Va/ Compare bytes 3:2 for VIAN if SOL - 1 then#VLAN +3 Else #VLAM +2 Input select 4 comp's/SOl_(0)CompVai=0 CompSel=0 RsgVal=2 or 3 SOL=x0 lnputSel=1
'(级!)' (级0)Elsif CompOa (VLAN)' iookup Etype (3:2) Compare bytes 7:6 for MPLS bottom (Va/ 3〕 Compare bytes 5:4 for IPX (4Pv4) Compare bytes 3:2 for MPLS bottom Compare bytes 1:0 for IPX ^v4^ then扭VLAN +2 Else亂AN +1 SOL - , 1 f叩ut select 4 comps/SOL(0)CompVal=3 LU LlJ—nib=4 LU stage-1 R^fWr=3 RsgV3l=1 or 2
(级I) (级0)Eise (E-type), lookup (7:6) Compare bytes 3:2 for MPLS bottom (Va/》 Compare bytes 1:0 for IPX ({^v4) Compare bytes 7:6 for MPLS隨。m Compare bytes 5:4 foNPX (W^v4) !fSOL" then并VLAN " e〖se no chsnge SOL:0 一 2) Input seiect 4 comps/SOI_(0〉CompVal=3 LU e v=1 LlJ—nib=c LU stage=1 RegVal=0 or 1 SOL=x0 lnputSel=1LLJWaU
SNAP (级o)CompO曰 CompOb CompOcIf Comp0a/Comp0b(SNAP) & CompOc(VLAN) Compare bytes 7:6 for VLAN 一 Compare bytes 3:21or VLAN SOL-xx Input select 4 comps/SOL(0)CompVai=1 CompSel=0 RegWn=3 SOL-xxVLAN
(级1) (级0)Elsff ConipOa/CompOb (SNAP), Lookup E-type (3:2) Compare byWs 7:6 for MPLS bottom /Va/" Co,re b,s 5:4 for !PX (IPv4) Compare bytes 3:2 for MPl_S bottom Compare bytes 1:0 for PX (^v4) Input select 4 comps/SOL《0)CompVal=3 CompSel=0 LU size=16 LlJ—nib=4 l_U stage=1LUWaU
Else, goto P白yload
802.2a (级2)CompOa Comp1dIf Comp1 d (xFFFF, 802,3 with IPX) SOL = x1 Input select flags (7, SCX(O〉 for sure)IPX
39&table&table see original document page 40&/column&&/row&&table&&table&table see original document page 41&/column&&/row&&table&&table&table see original document page 42&/column&&/row&&table&&table&table see original document page 43&/column&&/row&&table&&table&table see original document page 44&/column&&/row&&table&&table&table see original document page 45&/column&&/row&&table&&table&table see original document page 46&/column&&/row&&table&&table&table see original document page 47&/column&&/row&&table&&table&table see original document page 48&/column&&/row&&table&&table&table see original document page 49&/column&&/row&&table&6.层的标签(初歩标签)
00 空值/空闲可只描入各个帧之间
01 '有效数据(不是其它类型的)
02 前32位中L2的开始及Payload的幵始
03 在全部64位中L2的开始
04 在前32位中L2的开始,紧接着在后32位中L2.5的开始
05 在前32位中L2的开始,紧接着在后32位中L3的开始
06 在前32位中L2的开始,紧接着在后32位中Payload的开始
在^部64位'+—L'2.5—M'井始在后32位中L2.5的开始
在前32位中L2.5的开始,紧接着在后32位中L3的开始在前32位中L2.5的开始,紧接着在后32位中Payload的丌始L2.5预留
左全部64位中L3的开始在后32位中L3的开始
在前32位中L3的开始,紧接着在后32位中L4的开始在前32位中L3的开始,紧接着在后32位中Payload的开始U预留
在全部64位中L4的开始在后32位中L4的开始L4预留
16 在前32位中Payload的开始
17 在后32位中Payload的开始
18 EOPa,所有字节均有效
19 EOPb,并非所有宇节均有效。MSBytc (其肯定无效)包含有效字节的数量
1a EOPa及在前32位屮L4的开始
1b EOPa及在后32位中L4的开始
■1c EOPb及在前32位中L4的开始
1c( EOPb及在后32位中L4的开始
化 可用户自定义
1f 可用户自定义
04 旧M SNA
EO* Novell (IPX)
F4 LAN Manager FE
89 3b cd sfo1-234一附录B
代理档案号
Ufe of a Packet
12附录B1 —IPMl扩展12.1消息
智能平台管理总线(IPMB)被定义为一种用于连接底板中所有智能平台管理(IPM)控制器的双車行总线(dua! scria! bus)。智能平台管理总线协议是一种请求/回应型的消息接发体系,其指示一请求的来源及目的地以及预定的命令值,该预定的命令值用于指示该请求来源所^^行的操作。与该命令请求相关的ii何数据字节,均跟随在命令字节后面、校验和之前。以下各表显示各请求及回应消息的主体。
智能平台管理总线请求
字节0rsS.A字节1rsLUN字节2字节3rqSA7:节4rqSEQ j rqLUN7'节5cmd字节6检查和1I M1响应字节'—'■位位置
字节0rqSA(目的地)字节1netFnrqLUN字节2检查和字节3.——喊雄),字节4rqSEQ rsLUN字节5cmd字节6教据字节()W 7字节n教据字节n';':节n+1检査和
rsSA :应答器的从地址
rqSA -请求器的从地址
rsLUN/rqLUN -应答器/请求器的LUN
netFn -网络功能(所有CEN IPMI扩展消息将为us 0x31)
cmd -所要执行的摔作
Page化of 24
52U'fe of a Packet
检査和-前面各字节的2的补数之和。CHECKSUM在开始时被设定为0,对于毎一后续 字节CHECKSUM=(CHECKSUM +data byte) modulo 256。在将校验和写入该消息之前 CHECKSUM=CHECKSUM。在接收到之后,将消息字节与校验和相加后进行以256为模 的运算,结果值为O即表明数据有效。
所有CEN IPMI扩展消息(请求及回应)均包含单字节的报头,用以指示要根据下表进行的
CEN IPMI扩展命令
&table&table see original document page 53&/column&&/row&&table&
12.1.1 RAC消息
RAC消,Q、川P读取转发逻辑中的寄存器数据。下表显示RAC消总的格式。RAC消总为:
RAC请求消息格式
&table&table see original document page 53&/column&&/row&&table&&table&table see original document page 54&/column&&/row&&table&&table&table see original document page 55&/column&&/row&&table&&table&table see original document page 56&/column&&/row&&table&LJfe of a Packet
字节7预留字节6预留字节5预留字节4预留TX状态!35:29J字节3TX状态I28:211字节2TX状态[26:13J .''字节lTX状态[li'51字节OTX状态I4:(H TX '. 奇偶性TX 同步RX 同步
SPI4.2 PHY/SPI4.2配置寄存器
字节7预留字节6预闺字节5—预闺.字节4预留字,3 一预留字节2预留字节1预留字节O操作清零1 RDR一直 开始 回送UC2DRUCDR
UCDR - user—clk域复位
UC2DR - user—elk—2x域复位
LOOP - RX至TX回送 *开始-开始诊断测试
一直-无限地运行测试
RDR - rdclkdcm复位
,清零-将成功/不成功计数器清零
操作-使界面処于操作模式'忽略回送和诊断模式
XAUI SYS/A/XC40/XC50
f滞/邻:(;A^"E危a'—…微淳纖魏W^Pi
字节7 .' 预留Paga 23 of 24
57&table&table see original document page 58&/column&&/row&&table&
1.一种全协议数据包处理引擎,其用于管理处理器与具有至少10吉位/秒的线速的高速网络架构之间的数据包通信,所述数据包处理引擎包括所述数据包处理引擎的入口部分,其包括多个入口位流级处理器,每一入口位流级处理器均具有该入口位流级处理器所独有的可编程控制存储器;与所述处理器之间的入口处理器接口;与所述网络架构之间的入口网络接口;以及多端口数据流包存储器,其可操作地连接到所述多个入口位流级处理器、所述入口处理器接口以及所述入口网络接口;以及所述数据包处理引擎的出口部分,其包括多个出口位流级处理器,每一出口位流级处理器均具有该出口位流级处理器所独有的可编程控制存储器;与所述处理器之间的出口处理器接口;与所述网络架构之间的出口网络接口;以及多端口数据流包存储器,其可操作地连接到所述多个出口位流级处理器、所述出口处理器接口以及所述出口网络接口;其中,所述位流级处理器中每一个的所述控制存储器均可基于为一个或多个数据包的给定数据流确定的多个协议中的其中一个协议进行单独的、有选择的动态编程,且所述位流级处理器通过所述多端口数据流包存储器将所述给定的数据流处理为位流数据流,以使所述多个位流级处理器对所述给定数据流进行的处理根据所述位流数据流进行定时,且所述位流数据流是以一速率建立,所述速率使用于所有所述多个协议的所述数据包处理引擎能够实质上以至少等于所述高速网络架构的所述线速的速度连续运行。
2. 如权利要求1所述的数据包处理引擎,其特征在于所述数据包处理引擎的 所述入口部分的所述多个位流级处理器包括输入级位流处理器,其与所述入口网络接口的物理层介接,且根据针对所述给 定数据包确定的所述多个协议中的其中一个协议,建立所述位流数据流的帧;辅助级状态机,其根据针对所述给定数据包确定的所述多个协议中的其中一个协议来剖析所述帧;讯务级处理器,其对由所述辅助级状态机所剖析的所述帧进行帧处理; 调度器级处理器,其管理来自所述讯务级处理器的所述帧的输出;以及 输出级位流处理器,其将来自所述经调度的状态处理器的所述帧与所述入口处理器接口的物理层进行介接。
3. 如权利要求2所述的数据包处理引擎,其特征在于当所述辅助级状态机剖 析所述帧时,所述辅助级状态机利用密钥查找布置,所述密钥查找布置包含可编程 的超长指令字流量分类器,所述流量分类器使所述密钥查找布置的密钥产生流水线 化。
4. 如权利要求2所述的数据包处理引擎,其特征在于将所述讯务级处理器构 建为具有多个区段的数据流处理器,其中根据针对所述给定数据流确定的所述多个 协议中的所述其中一个协议,动态构建所述讯务级处理器内的所述多个区段。
5. 如权利要求1所述的数据包处理引擎,其特征在于所述位流级处理器的至 少一部分使用仲裁或时分多路复用方法中的其中一种方法与相应的多端口数据流 包存储器进行介接,以便在处理所述给定数据流中的部分或所有数据时不需要所述 位流级处理器中的每一个均复制该数据。
6. 如权利要求l所述的数据包处理引擎,其特征在于所述位流级处理器中的 每一个的所述控制存储器可选自指令存储器或状态存储器中的其中一个,且可使用 寄存器访问控制和子模块访问控制系统进行单独的、有选择性的动态重新配置和编 程。
7. 如权利要求6所述的数据包处理引擎,其特征在于所述寄存器访问控制和 子模块访问控制系统由图形用户界面控制,所述图形用户界面管理所述数据包处理 引擎的代码产生、流量控制、性能报告、诊断和维护。
8. 如权利要求l所述的数据包处理引擎,其特征在于所述高速网络架构选自 由以下网络组成的集合存储器网络、通信网络、处理器网络、或其任一组合。
9. 如权利要求l所述的数据包处理引擎,其特征在于进一步包括多端口高速数据包交换机, . 其中多个数据包处理引擎分别可操作地连接到所述多端口交换机,以形成 全协议桥布置,且其中所述多个数据包处理引擎中的每一个都连接到使用 不同协议进行通信的不同高速网络。
本发明提供一种可重新配置的且与协议无关的位流处理引擎以及相关的系统和数据通信方法,其适合实现在以至少10吉位/秒的速度运行的高速网络之间提供架构间互操作性的目标。所述位流处理引擎作为全协议的多级处理器运行,其可配置有合适的交换机和相关的网络组件以形成无缝网络架构,所述无缝网络架构不仅实现现有各种通信协议之间的互操作性,而且能够适应将来的通信协议。本发明的方法和系统适用于包括存储器网络、通信网络和处理器网络在内的网络。
文档编号G06F13/00GKSQ
公开日日 申请日期日 优先权日日
发明者B·斯塔克, R·霍舍巴奇, V·沙尔玛, W·储 申请人:Slt逻辑有限公司}

我要回帖

更多关于 xaui xgmii 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信