一种基于多节点网络报文传输的请求响应管理机制的制作方法
【专利摘要】本发明提供一种基于多节点网络报文传输的请求响应管理机制，本发明充分考虑到多节点网络中报文传输的特点，根据相应的节点的处理能力，以列表的方式来管理请求报文和响应报文，并以RAM的方式来实现此列表，从而大大降低了寄存器带来的资源占用，同时增强了对于各种规模的多节点网络应用的可移植性。
【专利说明】一种基于多节点网络报文传输的请求响应管理机制
[0001]
【技术领域】 本发明涉及芯片设计领域，具体地说是一种基于多节点网络报文传输的"请求一响应" 管理机制。
【背景技术】
[0002] 随着服务器应用领域的不断发展，高端服务器的应用需求已经进入了一个重要阶 段。复杂的体系结构实现支持高端服务器系统实现高性能指标、高安全性、高可用性、高可 靠性等特点。这就需要网络控制类芯片控制多路处理器系统，使系统内部报文传输达到高 效可靠、安全稳定。控制多路处理器访问报文传输的控制芯片内部支持复杂的协议，控制庞 大高速的报文流。这就需要一种高可靠的报文管理机制保证其内部报文传输高效可靠。报 文管理的目的有以下几点：维护"请求--响应"的对应报文收发，保证报文传输的可靠性； 控制同一时间段节点发出的请求数目，保证系统最有效率地运行；尽可能地减少对于芯片 资源的占用；易于实现和在不同规模的系统之间进行移植。
【发明内容】
[0003] 本发明的报文管理机制主要考虑现在对高端服务器的需求影响，导致复杂控制类 芯片的性能和可靠性都不断提升，复杂的协议支持和高速的传输能力使芯片内部需要特殊 的流控机制实现，从而满足高端服务器系统的高效，高可靠运行要求。
[0004] 本发明充分考虑到多节点网络中报文传输的特点，根据相应的节点的处理能力， 以列表的方式来管理请求报文和响应报文，并以RAM的方式来实现此列表，从而大大降低 了寄存器带来的资源占用，同时增强了对于各种规模的多节点网络应用的可移植性。实现 这种机制需要考虑的因素和实现的配置包括：（1)多节点网络所使用报文协议的清晰定 义；（2)节点每发出一个请求，需要在相应的列表上生成表项，记录下关键信息，在收到期 望响应之后擦除；（3)对于同一类的请求，在每个节点维护一张由RAM实现的单独的列表； (4) 当列表中的表项已经被未响应报文占满时，新的请求不能发出，需要通知节点等待； (5) 列表的大小由系统规模和需要处理的报文协议复杂度决定，应符合或略大于节点对于 相应报文的处理能力。
[0005] 对于报文协议的清晰定义，需要明确定义在所有不同场景下同一种请求可能引发 的各种响应，从而明确特定的请求能得到哪些期望的响应，即哪些得到的响应是有效的。节 点发出请求的操作，需要在表项中留下如请求类型，报文序列号等信息，用来衡量得到的响 应是否有效以及区分不同的请求。对于不同类别请求的区分，需要通过请求的响应方式作 为标准，主要是为了避免请求之间存在依赖性的情况。如果将有依赖性的请求放于同一张 表中，将使表的大小和控制逻辑的复杂程度变得难以控制，从而使"请求一响应"的匹配过 程变得低效。对于请求进入列表的控制，由与列表大小对应的序列号来实现，每个进入列表 的请求需要被分配一个序列号，当请求被响应之后该序列号被释放，如果所有的序列号都 已分配完，则通知节点等待。
[0006] 列表的大小，实际上决定了同时发出的同类请求的最大数目，如果这个数目远大 于系统的实际处理能力，就代表着多发出去的报文还是要等待，多出来的表项没有意义，反 而浪费了 RAM。如果这个数目小于系统的实际处理能力，那么表项的缺乏就降低了系统的效 率。另外，考虑到列表本身的控制逻辑会略微降低节点发送请求的效率，最合理的做法应该 是使列表大小符合或略大于节点对于相应报文的处理能力。
[0007] 本发明的管理机制实现了在芯片内部报文流高速传输的条件下，基于完整清晰的 协议设计，对于同一类请求，在发出请求的源节点建立列表，记录下请求的关键信息，并在 收到响应报文之后进行匹配。从而保证在高速传输条件下，报文的可靠传输。本发明在不 影响系统性能的前提下在保证报文可靠传输方面，保证设计可移植性，降低芯片资源耗费 三个方面有显著优势。
[0008] 本发明的有益效果是：在不同规模多节点系统下的可移植性，主要是指作为管理 机制核心的列表可以根据系统规模配置不同的大小，从而保证系统的高效运行，从设计实 现的角度看，在协议相同的前提下，不同规模的多节点系统的列表结构可以在修改RAM大 小参数之后复用。降低芯片资源耗费，主要是指列表的方式易于使用RAM实现，以取代以往 用寄存器方式存储待发送请求关键信息的方式，极大地节省了芯片内的寄存器资源。
【专利附图】
【附图说明】
[0009] 附图1是"请求--响应"列表的结构图； 附图2是"请求--响应"列表的工作流程图。
【具体实施方式】
[0010] 下面参照附图，对本发明的内容以列表结构和基于该结构的管理机制下的"请 求--响应"处理流程来描述这一管理机制的实现过程。
[0011] 正如
【发明内容】
所描述的，本发明用到的列表结构由RAM实现，所用RAM的宽度和深 度分别代表着每一条表项的大小和整个列表的深度。其中，每条表项宽度由关键信息的多 少决定，对于复杂度更高的多节点网络系统结构和协议，需要记录的关键信息(用于区分同 类请求和计算期望响应)就越多，所用的RAM的宽度就越大。列表的深度由系统对相应的请 求处理能力决定，系统处理该类请求的能力越强，同一时间段能处理的该类请求数目越多， RAM的深度就越大。如图1所表示的，记录的关键信息必须包括用于管理和区分请求表项的 序列号和有效位，此外，所实现协议的关键信息也必须包含在表项里。
[0012] "请求--响应"列表的工作流程如图2所示，对于本节点需要发出的请求，在等待 到有空的序列号（即有效位为0)可分配时，将定义的关键信息记录进对应表项，再将请求发 出。对于请求的目的节点，接受到请求之后进行协议定义的相应的处理，包括可能出现需要 给别的节点发送同类或不同类请求的操作并等待响应，在处理完成之后向原请求的源节点 发出响应报文（响应报文必须包含原请求的表项序列号）。源节点收到响应报文之后根据 报文的序列号匹配表项，再计算响应报文是否有效，有效的话擦除表项，释放序列号，接收 响应报文，处理结束。如果响应报文无效，则向系统报错，同时报上原请求的关键信息和错 误信息，擦除表项，处理结束。
【权利要求】
1. 一种基于多节点网络报文传输的"请求一响应"管理机制，其特征在于实现这种机制 需要考虑的因素和实现的配置包括：（1)多节点网络所使用报文协议的清晰定义；（2)节点 每发出一个请求，需要在相应的列表上生成表项，记录下关键信息，在收到期望响应之后擦 除；（3)对于同一类的请求，在每个节点维护一张由RAM实现的单独的列表；（4)当列表中 的表项已经被未响应报文占满时，新的请求不能发出，需要通知节点等待；（5)列表的大小 由系统规模和需要处理的报文协议复杂度决定，应符合或略大于节点对于相应报文的处理 能力。
2. 根据权利要求1所述的管理机制，其特征在于对于报文协议的清晰定义，需要明确 定义在所有不同场景下同一种请求可能引发的各种响应，从而明确特定的请求能得到哪些 期望的响应，即哪些得到的响应是有效的。
3. 根据权利要求1所述的管理机制，其特征在于节点发出请求的操作，需要在表项中 留下如请求类型，报文序列号等信息，用来衡量得到的响应是否有效以及区分不同的请求。
4. 根据权利要求1所述的管理机制，其特征在于对于不同类别请求的区分，需要通过 请求的响应方式作为标准，主要是为了避免请求之间存在依赖性的情况。
5. 根据权利要求1所述的管理机制，其特征在于对于请求进入列表的控制，由与列表 大小对应的序列号来实现，每个进入列表的请求需要被分配一个序列号，当请求被响应之 后该序列号被释放，如果所有的序列号都已分配完，则通知节点等待。
【文档编号】H04L12/70GK104104593SQ201410167399
【公开日】2014年10月15日 申请日期:2014年4月24日 优先权日:2014年4月24日
【发明者】王恩东, 胡雷钧, 李拓, 童元满, 李仁刚 申请人:浪潮电子信息产业股份有限公司