CN101827088A - 基于cpu总线互联的底层通信协议实现方法 - Google Patents
基于cpu总线互联的底层通信协议实现方法 Download PDFInfo
- Publication number
- CN101827088A CN101827088A CN201010126126A CN201010126126A CN101827088A CN 101827088 A CN101827088 A CN 101827088A CN 201010126126 A CN201010126126 A CN 201010126126A CN 201010126126 A CN201010126126 A CN 201010126126A CN 101827088 A CN101827088 A CN 101827088A
- Authority
- CN
- China
- Prior art keywords
- data
- formation
- sbuf
- buffer
- message
- 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.)
- Granted
Links
Images
Landscapes
- Computer And Data Communications (AREA)
Abstract
本发明涉及一种基于CPU总线互联的底层通信协议实现方法,是一种通过系统间共享物理内存的方式实现系统间的通信,其特征在于:该方法的具体实现方式如下:步骤一、定义地址映射;步骤二、定义内核数据结构和预留sbuf的结构;步骤三、关键方法定义;步骤四、协议启动、数据初始化阶段;步骤五、monitor启动,监控各个队列;步骤六、处理收发操作;步骤七,协议关闭阶段。本发明在基于系统间可以共享物理内存的机制上,对于每一个系统都分配出一块物理空间,为各个系统共享,这样系统间的通信就可以通过直接读、写远程主机的共享buffer来实现系统间的通信。
Description
(一)技术领域
本发明一种基于CPU总线互联的底层通信协议实现方法,具体涉及一种集群板内系统CPU通过总线互联通信的方法,属于计算机系统通信技术研究领域,尤其是涉及一种以共享buffer方案实现系统间通信的技术。
(二)背景技术
集群系统由于具有投资小,研制周期短,性能价格比高,可扩展性高,使用方便等特点,再加上可移植异构编程环境PVM和标准的消息传递平台MPI等并行编程环境的日益普及,目前已经成为高性能计算领域重要的发展方向。然而集群系统的通信网络的性能往往成为整个集群式系统性能的瓶颈,目前主要存在的问题是通信带宽低、延时大、通信网络的可扩展性差等缺点,为了改善集群系统的通信性能,解决集群网络可扩展性的问题,现在基本有两个走势,一是为集群系统设计专用网络,以此来改善集群系统的通信,二是对于单机在板内采用大规模处理器系统,通过总线技术实现芯片级、主板级、系统级的通信。
设计专用通信网络
Myrinet、QsNet、InfiniBand是为解决集群系统通信问题设计的专用通信网络,其中InfiniBand网络是一种全新的、功能强大、被设计用来支持基础设施互连的体系结构,被工业界的顶级公司所支持,是唯一既提供机箱内底板互连解决方案,又可以实现机箱间的高带宽互连,把I/O和SAN统一起来的标准。
使用总线技术实现芯片级、主板级、系统级的通信
未来随着工艺的提升多核芯片的规模也将随之扩大,互联结构直接决定整体系统的规模及可扩展性,需要既能满足当前结构规模的需要,同时又要为未来的扩展设计提供便利。
HyperTransport总线在此背景下应运而生,它不仅可以解决高速CPU与外设间的互联的问题,同时也为CPU间的互联提供了解决方案。
通信协议
TCP/IP:TCP/IP通讯协议是人们最为熟知的应用于互联网通信的协议,采用了四层(应用层,传输层,互连网络层,网络接口层)的层级结构,每一层都呼叫它的下一层所提供的功能来完成自己的需求,存在的不足是:由于协议实现过于复杂,通信效率很低。
RDP:RDP协议是Reliable Data Protocol的简写,称为可靠数据协议。RDP协议是面向连接的传输层协议,可以提供可靠的数据传输,其原理和TCP协议相似,都是采用序号和重传机制来保证数据正确到达目的节点。RDP协议和TCP协议的最大不同是:TCP是面向字节流的,而RDP协议是面向消息的,即面向数据包流的,存在的不足是应用范围较窄。
VMMC:VMMC是一种基于虚拟内存映射的通信机制,它支持消息数据在通信进程的虚拟地址空间之间进行有保护的直接传送,可以提供有序、可靠和高效的消息传递并满足多种类型应用程序的通信需求,缺点是需要专门的硬件来支持。
Active Message:Active Message是美国California大学Berkeley分校的Eicken等人在1992年提出的一种异步通信机制,它采用了与传统的通信机制完全不同的设计思路,更直接地使用通信硬件提供的功能,存在的不足是在死锁处理和同步上较差。
Fast Sockets:Fast Sockets是由美国California大学Berkeley分校的Culler教授等于1996年开发的一种面向局域网的通信软件,它采用新的高效通信协议在用户空间实现了网络通信协议(TCP/IP),使得通信过程中软件开销最小,同时又能保持Fast Sockets与现有应用程序以及广域网通信协议的兼容性,存在的不足是需要专用的平台接口才能实现。
综上所诉,集群通信正在朝着两个方向走,一是为集群系统设计专用的网络,二是在板内使用大规模处理器,通过高速总线互联的技术实现芯片间、甚至是系统间的通信任务。
(三)发明内容
本发明的目的在于提供一种基于CPU总线互联的底层通信协议实现方法,为板内CPU通过总线互联的系统提供共享buffer的通信方式,优势在于采用共享buffer方式的通信效率远远高于采用以太网或者是IB网络实现的主机间的通信。
本系统的特点在于CPU通过总线进行互联的系统彼此间可以进行直接内存访问。
本发明在基于系统间可以共享物理内存的机制上,对于每一个系统都分配出一块物理空间,为各个系统共享,这样系统间的通信就可以通过直接读、写远程主机的共享buffer来实现系统间的通信。
本发明一种基于CPU总线互联的底层通信协议实现方法,是一种通过系统间共享物理内存的方式实现系统间的通信,具体实现方式如下:
步骤一、定义地址映射
对于板内的各个系统而言,系统间是独立的,划分的buffer地址范围在物理上是一致的,系统间实现buffer共享,需要每个系统对外都能提供逻辑地址空间,之后系统间的互访就可以通过访问逻辑地址空间实现。实现逻辑地址到物理地址变换可以通过HT1地址映射来完成,每个HT控制器提供了最多八个可用的地址映射窗口,现考虑的地址映射方案采用双向环的策略,一个是顺时针环,一个是逆时针环,这样的设计使得每个系统都能访问其相邻的系统以及其对角线的系统,并且使得访问对角线的系统可以采用不同的环路径到达,这样的设计保证在一个环出现问题的情况下,可以通过另一个环来完成系统间的通信任务。
步骤二、定义内核数据结构和预留sbuf的结构
本通信协议的任务是完成主机间的数据传输的任务,主要包括数据发送和数据接收,对于收发的数据不仅要记录发送、接收的具体数据,还要记录收发收据的协议描述信息,类似于TCP/IP协议的头部,在内核中需要开辟空间维护四个队列,依次是:“消息发送队列”、“消息发送完成队列”、“消息接收队列”、“消息接收完成队列”。
“消息发送队列”主要记录的是上层应用程序发送的消息,这些发送的消息还没有通知给消息的接收方。“消息发送完成队列”记录的上层应用程序发送的消息,这些消息已经通知给消息的接收方,消息的接收方还没有传递消息接收完成的通知。“消息接收队列”记录着远程主机发给本主机的消息,记录着这些消息的基本信息,如数据类型以及数据量大小、数据存放在buffer中位置等的信息,本机可以根据这些信息获取远程主机发给本主机的数据。“消息接收完成队列”记录着发送方发给本主机消息的记录,接收方已将这些消息提交给了上层应用程序,但还没有反馈给消息的发送方。此外,在内核中还需要开辟空间记录数据buffer的使用,包括为基于HT互联的通信模块预留的数据buffer哪些已经被使用,哪些可以使用,可以使用数据buffer的单元大小等信息。
预留的sbuf主要是用于两台通信的主机交换信息使用,这是两台独立主机沟通的唯一渠道,这片buffer空间是操作系统为基于HT互联的通信模块预留出的空间,对于这片空间操作系统不用于分配,而是把对这片空间的使用权完全交给基于HT互联的通信模块,通信模块将这片预留的sbuf进行了划分,具体分为两个部分,一部分记录系统交互的信息,一部分记录两个系统间具体传输的数据。后一部分比较简单,仅仅记录系统间交互的数据,它由buffer管理结构对其进行管理。第一部分比较复杂,因为涉及到两个系统对这片预留buffer区域的操作,互斥的问题需要重点解决,下面做以介绍。记录系统交互的信息部分这部分主要涉及两个结构,一个是“sbuf接收队列”,一个是“sbuf接收完成队列”。这两个队列都是供远程主机写入,本机读取的队列。对于“sbuf接收队列”而言,它主要是接收其他主机发给本主机的消息,这些消息仅仅包括消息头,这些消息头给出了发送数据具体存放的位置,数据的长度,数据的类型等信息,本机能够根据这些消息头所表达的信息,取得消息所包含的数据,这里取数据的操作主要是操作远端内存,因为接收的数据真正是存放在消息的发送方。“sbuf接收完成队列”存放的是数据接收方主机通告的数据已经接收完的通告,发送方根据这个通告,得知发送给接收方的数据哪些已经被提交给上层应用程序,已经提交的数据,发送方需要释放数据所占用的buffer空间。由于对“sbuf接收队列”和“sbuf接收完成队列”这个队列的操作是由两台主机来完成,通常的锁机制在这里并不能使用,为了保证对这些预留buffer操作的互斥性,在sbuf中设置了一些代表锁结构的标识一些特殊的标识并使用一定的策略来达到互斥的效果。下面将具体的介绍如何利用这些标识和相关的策略来达到对预留buffer操作的互斥性。
对于两台主机都能访问的结构加入额外两个锁,不妨称其为lockA,lockB,假设主机A和主机B是对共享buffer区域操作的两台主机,这片buffer空间是主机A为HT互联通信预留的buffer空间,那么主机A对这片buffer的操作相当于操作本地内存,主机B对这片buffer空间的操作相当于操作远端内存,主机A和主机B可以分别使用lockA和lockB锁住这片空间,其中lockA与lockB在初始化阶段都被设置为非锁定状态,每台主机想操作这片buffer空间都需要在对方没有锁定的情况下才可以。下面简述一下过程,假如主机A想操作这片共享的空间,它先使用lockA把这片空间锁住,之后获取lockB这个锁的状态,如果主机B没有锁定这片buffer空间那么它就可以操作,操作完成后,打开自己加的锁,如果主机B已将buffer空间锁定,主机A就直接打开自己加的锁,不然会造成死锁;对于主机B而言,它要想操作这片空间,也需要获得对方的锁,它首先通过自己的锁lockB把共享的buffer锁定,之后获取lockA的状态,如果对方加锁,它直接释放掉自己加的锁,如果锁可以获得,它并不能马上操作这片空间,而是要多询问几次,如果锁在询问过程中一直都可以获得,它才去操作这片空间,操作后释放掉自己加的锁,如果有一次询问的结果是主机A已对buffer空间加锁,主机B无条件释放对这片buffer空间加上的锁,原因在于这片buffer空间可能事先主机A和主机B对它都没有操作,双方的锁都是打开的状态,主机A和主机B可能同时去获取锁,这样就造成了主机A和主机B都对这片buffer空间有操作权,这当然会出问题,为了避免这种情况的发生,采用了让主机B这个操作远端内存的主机多次询问的方式来避免该种情况的发生,即在主机A和主机B都同时获得了对这片buffer空间的操作权时,其实最终能够操作这片buffer空间的主机是主机A,主机B没有对这片buffer空间做任何操作。
步骤三、关键方法定义
基于以上的数据结构,需要主要定义如下方法并实现才能保证通信协议正常运转。
定义的主要方法分别是“发送操作”,“接收操作”,“获取buffer”,“释放buffer”,“监控发送队列”,“监控接收完成队列”,“监控sbuf接收队列”,“监控sbuf接收完成队列”,下面分别加以介绍。
“发送操作”是通信协议为上层应用程序提供的调用接口,它负责的功能是解析用户的请求,具体包括解析应用程序将把数据发送到那里,数据的大小,数据的类型信息,发送函数根据这些信息去调用“获取buffer”函数,来确定剩余的预留buffer空间是否还能够满足用户的请求,如果空间不够,向用户程序通告发送失败的消息,如果可以满足请求,那么发送函数将用户要发送的数据由用户空间拷贝到内核空间,同时生产记录表项,包括数据buffer使用的记录,发送的消息记录,之后获取数据接收方的锁,看是否可以把发送的信息通告给数据接收方(获取锁的过程在步骤二中有详细的介绍),如果可以将通告信息通知给数据接收方,那么“发送操作”就向接收方的sbuf中写入通告信息,同时生产发送完成表项插入到自己的发送完成队列中,如果通告信息不能通告给数据的接收方,那么“发送操作”将生产发送表项,插入到自身的发送队列,等待monitor的扫描对该队列包含的请求做出处理。
“接收操作”也是通信模块为上层应用程序提供的调用接口,这个函数主要负责解析用户程序调用传递的参数,根据数据来源、消息标示等信息在“接收队列”中搜索,如果找到了匹配的项,说明数据已经正确的接收,这时将数据提交给上层应用程序,并释放相应的接收表项,数据提交后还需要通告消息发送方数据已正确接收,以便发送方能够及时释放掉已发送数据占用的buffer空间,对于这个操作,“接收操作”需要获取消息发送方sbuf结构的锁(步骤二中详细给出了获得锁的过程),如果消息发送方的sbuf中可以写入接收完成通告表项,那么就将通告写入到发送方的sbuf中的接收完成队列中即可,如果不能写入,就需要生产接收完成表项插入到自身的接收完成队列中,等待monitor的扫描把通告发送给消息的发送方。
“获取buffer”操作是根据申请的buffer大小信息,在数据buffer管理结构中查找这样的buffer,如果能够找到,就分配buffer,并对buffer使用记录做更改,如果不能分配buffer,就返回buffer请求失败的信息。
“释放buffer”要做的操作是根据调用的参数确定即将释放buffer的起始地址和需要释放buffer的大小,之后扫描数据buffer管理结构的队列,来完成具体buffer回收的操作,由于buffer的分配和释放采用的是buddy算法,这是个成型的算法,这里不做过多介绍,由于buffer的分配和回收是独立的模块,在buffer管理中完全可以使用另一种分配算法来实现数据buffer的管理,由于这里关于buffer管理使用的buddy算法是本领域技术人员所公知的算法,所以不再做更多介绍,如果需要了解可以参考相关书籍。
“监控发送队列”完成的功能是在monitor扫描该队列时,首先确定队列中是否有请求没有得到处理,如果没有,该操作什么都不做,如果有请求没有处理,那么去获得远程主机的sbuf锁(锁获取请参考步骤二),如果锁获取失败,那么什么都不做,如果锁获取成功,再查看远程sbuf中可以接收的表项数目,如果为零,说明远程主机的sbuf中不能再接收新的表项,那么什么都不做,如果不为零,取发送队列中表项数和远程主机sbuf中可以接收表项数中较小的值,将相应的发送表项写入到远程主机的sbuf的接收队列中,同时需要释放发送表项,并生产发送完成表项插入到发送完成队列中,这之后需要相应更改发送队列、发送完成队列、sbuf接收队列中的表项数目值。
“监控接收完成队列”完成的功能是在monitor扫描该队列时,确定是否有接收完成通告需要通知给消息的发送方,如果该队列为空,什么都不做,如果队列不空,说明有请求需要处理,之后获取远程主机sbuf锁(锁获取请参考步骤二),如果锁获取失败,那么什么都不做,如果锁获取成功,再查看远程sbuf中可以接收的表项数目,如果为零,说明远程主机的sbuf中不能再接收新的表项,那么什么都不做,如果不为零,取接收完成队列中表项数和远程主机sbuf中可以接收表项数中较小的值,将相应的接收完成表项写入到远程主机的sbuf的“接收完成队列”中,同时需要释放接收完成表项,这之后需要相应更改接收完成队列、sbuf接收完成队列中的表项数目值。
“监控sbuf接收队列”完成的功能是首先获取sbuf的锁(锁获取请参考步骤二),如果锁获取失败,什么都不做,如果锁获取成功,查看sbuf中的表项数目,如果数目为零,什么都不做,如果数目不为零,那么在内核空间申请与sbuf中表项数目相应的接收表项数目,考虑到在内核空间去申请空间可能会失败,那么会得到一个实际申请到的接收表项数目值,根据这个值,将sbuf中的表项数目拷贝到接收队列中,同时更改sbuf中接收表项数目的值和接收队列中表项数目的值。
“监控sbuf接收完成队列”完成的功能是首先获取sbuf的锁(锁获取请参考步骤二),如果锁获取失败,什么都不做,如果锁获取成功,查看sbuf中的表项数目,如果数目为零,什么都不做,如果数目不为零,那么在发送完成队列中搜索相应的表项,将搜索到的表项记录从发送完成队列中销毁,同时需要释放该消息数据所占用的buffer单元,调用“释放buffer”函数回收数据buffer,处理过sbuf中的所有表项后,那么更改sbuf接收完成队列中表项的记录数以及发送完成队列中的表项数。
步骤四、协议启动、数据初始化阶段
本阶段主要完成通信模块中的一些信息初始化工作,主要包括在内核中申请的一些记录信息的初始化,为基于HT互联的通信模块预留的buffer空间的初始化,具体包括“发送队列”,“发送完成队列”,“接收队列”,“接收完成队列”的初始化,“数据buffer管理结构”的初始化,“sbuf中锁”的初始化,“sbuf中接收表项数目和接收完成表项数目”初始化,“sbuf中接收队列”初始化,“sbuf中接收完成队列”初始化。
步骤五、monitor启动,监控各个队列
Monitor使用内核定时器,在设定的时间到达时刻去扫描“发送队列”,“接收完成队列”,“sbuf接收队列”,“sbuf接收完成队列”,如果队列中有请求需要处理,就调用相应函数对该请求做出适当的处理,如果队列中无需要处理的请求,monitor会继续扫描下一个队列,扫描队列完成,重新设置定时器,之后采用休眠,在定时时刻再次到来时再去扫描各个队列,monitor在协议启动后处于一直运行的状态,直到协议关闭,这里可以对monitor扫描的时间做动态的调整,这个统计可以基于每次扫描处理请求的时间来做调整。
步骤六、处理收发操作
当用户程序有数据收发请求时,将调用内核中的通信模块,对于发送操作,通信模块负责对发送的信息做以记录,并将数据从用户空间拷贝到内核空间,并通知数据接收方数据已发送,等待数据接收方取数据;对于数据接收操作,用户程序调用处于内核态下的通信模块,通信模块负责去查找要接收的数据是否已经正确接收到,如果正确接收到,将数据从内核空间拷贝到用户空间,同时销毁一些记录信息,并通知数据发送方,数据接收已完成,发送方接收到接收完成通告将销毁一些记录信息同时释放数据所占用的buffer空间,如果用户程序要接收的数据还没有正确接收,那么内核模块将不返回任何数据,通告用户程序数据未正确接收。
步骤七,协议关闭阶段
本阶段发生在卸载通信模块阶段,否则,该通信模块将一直运行在内核态下,为用户的请求提供服务,在模块卸载阶段,将销毁在协议启动阶段所分配的内核空间。
本发明一种基于CPU总线互联的底层通信协议实现方法,其优点及功效在于:采用共享buffer方式的通信效率远远高于采用以太网或者是IB网络实现的主机间的通信。本发明在基于系统间可以共享物理内存的机制上,对于每一个系统都分配出一块物理空间,为各个系统共享,这样系统间的通信就可以通过直接读、写远程主机的共享buffer来实现系统间的通信。
(四)附图说明
图116片龙芯3互联系统结构图
图2地址映射方案图
图3协议运行流程框图
图4预留buffer数据结构图
图5(a)数据发送流程图
图5(b)数据接收流程图
图6buffer管理流程图
图7协议涉及的主要模块及数据结构
(五)具体实施方式
1.方法概述
本专利使用共享内存技术实现板上各个操作系统间的通信,各个操作系统都预留出一片buffer空间给基于HT互联的通信模块专用,对于每台主机预留的buffer空间,其他的主机都可以通过逻辑地址空间来访问,逻辑地址空间到物理地址空间的映射由HT控制器完成映射的过程,地址映射方案的配置可以采用多种方案,本专利中采用了顺时针映射和逆时针映射相结合的方式,通过这样的映射方式,每台主机访问相邻的主机有一种方案,访问逻辑对角线的主机,可以采用两种不同的方式,即顺时针的方式和逆时针的方式。在地址映射方案的基础上,内核通信模块负责处理用户提出的发送数据和接收数据的请求,自动完成buffer空间的请求,信息的记录,最终完成数据的发送和接收功能,如图7,在内核空间需要维护③④⑤⑥四个队列,其中③④队列记录着发给其他主机消息的记录,③队列中记录的消息还没有通知给接收主机,④队列记录的消息已经通知给了接收主机;⑤⑥队列记录的消息是其他主机发给本主机的消息,主机可以根据这些记录通过远程内存访问获得消息所包含的数据,⑤队列记录的消息上层应用程序还没有取走,⑥队列记录的消息上层应用程序已经取走,等待给发送主机通告消息,以便发送方主机可以及时释放已提交数据所占用的buffer空间。⑦⑧⑨⑩对应的队列开辟在基于HT互联的通信模块预留的buffer空间中,⑦队列用于接收远程主机发送的消息通告,本主机可以根据这些通告信息获取发送的消息对应的具体数据,⑧队列用于接收远程主机发送的消息已接收的通告,主机根据这些通告能够确定发给其他主机的消息数据哪些被提交给了上层应用程序,已提交的消息数据,主机将释放其占用的buffer空间,⑨⑩用于确定哪些主机还在参与活动,它们维护了系统当前的信息和先前的信息,通过这些信息的比较能够确定主机是否存活。①②对应了是操作sbuf的锁,其中①由远程主机持有,远程主机可对其进行修改,本主机只能读取该锁,②由本主机持有,本主机可对该锁进行修改,远程主机只能读取该锁,①②使用的目的就在于使得两台主机能够互斥的操作这片共享buffer空间。模块A、B、C、D、E是协议运行中必不可少的模块,模块A完成地址映射的功能,这是协议能够正常运行的基础,模块B提供了对buffer的管理的功能,模块C是对远程主机的请求进行选择处理的模块,现在选用的策略很简单,即采用了先请求先服务的策略。模块D用于搜集主机活动的信息,参与活动的主机是存活的,不参与活动的主机可能已经死掉,通信模块根据模块D搜集的信息来确定消息路由的方案,避免将数据发往或经过死掉的主机。模块E用于对数据传输错误做出恰当的处理,如果传输的数据经过校验发生错误,模块E能够保证发送方将再次进行数据传输,最终使得数据能够被正确传输。
2.通信模块的特点
通信模块封装了所有通信的细节,包括系统存在的感知,传输数据的校验,为通信模块预留buffer的管理,所有这些细节都由模块自适应的解决,通信模块以模块的形式插入到内核,为上层应用程序提供服务,上层应用程序以系统调用的形式来实现对通信模块的调用。通信模块接收到用户的请求,完成与目的端内核通信模块的交互,最终完成数据收发的交互。
3.系统结构
基于HT互联的通信模块按功能流程分为如下几个模块:
模块一、地址映射
对于板内的各个系统而言,系统间是独立的,划分的buffer地址范围在物理上是一致的,系统间实现buffer共享,需要每个系统对外都能提供逻辑地址空间,之后系统间的互访就可以通过访问逻辑地址空间实现。实现逻辑地址到物理地址变换可以通过HT1地址映射来完成,每个HT控制器提供了最多八个可用的地址映射窗口,用户可自行配置其映射方式,地址映射配置需要具体考虑到编码的易实现行、系统的可用性等因素,现考虑的地址映射方案采用双向环的策略,一个是顺时针环,一个是逆时针环,这样的设计使得每个系统都能访问其相邻的系统以及其对角线的系统,并且使得访问对角线的系统可以采用不同的环路径到达,这样的设计保证在一个环出现问题的情况下,可以通过另一个环来完成系统间的通信任务,如图2所示,A1,A2,A3,A4构成了顺时针环,B1,B2,B3,B4构成了逆时针环,sys0想访问sys2可以通过sys1也可以通过sys3,sys0访问sys1使用的地址是sys1的逻辑地址,但sys1真正能够识别的地址是它本身的物理地址,这样的转换由地址映射来完成,在sys0访问sys1这个实例中,需要配置A1的地址映射方式,具体可以参考表1中的映射方式,表的第二列对应于sys0访问sys1使用的地址,表的第三列对应于逻辑地址经过地址映射后被转换的地址,特别强调的是以0X1E0开头的地址经地址转换后访问的是相邻的主机,以0X1E1开头的地址经地址转换后访问的是对角线的主机。本专利中并未采用全映射的方案,即每一个系统都可以通过顺时针或者是逆时针访问板上的其它系统,因为这样的映射方案会加大主机访问远程内存的时间,影响通信协议的运行效率。
A1:
Access Target | Address in System 0 | Address in System 1 |
System 1 | 0x1E00_0000_0000-0x1E00_0FFF_FFFF | 0x0000_0000_0000-0x0000_0FFF_FFFF |
System 1,Chip2,HT1 | 0x1E10_0000_0000-0x1E10_0FFF_FFFF | 0x2E00_0000_0000-0x2E00_0FFF_FFFF |
A2:
Access Target | Address in System 1 | Address in System 2 |
System 2 | 0x2E00_0000_0000-0x2E00_0FFF_FFFF | 0x0000_0000_0000-0x0000_0FFF_FFFF |
System 2,Chip1,HT1 | 0x2E10_0000_0000-0x2E10_0FFF_FFFF | 0x1E00_0000_0000-0x1E00_0FFF_FFFF |
A3:
Access Target | Address in System 2 | Address in System 3 |
System 3 | 0x1E00_0000_0000-0x1E00_0FFF_FFFF | 0x0000_0000_0000-0x0000_0FFF_FFFF |
System 3,Chip2,HT1 | 0x1E10_0000_0000-0x1E10_0FFF_FFFF | 0x2E00_0000_0000-0x2E00_0FFF_FFFF |
A4:
Access Target | Address in System 3 | Address in System 0 |
System 0 | 0x2E00_0000_0000-0x2E00_0FFF_FFFF | 0x0000_0000_0000-0x0000_0FFF_FFFF |
System 0,Chip1,HT1 | 0x2E10_0000_0000-0x2E10_0FFF_FFFF | 0x1E00_0000_0000-0x1E00_0FFF_FFFF |
B1:
Access Ta rget | Address in System 1 | Address in System 0 |
System 0 | 0x3E00_0000_0000-0x3E00_0FFF_FFFF | 0x0000_0000_0000-0x0000_0FFF_FFFF |
System 0,Chip3,HT1 | 0x3E10_0000_0000-0x3E10_0FFF_FFFF | 0x3E00_0000_0000-0x3E00_0FFF_FFFF |
B2:
Access Target | Address in System 0 | Address in System 3 |
System 3 | 0x3E00_0000_0000-0x3E00_0FFF_FFFF | 0x0000_0000_0000-0x0000_0FFF_FFFF |
System 3,Chip3,HT1 | 0x3E10_0000_0000-0x3E10_0FFF_FFFF | 0x3E00_0000_0000-0x3E00_0FFF_FFFF |
B3:
Access Target | Address in System 3 | Address in System2 |
System 2 | 0x3E00_0000_0000-0x3E00_0FFF_FFFF | 0x0000_0000_0000-0x0000_0FFF_FFFF |
System 2,Chip3,HT1 | 0x3E10_0000_0000-0x3E10_0FFF_FFFF | 0x3E00_0000_0000-0x3E00_0FFF_FFFF |
B4:
Access Target | Address in System 2 | Address in System 1 |
System 1 | 0x3E00_0000_0000-0x3E00_0FFF_FFFF | 0x0000_0000_0000-0x0000_0FFF_FFFF |
System 1,Chip3,HT1 | 0x3E10_0000_0000-0x3E10_0FFF_FFFF | 0x3E00_0000_0000-0x3E00_0FFF_FFFF |
表1:HT地址映射表
模块二、buffer管理
系统提供的buffer是一片连续的地址空间,考虑到发送数据的特点,可以将buffer划分为不同的结构队列,如划分为1字节、2字节、4字节、8字节的buffer结构队列,这样可以根据请求发送数据的类型,为之选择适当结构的buffer。Buffer的分配与回收采用buddy这种在linux内存管理中使用的比较成熟的算法,可以高效的实现buffer的分配和回收的操作,尽量减少buffer碎片的产生。同时考虑到buffer在分配、回收中可能经常产生需要拆分大的buffer结构,之后又合并小buffer为大的buffer这样的操作,可以预留一片固定大小的buffer,在有buffer请求时将其分配出去,在buffer使用后只是简单的将其标记已回收,如图6,bufManager是一个数组,每个数组元素都包括三个域,分别对应于包含表项的数目,指向第一个表项的指针,指向最后一个表项的指针,每个表项给出可以分配的buffer的大小,大小由bufManager下标i给出,由2^i指定可分配buffer单元的大小,链表链接的可分配buffer的地址是从小到大排序的,在buffer分配、回收的过程中也不会破坏这个性质。
模块三、自适应的buffer请求调度模块
考虑到应用程序的需求,在通信协议的运行中,会接收到很多buffer的使用请求,但buffer容量有限,某些请求不能立即满足,需缓存起来待请求可满足时再行处理,对不同系统、不同进程的请求,需考虑处理顺序的问题,即调度问题,好的调度策略应该兼顾响应时间、优先级、吞吐量等因素,当然当系统任务很庞大很复杂时,如果调度策略的执行要花费非常长的时间,简单的调度策略应该被采用,所以调度策略应被设计成可动态调节的,根据系统任务的特点及系统buffer使用的情况来决定任务调度的策略,这里我们称之为“自适应的buffer请求调度策略”,这里我们采用了非常简单的调度策略,即先来先服务的策略,可以针对通信的特点,采用适应的策略。
模块四、可用性保障模块
基于HT互联的通信协议需要在操作系统基础上运行,一旦某个操作系统出现问题,其相应的通信协议模块也必然瘫痪,对于一个大节点上的各个系统而言,希望保证各个系统的通信协议模块互不影响,所以需要设计这样的可用性保证模块,可以在个别的系统出现问题的情况下,其他系统的通信协议模块依然可以正常工作,减小系统间的耦合,现在的实现是各个系统间约定一个沟通的机制,每个存在的系统都参与,每个系统在运行中都会在特定的时间向其它系统告知自身的存在并去查看其他系统是否在参与活动,如果发现某些系统处于非活跃状态,可以确定系统已死掉或是其通信模块已不可用,这样系统在进行数据收发时要采取相应的策略避免将数据发给已死掉的系统或是在数据传输时避免经过已不可用的系统。
模块五、错误处理模块
对于总线的通信,数据传输的可靠性非常高,错误极少发生,但尚存在可能,基于HT互联的通信协议设计中需要考虑各种情况,错误处理模块是其协议可用性的重要一块,当基于HT互联的通信协议在通信中有错误发生时,需要通信协议模块能发现错误,对错误做出及时处理。在现有的协议设计中,几乎每种协议都加入了错误处理模块,然而各系统采用的错误处理机制各不相同,有的仅仅是发现错误,之后通知发送方进行数据重传,有的系统采用纠错的机制,每种错误处理方式都有其优缺点,对于我们的系统而言,由于其通信的可靠性非常高,所以错误处理模块可做的尽量简单,现采用简单的发现错误并通知发送方进行数据重传的机制,发现错误现采用crc校验的机制,即发送方对传输的数据生成一个crc校验值附在发送数据的尾端,接收端接收到数据后,也采用同样的crc校验方式对数据进行校验,之后与数据尾端的crc校验值去比较,如果相同,说明数据传输没有错误发生,如果比较的值不同,说明数据在传输中有错误发生。
4.系统工作流程
初始化阶段:
发送队列和发送完成队列的初始化
接收队列和接收完成队列的初始化
为基于HT互联的通信模块预留buffer的初始化,包括固定结构的初始化和数据buffer的初始化
数据buffer管理结构的初始化
Monitor启动,监控各个队列阶段
数据收发的处理
下面结合附图,详述具体实施步骤如下:
步骤一、定义地址映射
对于板内的各个系统而言,系统间是独立的,划分的buffer地址范围在物理上是一致的,系统间实现buffer共享,需要每个系统对外都能提供逻辑地址空间,之后系统间的互访就可以通过访问逻辑地址实现。实现逻辑地址到物理地址变换可以通过HT1地址映射来完成,每个HT控制器提供了最多八个可用的地址映射窗口,现考虑的地址映射方案采用双向环的策略,一个是顺时针环,一个是逆时针环,这样的设计使得每个系统都能访问其相邻的系统以及其对角线的系统,并且使得访问对角线的系统可以采用不同的环路径到达,这样的设计保证在一个环出现问题的情况下,可以通过另一个环来完成系统间的通信任务,关于地址映射的例子可以参考模块一中的介绍。
步骤二、定义内核数据结构和预留sbuf的结构
本通信协议的任务是完成主机间的数据传输的任务,主要包括数据发送和数据接收,对于收发的数据不仅要记录发送、接收的具体数据,还要记录收发数据的协议描述信息,类似与TCP/IP协议的头部,在内核中需要开辟空间维护四个队列,见图7,依次是:③④⑤⑥。③主要记录的是上层应用程序发送的消息,这些发送的消息还没有通知给消息的接收方。④记录的上层应用程序发送的消息,这些消息已经通知给消息的接收方,消息的接收方还没有传递消息接收完成的通知。⑤记录着远程主机发给本主机的消息,记录着这些消息的基本信息,如数据类型,以及数据量大小、数据存放在buffer中位置等的信息,本机可以根据这些信息获取远程主机发给本主机的数据。⑥记录着发送方发给本主机消息的记录,这些消息接收方已经提交给上层应用程序,但还没有反馈给消息的发送方。此外,在内核中还需要开辟空间记录数据buffer的使用,包括为基于HT互联的通信模块预留的数据buffer哪些已经被使用,那些可以使用,可以使用数据buffer的单元大小等信息。
预留的sbuf主要是用于两台通信的主机交换信息使用,这是两台独立主机沟通的唯一渠道,这片buffer空间是操作系统为基于HT互联的通信模块预留出的空间,对于这片空间操作系统不用于分配,而是把对这片空间的使用权完全交给基于HT互联的通信模块,通信模块将这片预留的sbuf进行了划分,具体分为两个部分,一部分记录系统交互的信息,一部分记录两个系统间具体传输的数据。后一部分比较简单,仅仅记录系统间交互的数据,它由buffer管理结构对其进行管理。第一部分比较复杂,因为涉及到两个系统对这片预留buffer区域的操作,互斥的问题需要重点解决,下面做以介绍。这部分主要涉及两个结构,一个是⑦,一个是⑧。这两个队列都是供远程主机写入,本机读取的队列。对于⑦而言,它主要是接收其他主机发给本主机的消息,这些消息仅仅包括消息头,这些消息头给出了发送数据具体存放的位置,数据的长度,数据的类型等信息,本机能够根据这些消息头所表达的信息,取得消息所包含的数据,这里取数据的操作主要是操作远端内存,因为接收的数据真正是存放在消息的发送方。⑧存放的是数据接收方主机通告的数据已经接收完的通告,发送方根据这个通告,得知发送给接收方的数据哪些已经被提交给上层应用程序,已经提交的数据,发送方需要释放数据所占用的buffer空间。由于对这个队列的操作是由两台主机来完成,通常的锁机制在这里并不能使用,为了保证对这些预留buffer操作的互斥性,在sbuf中设置了一些特殊的标识并使用一定的策略来达到互斥的效果。下面给出了使用相应标识和策略来达到互斥访问共享buffer的介绍。
对于两台主机都能访问的结构加入额外两个锁,不妨称其为lockA,lockB,假设主机A和主机B是对共享buffer区域操作的两台主机,这片buffer空间是主机A预留的buffer空间,那么主机A对这片buffer的操作相当于操作本地内存,主机B对这片buffer空间的操作相当于操作远端内存,主机A能够通过lockA锁住这片空间,主机B可以通过lockB来锁住这片空间,其中lockA与lockB在初始化阶段都设置为非锁定的状态,这样在两台主机想操作这片空间时都需要在对方没有锁定这片空间时才可以操作。下面简述一下过程,假如主机A想操作这片共享的空间,它先使用lockA把这片空间锁住,之后获取lockB这个锁的状态,如果对方没有锁定那么它就操作这片空间,操作完成后,打开自己加的锁,如果不能获得,就直接打开自己加的锁,不然会造成死锁;对于主机B而言,它要想操作这片空间,也需要获得对方的锁,它首先通过自己的锁lockB把共享的buffer锁定,之后获取lockA的状态,如果对方加锁,它直接释放掉自己加的锁,如果锁可以获得,它并不能马上操作这片空间,而是要多询问几次,如果锁在询问过程中一直都可以获得,它才去操作这片空间,操作后释放掉自己加的锁,如果有一次询问的结果是对方已加锁,主机B无条件释放对这片buffer空间加上的锁,原因在于这片空间可能事先主机A和主机B对它都没有操作,双方的锁都是打开的状态,主机A和主机B可能同时去获取锁,这样就造成了主机A和B都对这片buffer空间有操作权,这当然会出问题,为了避免这种情况的发生,采用了让主机B这个操作远端内存的主机多次询问了方式来避免该种情况的方式,即在主机A和主机B都同时获得了对这片buffer空间的操作权时,其实最终能够操作这片buffer空间的主机是主机A,主机B没有对这片buffer空间做任何操作。
步骤三、关键方法定义
基于以上的数据结构,需要主要定义如下方法并实现才能保证通信协议可以正常运转。定义的主要方法分别是“发送操作”,“接收操作”,“获取buffer”,“释放buffer”,“监控发送队列”,“监控接收完成队列”,“监控sbuf接收队列”,“监控sbuf接收完成队列”,下面分别加以介绍。”
“发送操作”是通信协议为上层应用程序提供的调用接口,它负责的功能是解析用户的请求,具体包括解析应用程序将把数据发送到那里,数据的大小,数据的类型信息,发送函数根据这些信息去调用“获取buffer”函数,来确定剩余的预留buffer空间是否还能够满足用户的请求,如果空间不够,向用户程序通告发送失败的消息,如果可以满足请求,那么发送函数将用户要发送的数据由用户空间拷贝到内核空间,同时生产记录表项,包括数据buffer使用的记录,发送的消息记录,之后获取数据接收方的锁,看是否可以把发送的信息通告给数据接收方(获取锁的过程在步骤二中有详细的介绍),如果可以将通告信息通知给数据接收方,那么“发送操作”就向接收方的sbuf中写入通告信息,同时生产发送完成表项插入到自己的发送完成队列中,如果通告信息不能通告给数据的接收方,那么“发送操作”将生产发送表项,插入到自身的发送队列,等待monitor的扫描对该队列包含的请求做出处理,图5(a)给出数据发送流程框图。
“接收操作”也是通信模块为上层应用程序提供的调用接口,这个函数主要负责解析用户程序调用传递的参数,根据数据来源、消息标示等信息在“接收队列”中搜索,如果找到了匹配的项,说明数据已经正确的接收,这时将数据提交给上层应用程序,并释放相应的接收表项,数据提交后还需要通告消息发送方数据已正确接收,以便发送方能够及时释放掉已发送数据占用的buffer空间,对于这个操作,“接收操作”需要获取消息发送方sbuf结构的锁(步骤二中详细给出了获得锁的过程),如果消息发送方的sbuf中可以写入接收完成通告表项,那么就将通告写入到发送方的sbuf中的接收完成队列中即可,如果不能写入,“接收完成”操作就需要生产接收完成表项插入到自身的接收完成队列中,等待monitor的扫描把通告发送给消息的发送方,图5(b)给出了数据接收的流程框图。
“获取buffer”操作是根据申请的buffe大小信息,在数据buffer管理结构中查找这样的buffer,如果能够找到,就分配buffer,并对buffer使用记录做更改,如果不能分配buffer,就返回buffer请求失败的信息。
“释放buffer”要做的操作是根据调用的参数确定即将释放buffer的起始地址和需要释放buffer的大小,之后扫描数据buffer管理结构的队列,来完成具体buffer回收的操作,由于buffer的分配和释放采用的是buddy算法,这是个成型的算法,这里不做过多介绍,由于buffer的分配和回收是独立的模块,在buffer管理中完全可以使用另一种分配算法来实现数据buffer的管理,这里关于buffer管理使用的buddy算法不做更多介绍,如果需要可以参考相关书籍。
“监控发送队列”完成的功能是在monitor扫描该队列时,首先确定队列中是否有请求没有得到处理,如果没有,该操作什么都不做,如果有请求没有处理,那么去获得远程主机的sbuf锁(锁获取请参考步骤二),如果锁获取失败,那么什么都不做,如果锁获取成功,再查看远程sbuf中可以接收的表项数目,如果为零,说明远程主机的sbuf中不能再接收新的表项,那么什么都不做,如果不为零,取发送队列中表项数和远程主机sbuf中可以接收表项数中较小的值,将相应的发送表项写入到远程主机的sbuf的接收队列中,同时需要释放发送表项,并生产发送完成表项插入到发送完成队列中,这之后需要相应更改发送队列、发送完成队列、sbuf接收队列中的表项数目值。
“监控接收完成队列”完成的功能是在monitor扫描该队列时,确定是否有接收完成通告需要通知给消息的发送方,如果该队列为空,什么都不做,如果队列不空,说明有请求需要处理,之后获取远程主机sbuf锁(锁获取请参考步骤二),如果锁获取失败,那么什么都不做,如果锁获取成功,再查看远程sbuf中可以接收的表项数目,如果为零,说明远程主机的sbuf中不能再接收新的表项,那么什么都不做,如果不为零,取接收完成队列中表项数和远程主机sbuf中可以接收表项数中较小的值,将相应的接收完成表项写入到远程主机的sbuf的接收完成队列中,同时需要释放接收完成表项,这之后需要相应更改接收完成队列、sbuf接收完成队列中的表项数目值。
“监控sbuf接收队列”完成的功能是首先获取sbuf的锁(锁获取请参考步骤二),如果锁获取失败,什么都不做,如果锁获取成功,查看sbuf中的表项数目,如果数目为零,什么都不做,如果数目不为零,那么在内核空间申请与sbuf中表项数目相应的接收表项数目,考虑到在内核空间去申请空间可能会失败,那么会得到一个实际申请到得接收表项数目值,根据这个值,将sbuf中的表项数目拷贝到接收队列中,同时更改sbuf中接收表项数目的值和接收队列中表项数目的值。
“监控sbuf接收完成队列”完成的功能是首先获取sbuf的锁(锁获取请参考步骤二),如果锁获取失败,什么都不做,如果锁获取成功,查看sbuf中的表项数目,如果数目为零,什么都不做,如果数目不为零,那么在发送完成队列中搜索相应的表项,将搜索到的表项记录从发送完成队列中销毁,同时需要释放该消息数据所占用的buffer单元,调用“释放buffer”函数回收数据buffer,处理过sbuf中的所有表项后,那么更改sbuf接收完成队列中表项的记录数以及发送完成队列中的表项数。
步骤四、协议启动、数据初始化阶段
本阶段主要完成通信模块中的一些信息初始化工作,主要包括在内核中申请的一些记录信息的初始化,为基于HT互联的通信模块预留的buffer空间的初始化,具体包括“发送队列”初始化,“发送完成队列”初始化,“接收队列”初始化,“接收完成队列”初始化,“数据buffer管理结构”初始化,“sbuf中锁”初始化,“sbuf中接收表项数目和接收完成表项数目”初始化,“sbuf中接收队列”初始化,“sbuf中接收完成队列”初始化,其中图4中给出了sbuf中锁的描述,sbuf中接收队列和接收完成队列有着类似的结构,这里仅介绍sbuf中接收队列,sbuf中的接收队列需要设置为三份,分别与其他三台主机共享,其中①③⑤是远程主机所持有的锁,②④⑥是本地主机所持有的锁,关于锁的获取请参考步骤二。
步骤五、monitor启动,监控各个队列
Monitor使用内核定时器,在设定的时间到达时刻去扫描“发送队列”,“接收完成队列”,“sbuf接收队列”,“sbuf接收完成队列”,如果队列中有请求需要处理,就调用相应函数对该请求做出适当的处理,如果队列中无需要处理的请求,monitor会继续扫描下一个队列,扫描队列完成,重新设置定时器,之后采用休眠,在定时时刻再次到来时再去扫描各个队列,monitor在协议启动后处于一直运行的状态,直到协议关闭,这里可以对monitor扫描的时间做动态的调整,这个统计可以基于每次扫描处理请求的时间来做调整,图3给出了协议运行的流程框图。
步骤六、处理收发操作
当用户程序有数据收发请求时,将调用内核中的通信模块,对于发送操作,通信模块负责对发送的信息做以记录,并将数据从用户空间拷贝到内核空间,并通知数据接收方数据已发送,等待数据接收方取数据;对于数据接收操作,用户程序调用处于内核态下的通信模块,通信模块负责去查找要接收的数据是否已经正确接收到,如果正确接收到,将数据从内核空间拷贝到用户空间,同时销毁一些记录信息,并通知数据发送方,数据接收已完成,发送方接收到接收完成通告将销毁一些记录信息同时释放数据所占用的buffer空间,如果用户程序要接收的数据还没有正确接收,那么内核模块将不返回任何数据,通告用户程序数据未正确接收,图5(a)、图5(b)分别给出数据发送和数据接收的流程图,关于数据发送和接收的详细过程请参考“发送操作”和“接收操作”。
步骤七,协议关闭阶段
本阶段发生在卸载通信模块阶段,否则,该通信模块将一直运行在内核态下,为用户的请求提供服务,在模块卸载阶段,将销毁在协议启动阶段所分配的内核空间。
本发明为板内CPU通过总线互联的系统提供了共享buffer的通信方式,该通信协议能够极大的改善集群板内主机间的通信效率,同时有望在MPI库中加入对该通信模块的支持,最终将带来集群系统通信效率的改善。
Claims (1)
1.一种基于CPU总线互联的底层通信协议实现方法,是一种通过系统间共享物理内存的方式实现系统间的通信,其特征在于:该方法的具体实现方式如下:
步骤一、定义地址映射
对于板内的各个系统而言,系统间是独立的,划分的buffer地址范围在物理上是一致的,系统间实现buffer共享,需要每个系统对外都能提供逻辑地址空间,之后系统间的互访就可以通过访问逻辑地址空间实现;实现逻辑地址到物理地址变换可以通过HT1地址映射来完成,每个HT控制器提供了最多八个可用的地址映射窗口,现考虑的地址映射方案采用双向环的策略,一个是顺时针环,一个是逆时针环,这样的设计使得每个系统都能访问其相邻的系统以及其对角线的系统,并且使得访问对角线的系统可以采用不同的环路径到达,这样的设计保证在一个环出现问题的情况下,可以通过另一个环来完成系统间的通信任务;
步骤二、定义内核数据结构和预留sbuf的结构
本通信协议的任务是完成主机间的数据传输的任务,主要包括数据发送和数据接收,对于收发的数据不仅要记录发送、接收的具体数据,还要记录收发收据的协议描述信息,类似于TCP/IP协议的头部,在内核中需要开辟空间维护四个队列,依次是:“消息发送队列”、“消息发送完成队列”、“消息接收队列”、“消息接收完成队列”;
“消息发送队列”主要记录的是上层应用程序发送的消息,这些发送的消息还没有通知给消息的接收方;“消息发送完成队列”记录的上层应用程序发送的消息,这些消息已经通知给消息的接收方,消息的接收方还没有传递消息接收完成的通知;“消息接收队列”记录着远程主机发给本主机的消息,记录着这些消息的基本信息,如数据类型以及数据量大小、数据存放在buffer中位置等的信息,本机可以根据这些信息获取远程主机发给本主机的数据;“消息接收完成队列”记录着发送方发给本主机消息的记录,接收方已将这些消息提交给了上层应用程序,但还没有反馈给消息的发送方;此外,在内核中还需要开辟空间记录数据buffer的使用,包括为基于HT互联的通信模块预留的数据buffer哪些已经被使用,哪些可以使用,可以使用数据buffer的单元大小等信息;
预留的sbuf主要是用于两台通信的主机交换信息使用,这是两台独立主机沟通的唯一渠道,这片buffer空间是操作系统为基于HT互联的通信模块预留出的空间,对于这片空间操作系统不用于分配,而是把对这片空间的使用权完全交给基于HT互联的通信模块,通信模块将这片预留的sbuf进行了划分,具体分为两个部分,一部分记录系统交互的信息,一部分记录两个系统间具体传输的数据;后一部分比较简单,仅仅记录系统间交互的数据,它由buffer管理结构对其进行管理;第一部分比较复杂,因为涉及到两个系统对这片预留buffer区域的操作,互斥的问题需要重点解决,下面做以介绍;记录系统交互的信息部分这部分主要涉及两个结构,一个是“sbuf接收队列”,一个是“sbuf接收完成队列”;这两个队列都是供远程主机写入,本机读取的队列;对于“sbuf接收队列”而言,它主要是接收其他主机发给本主机的消息,这些消息仅仅包括消息头,这些消息头给出了发送数据具体存放的位置,数据的长度,数据的类型等信息,本机能够根据这些消息头所表达的信息,取得消息所包含的数据,这里取数据的操作主要是操作远端内存,因为接收的数据真正是存放在消息的发送方;“sbuf接收完成队列”存放的是数据接收方主机通告的数据已经接收完的通告,发送方根据这个通告,得知发送给接收方的数据哪些已经被提交给上层应用程序,已经提交的数据,发送方需要释放数据所占用的buffer空间;由于对“sbuf接收队列”和“sbuf接收完成队列”这个队列的操作是由两台主机来完成,通常的锁机制在这里并不能使用,为了保证对这些预留buffer操作的互斥性,在sbuf中设置了一些代表锁结构的标识一些特殊的标识并使用一定的策略来达到互斥的效果;下面将具体的介绍如何利用这些标识和相关的策略来达到对预留buffer操作的互斥性;
对于两台主机都能访问的结构加入额外两个锁,称其为lockA,lockB,假设主机A和主机B是对共享buffer区域操作的两台主机,这片buffer空间是主机A为HT互联通信预留的buffer空间,那么主机A对这片buffer的操作相当于操作本地内存,主机B对这片buffer空间的操作相当于操作远端内存,主机A和主机B可以分别使用lockA和lockB锁住这片空间,其中lockA与lockB在初始化阶段都被设置为非锁定状态,每台主机想操作这片buffer空间都需要在对方没有锁定的情况下才可以;下面简述一下过程,假如主机A想操作这片共享的空间,它先使用lockA把这片空间锁住,之后获取lockB这个锁的状态,如果主机B没有锁定这片buffer空间那么它就可以操作,操作完成后,打开自己加的锁,如果主机B已将buffer空间锁定,主机A就直接打开自己加的锁,不然会造成死锁;对于主机B而言,它要想操作这片空间,也需要获得对方的锁,它首先通过自己的锁lockB把共享的buffer锁定,之后获取lockA的状态,如果对方加锁,它直接释放掉自己加的锁,如果锁可以获得,它并不能马上操作这片空间,而是要多询问几次,如果锁在询问过程中一直都可以获得,它才去操作这片空间,操作后释放掉自己加的锁,如果有一次询问的结果是主机A已对buffer空间加锁,主机B无条件释放对这片buffer空间加上的锁,原因在于这片buffer空间可能事先主机A和主机B对它都没有操作,双方的锁都是打开的状态,主机A和主机B可能同时去获取锁,这样就造成了主机A和主机B都对这片buffer空间有操作权,这当然会出问题,为了避免这种情况的发生,采用了让主机B这个操作远端内存的主机多次询问的方式来避免该种情况的发生,即在主机A和主机B都同时获得了对这片buffer空间的操作权时,其实最终能够操作这片buffer空间的主机是主机A,主机B没有对这片buffer空间做任何操作;
步骤三、关键方法定义
基于以上的数据结构,需要主要定义如下方法并实现才能保证通信协议正常运转;定义的主要方法分别是“发送操作”,“接收操作”,“获取buffer”,“释放buffer”,“监控发送队列”,“监控接收完成队列”,“监控sbuf接收队列”,“监控sbuf接收完成队列”,下面分别加以介绍:
“发送操作”是通信协议为上层应用程序提供的调用接口,它负责的功能是解析用户的请求,具体包括解析应用程序将把数据发送到那里,数据的大小,数据的类型信息,发送函数根据这些信息去调用“获取buffer”函数,来确定剩余的预留buffer空间是否还能够满足用户的请求,如果空间不够,向用户程序通告发送失败的消息,如果可以满足请求,那么发送函数将用户要发送的数据由用户空间拷贝到内核空间,同时生产记录表项,包括数据buffer使用的记录,发送的消息记录,之后获取数据接收方的锁,看是否可以把发送的信息通告给数据接收方,如果可以将通告信息通知给数据接收方,那么“发送操作”就向接收方的sbuf中写入通告信息,同时生产发送完成表项插入到自己的发送完成队列中,如果通告信息不能通告给数据的接收方,那么“发送操作”将生产发送表项,插入到自身的发送队列,等待monitor的扫描对该队列包含的请求做出处理;
“接收操作”也是通信模块为上层应用程序提供的调用接口,这个函数主要负责解析用户程序调用传递的参数,根据数据来源、消息标示等信息在“接收队列”中搜索,如果找到了匹配的项,说明数据已经正确的接收,这时将数据提交给上层应用程序,并释放相应的接收表项,数据提交后还需要通告消息发送方数据已正确接收,以便发送方能够及时释放掉已发送数据占用的buffer空间,对于这个操作,“接收操作”需要获取消息发送方sbuf结构的锁,如果消息发送方的sbuf中可以写入接收完成通告表项,那么就将通告写入到发送方的sbuf中的接收完成队列中即可,如果不能写入,就需要生产接收完成表项插入到自身的接收完成队列中,等待monitor的扫描把通告发送给消息的发送方;
“获取buffer”操作是根据申请的buffer大小信息,在数据buffer管理结构中查找这样的buffer,如果能够找到,就分配buffer,并对buffer使用记录做更改,如果不能分配buffer,就返回buffer请求失败的信息;
“释放buffer”要做的操作是根据调用的参数确定即将释放buffer的起始地址和需要释放buffer的大小,之后扫描数据buffer管理结构的队列,来完成具体buffer回收的操作;“监控发送队列”完成的功能是在monitor扫描该队列时,首先确定队列中是否有请求没有得到处理,如果没有,该操作什么都不做,如果有请求没有处理,那么去获得远程主机的sbuf锁,如果锁获取失败,那么什么都不做,如果锁获取成功,再查看远程sbuf中可以接收的表项数目,如果为零,说明远程主机的sbuf中不能再接收新的表项,那么什么都不做,如果不为零,取发送队列中表项数和远程主机sbuf中可以接收表项数中较小的值,将相应的发送表项写入到远程主机的sbuf的接收队列中,同时需要释放发送表项,并生产发送完成表项插入到发送完成队列中,这之后需要相应更改发送队列、发送完成队列、sbuf接收队列中的表项数目值;
“监控接收完成队列”完成的功能是在monitor扫描该队列时,确定是否有接收完成通告需要通知给消息的发送方,如果该队列为空,什么都不做,如果队列不空,说明有请求需要处理,之后获取远程主机sbuf锁,如果锁获取失败,那么什么都不做,如果锁获取成功,再查看远程sbuf中可以接收的表项数目,如果为零,说明远程主机的sbuf中不能再接收新的表项,那么什么都不做,如果不为零,取接收完成队列中表项数和远程主机sbuf中可以接收表项数中较小的值,将相应的接收完成表项写入到远程主机的sbuf的“接收完成队列”中,同时需要释放接收完成表项,这之后需要相应更改接收完成队列、sbuf接收完成队列中的表项数目值;
“监控sbuf接收队列”完成的功能是首先获取sbuf的锁,如果锁获取失败,什么都不做,如果锁获取成功,查看sbuf中的表项数目,如果数目为零,什么都不做,如果数目不为零,那么在内核空间申请与sbuf中表项数目相应的接收表项数目,考虑到在内核空间去申请空间可能会失败,那么会得到一个实际申请到的接收表项数目值,根据这个值,将sbuf中的表项数目拷贝到接收队列中,同时更改sbuf中接收表项数目的值和接收队列中表项数目的值;
“监控sbuf接收完成队列”完成的功能是首先获取sbuf的锁,如果锁获取失败,什么都不做,如果锁获取成功,查看sbuf中的表项数目,如果数目为零,什么都不做,如果数目不为零,那么在发送完成队列中搜索相应的表项,将搜索到的表项记录从发送完成队列中销毁,同时需要释放该消息数据所占用的buffer单元,调用“释放buffer”函数回收数据buffer,处理过sbuf中的所有表项后,那么更改sbuf接收完成队列中表项的记录数以及发送完成队列中的表项数;
步骤四、协议启动、数据初始化阶段
本阶段主要完成通信模块中的一些信息初始化工作,主要包括在内核中申请的一些记录信息的初始化,为基于HT互联的通信模块预留的buffer空间的初始化,具体包括“发送队列”,“发送完成队列”,“接收队列”,“接收完成队列”的初始化,“数据buffer管理结构”的初始化,“sbuf中锁”的初始化,“sbuf中接收表项数目和接收完成表项数目”初始化,“sbuf中接收队列”初始化,“sbuf中接收完成队列”初始化;
步骤五、monitor启动,监控各个队列
Monitor使用内核定时器,在设定的时间到达时刻去扫描“发送队列”,“接收完成队列”,“sbuf接收队列”,“sbuf接收完成队列”,如果队列中有请求需要处理,就调用相应函数对该请求做出适当的处理,如果队列中无需要处理的请求,monitor会继续扫描下一个队列,扫描队列完成,重新设置定时器,之后采用休眠,在定时时刻再次到来时再去扫描各个队列,monitor在协议启动后处于一直运行的状态,直到协议关闭,这里可以对monitor扫描的时间做动态的调整,这个统计可以基于每次扫描处理请求的时间来做调整;
步骤六、处理收发操作
当用户程序有数据收发请求时,将调用内核中的通信模块,对于发送操作,通信模块负责对发送的信息做以记录,并将数据从用户空间拷贝到内核空间,并通知数据接收方数据已发送,等待数据接收方取数据;对于数据接收操作,用户程序调用处于内核态下的通信模块,通信模块负责去查找要接收的数据是否已经正确接收到,如果正确接收到,将数据从内核空间拷贝到用户空间,同时销毁一些记录信息,并通知数据发送方,数据接收已完成,发送方接收到接收完成通告将销毁一些记录信息同时释放数据所占用的buffer空间,如果用户程序要接收的数据还没有正确接收,那么内核模块将不返回任何数据,通告用户程序数据未正确接收;
步骤七,协议关闭阶段
本阶段发生在卸载通信模块阶段,否则,该通信模块将一直运行在内核态下,为用户的请求提供服务,在模块卸载阶段,将销毁在协议启动阶段所分配的内核空间。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 201010126126 CN101827088B (zh) | 2010-03-15 | 2010-03-15 | 基于cpu总线互联的底层通信协议实现方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 201010126126 CN101827088B (zh) | 2010-03-15 | 2010-03-15 | 基于cpu总线互联的底层通信协议实现方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101827088A true CN101827088A (zh) | 2010-09-08 |
CN101827088B CN101827088B (zh) | 2013-03-27 |
Family
ID=42690792
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 201010126126 Expired - Fee Related CN101827088B (zh) | 2010-03-15 | 2010-03-15 | 基于cpu总线互联的底层通信协议实现方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101827088B (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102467479A (zh) * | 2010-11-17 | 2012-05-23 | 英业达股份有限公司 | 主机间数据的传输方法 |
CN103701830A (zh) * | 2014-01-13 | 2014-04-02 | 浪潮(北京)电子信息产业有限公司 | 一种实现数据处理和交互的方法和系统 |
WO2018112738A1 (en) * | 2016-12-20 | 2018-06-28 | Intel Corporation | Power state management |
CN109800201A (zh) * | 2018-12-18 | 2019-05-24 | 珠海派诺科技股份有限公司 | 基于linux的RS485实时收发控制的驱动方法 |
CN110225577A (zh) * | 2014-02-20 | 2019-09-10 | 高通股份有限公司 | 在周期性的数据交换期间实行针对无线设备的功率节省的方法和装置 |
CN112532539A (zh) * | 2019-09-18 | 2021-03-19 | 无锡江南计算技术研究所 | 面向大规模并发通信的优化方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2004054437A (ja) * | 2002-07-17 | 2004-02-19 | Ricoh Co Ltd | データ通信システム |
CN101122892A (zh) * | 2007-08-17 | 2008-02-13 | 中国科学院计算技术研究所 | 一种cpci信号处理板 |
CN101388844A (zh) * | 2008-11-07 | 2009-03-18 | 东软集团股份有限公司 | 一种数据流程的处理方法和系统 |
-
2010
- 2010-03-15 CN CN 201010126126 patent/CN101827088B/zh not_active Expired - Fee Related
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2004054437A (ja) * | 2002-07-17 | 2004-02-19 | Ricoh Co Ltd | データ通信システム |
CN101122892A (zh) * | 2007-08-17 | 2008-02-13 | 中国科学院计算技术研究所 | 一种cpci信号处理板 |
CN101388844A (zh) * | 2008-11-07 | 2009-03-18 | 东软集团股份有限公司 | 一种数据流程的处理方法和系统 |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102467479A (zh) * | 2010-11-17 | 2012-05-23 | 英业达股份有限公司 | 主机间数据的传输方法 |
CN103701830A (zh) * | 2014-01-13 | 2014-04-02 | 浪潮(北京)电子信息产业有限公司 | 一种实现数据处理和交互的方法和系统 |
CN103701830B (zh) * | 2014-01-13 | 2016-09-07 | 浪潮(北京)电子信息产业有限公司 | 一种实现数据处理和交互的方法和系统 |
CN110225577A (zh) * | 2014-02-20 | 2019-09-10 | 高通股份有限公司 | 在周期性的数据交换期间实行针对无线设备的功率节省的方法和装置 |
WO2018112738A1 (en) * | 2016-12-20 | 2018-06-28 | Intel Corporation | Power state management |
US10936047B2 (en) | 2016-12-20 | 2021-03-02 | Intel Corporation | Power state management |
CN109800201A (zh) * | 2018-12-18 | 2019-05-24 | 珠海派诺科技股份有限公司 | 基于linux的RS485实时收发控制的驱动方法 |
CN109800201B (zh) * | 2018-12-18 | 2021-04-13 | 珠海派诺科技股份有限公司 | 基于linux的RS485实时收发控制的驱动方法 |
CN112532539A (zh) * | 2019-09-18 | 2021-03-19 | 无锡江南计算技术研究所 | 面向大规模并发通信的优化方法 |
CN112532539B (zh) * | 2019-09-18 | 2023-03-28 | 无锡江南计算技术研究所 | 面向大规模并发通信的优化方法 |
Also Published As
Publication number | Publication date |
---|---|
CN101827088B (zh) | 2013-03-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5376371B2 (ja) | 並列コンピューティング・システムに使用されるネットワーク・インターフェース・カード | |
US11640362B2 (en) | Procedures for improving efficiency of an interconnect fabric on a system on chip | |
US7702742B2 (en) | Mechanism for enabling memory transactions to be conducted across a lossy network | |
CN101827088B (zh) | 基于cpu总线互联的底层通信协议实现方法 | |
CN106533992B (zh) | 用于全连接网格拓扑结构的高速pci架构路由 | |
US20040187112A1 (en) | System and method for dynamic ordering in a network processor | |
US8756270B2 (en) | Collective acceleration unit tree structure | |
US20050097300A1 (en) | Processing system and method including a dedicated collective offload engine providing collective processing in a distributed computing environment | |
CN1798102A (zh) | 在交换结构网络中仲裁虚拟信道传输队列 | |
CN113490927A (zh) | 具有硬件集成和乱序放置的rdma输送 | |
CN111309491B (zh) | 一种作业协同处理方法及系统 | |
WO2020171988A1 (en) | Rdma transport with hardware integration | |
US7124231B1 (en) | Split transaction reordering circuit | |
US8566833B1 (en) | Combined network and application processing in a multiprocessing environment | |
CN114598746B (zh) | 基于智能网卡的服务器间负载均衡性能优化方法 | |
CN102687109A (zh) | 使用分组分段和转发的存储器管理 | |
US9703739B2 (en) | Return available PPI credits command | |
US10579310B2 (en) | System and method for reliably persisting storage writes at high speed | |
CN114885007A (zh) | 用于实时的强一致性会话同步的方法和电子设备 | |
CN101123567A (zh) | 用于处理网络信息的方法及系统 | |
CN113434290A (zh) | 基于raft协议的数据处理方法和设备,及计算机存储介质 | |
CN109845199A (zh) | 合并网络设备架构中的读取请求 | |
Bui et al. | Improving data movement performance for sparse data patterns on the blue gene/q supercomputer | |
US20160142476A1 (en) | Method and apparatus for transferring content among large clusters of storage devices to achieve a target replication distribution | |
Bui et al. | Improving sparse data movement performance using multiple paths on the Blue Gene/Q supercomputer |
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: 20130327 Termination date: 20200315 |