【业务领域】InfiniBand协议总结
InfiniBand协议总结
- InfiniBand协议是什么?
- Infiniband产生的原因
- Mellanox公司介绍及其新闻
- 基于TCP/IP的网络与IB网络的比较
- IB标准的优势
- 什么是InfiniBand网络
- 什么是InfiniBand架构
- Mellanox IB卡介绍
- InfiniBand速率发展介绍
- InfiniBand网络主要上层协议
- InfiniBand管理软件
- Infiniband的协议层次与网络结构
- 如何使用IB verbs传送数据
- 常见错误
- IB专业术语
- 报文基本知识
- 报文传输类型
- 交换器和路由器规则
- 属性与管理器
- IB核心传输引擎Queue Pair
InfiniBand协议是什么?
NVIDIA 于2020年4月份完成了对 Mellanox 的收购,将高性能网络技术与自身高性能计算技术相结合,提供更高的性能、更高的计算资源利用率,其中最重要的一点是通过 InfiniBand 实现互连。
InfiniBand 即“无限带宽”技术,通常缩写为IB,是一个用于高性能计算的计算机网络通信标准,它最重要的一个特点就是高带宽、低延迟,应用于计算机与计算机之间的数据互连。InfiniBand 也用作服务器与存储系统之间的直接或交换互连,以及存储系统之间的互连,这也是 NVIDIA 收购 Mellanox 的一个重要原因。
由于IB网络具备低延迟、高带宽的网络特性,因此在高性能计算项目中有比较广泛的应用,通常在集群中作为高速计算网络,IB 网络采用了 mallenox 的IB网卡(目前最新带宽已经达到400Gb/s),通过专用 IB 交换机和控制器软件 UFM 实现网络通信和管理。
InfiniBand 作为一个统一的互联技术,可以用来处理存储 I/O、网络 I/O,也能够去处理进程间的互相通信。它可以将服务器集群中的管理节点、计算节点、存储服务器(分布式存储、磁盘阵列)等进行互联,实现高速通信,也可以连接外部网络(例如互联网、VPN、WAN)。设计及使用InfiniBand 技术的目的主要是应用于企业级的数据中心进行高速通信。其目标主要是实现高的可靠性、可用性、可扩展性和高的性能。InfiniBand 可以提供高带宽、低延迟的传输在相对短的距离内,而且在单个或多个互联网络中支持冗余的 I/O 通道,所以在数据中心发生一些故障的情况下仍然能够保持高速运行。
在应用场景方面,以太网可以实现全球通信的互联,InfiniBand 则没有那么大的通信距离和范围,主要用于企业、校园内部或者城市局域部分的数据中心,通常只有几间机房,而他的最大距离很大程度上取决于缆线类型(铜缆或光纤)、连接的质量、数据速率和收发器等。如果在使用光缆、单模的收发器以及基本数据速率的情况下,InfiniBand 的最大距离在10公里左右。
理论上来说,InfiniBand 能够想以太网一样通过交换机、路由器实现超远距离的通信,但是在实际使用过程中,传输距离会受到多方面的限制。为了确保数据分组的可靠传输,InfiniBand 具备诸如反应超时、流控等特点,用来防止阻塞造成的分组丢失。延长 InfiniBand 的距离将降低这些特征的有效性,因为延迟超过了合理的范围。
为了扩大InfiniBand的应用范围,满足用户更大的使用需求,需要解决长距离传输问题,Mellanox 厂商想到了利用以太网、光纤网络的方式来解决这一困扰;即通过一桥接设备连接到以太网和光纤网络,同时能够实现InfiniBand网络与现有的光纤通道连接的各类局域网、城域网等分布式数据中心相兼容,通过这一方法,将传输距离提升至10公里左右。
除了上文中介绍到的高速网络传输性能之外,Infiniband 技术发展的另一个重要的方向在于将服务器中的总线进行网络化,因此它直接继承了总线低时延、高带宽的特性。Infiniband 中的 RDMA(Remote Direct Memory Access) 技术直接继承的总线技术中使用的 DMA Direct Memory Access) 技术。得益于这一技术的应用,我们能够通过 RDMA 提供的基于 IO 通道直接对远程的虚拟内存进行直接读写,而不是像传统的读写方式,需要通过 CPU 的干预,应用程序能够直接访问远程主机内存或者硬盘而不必消耗远程主机中的任何 CPU 资源,释放服务器 CPU 性能。因此相对万兆以太网来说,Infiniband 在服务器中对 CPU、内存、硬盘等的交流方面具备天然的优势。
Infiniband产生的原因
随着CPU性能的飞速发展,I/O系统的性能成为制约服务器性能的瓶颈。于是人们开始重新审视使用了十几年的PCI总线架构。虽然PCI总线结构把数据的传输从8位/16位一举提升到32位,甚至当前的64位,但是它的一些先天劣势限制了其继续发展的势头。PCI总线有如下缺陷:
-
由于采用了基于总线的共享传输模式,在PCI总线上不可能同时传送两组以上的数据,当一个PCI设备占用总线时,其他设备只能等待;
-
随着总线频率从33MHz提高到66MHz,甚至133MHz(PCI-X),信号线之间的相互干扰变得越来越严重,在一块主板上布设多条总线的难度也就越来越大;
-
由于PCI设备采用了内存映射I/O地址的方式建立与内存的联系,热添加PCI设备变成了一件非常困难的工作。目前的做法是在内存中为每一个PCI设备划出一块50M到100M的区域,这段空间用户是不能使用的,因此如果一块主板上支持的热插拔PCI接口越多,用户损失的内存就越多;
4. PCI的总线上虽然有buffer作为数据的缓冲区,但是它不具备纠错的功能,如果在传输的过程中发生了数据丢失或损坏的情况,控制器只能触发一个NMI中断通知操作系统在PCI总线上发生了错误因此,Intel、 Cisco、 Compaq、 EMC、 富士通等公司共同发起了infiniband架构,其目的是为了取代PCI成为系统互连的新技术标准,其核心就是将I/O系统从服务器主机中分离出来。
InfiniBand 采用双队列程序提取技术,使应用程序直接将数据从适配器 送入到应用内存(称为远程直接存储器存取或RDMA), 反之依然。在TCP/IP协议中,来自网卡的数据先拷贝到 核心内存,然后再拷贝到应用存储空间,或从应用空间 将数据拷贝到核心内存,再经由网卡发送到Internet。这 种I/O操作方式,始终需要经过核心内存的转换,它不 仅增加了数据流传输路径的长度,而且大大降低了I/O 的访问速度,增加了CPU的负担。而SDP则是将来自网 卡的数据直接拷贝到用户的应用空间,从而避免了核心 内存参入。这种方式就称为零拷贝,它可以在进行大量 数据处理时,达到该协议所能达到的最大的吞吐量
Mellanox公司介绍及其新闻
InfiniBand技术一直以来都是Mellanox公司在推动发展,下面是Mellanox的简要介绍;
Mellanox合并完成:NVIDIA网卡名正言顺!
Mellanox为何让多家巨头公司“趋之若鹜”
N卡网速快!Mellanox 100GbE 交换机 SN2700 开箱简测
一文掌握InfiniBand技术和架构
infiniband学习总结
基于TCP/IP的网络与IB网络的比较
IP网络协议如TCP/IP,具有转发丢失数据包的特性,网络不良时要不断地确认与重发,基于这些协议的通信也会因此变慢,极大地影响了性能。与之相比,IB使用基于信任的、流控制的机制来确保连接的完整性,数据包极少丢失。
使用IB协议,除非确认接收缓存具备足够的空间,否则不会传送数据。接受方在数据传输完毕之后,返回信号来标示缓存空间的可用性。通过这种办法,IB协议***消除了由于原数据包丢失而带来的重发延迟,从而提升了效率和整体性能***。
IB标准的优势
IB(InfiniBand)协议是用于高性能计算的网络通讯标准,其主要优势是:
- 支持大量协议:包括通过IB光纤的非IB协议的隧道包,例如IPv6、Ethertype包;
- 高带宽,吞吐量可实现2.5Gb/s,10Gb/s,30Gb/s;
- 低延时,应用程序时延 <3us; 高可扩展性的拓扑结构;
- 非特权应用发送接收信息时,内核不用进行特权模式的切换;
- 每个信息都由CA(通道适配器)的硬件DMA直接传输,而不用处理器的参与,也就是RDMA;
大部分协议都可以在芯片上实现,减少软件和处理器的负荷。
什么是InfiniBand网络
InfiniBand是一种网络通信协议,它提供了一种基于交换的架构,由处理器节点之间、处理器节点和输入/输出节点(如磁盘或存储)之间的点对点双向串行链路构成。每个链路都有一个连接到链路两端的设备,这样在每个链路两端控制传输(发送和接收)的特性就被很好地定义和控制了。
InfiniBand通过交换机在节点之间直接创建一个私有的、受保护的通道,进行数据和消息的传输,无需CPU参与远程直接内存访问(RDMA)和发送/接收由InfiniBand适配器管理和执行的负载。
适配器通过PCI Express接口一端连接到CPU,另一端通过InfiniBand网络端口连接到InfiniBand子网。与其他网络通信协议相比,这提供了明显的优势,包括更高的带宽、更低的延迟和增强的可伸缩性。
什么是InfiniBand架构
InfiniBand Architecture(IBA) 是为硬件实现而设计的,而TCP则是为软件实现而设计的。因此,InfiniBand是比TCP更轻的传输服务,因为它不需要重新排序数据包,因为较低的链路层提供有序的数据包交付。传输层只需要检查包序列并按顺序发送包。
进一步,因为InfiniBand提供以信用为基础的流控制(发送方节点不给接收方发送超出广播 “信用“大小的数据包),传输层不需要像TCP窗口算法那样的包机制确定最优飞行包的数量。这使得高效的产品能够以非常低的延迟和可忽略的CPU利用率向应用程序交付56、100Gb/s的数据速率。
IB是以通道(Channel)为基础的双向、串行式传输,在连接拓朴中是采用交换、切换式结构(Switched Fabric),所以会有所谓的IBA交换器(Switch),此外在线路不够长时可用IBA中继器(Repeater)进行延伸。
而每一个IBA网络称为子网(Subnet),每个子网内最高可有65,536个节点(Node),IBASwitch、IBA Repeater仅适用于Subnet范畴,若要通跨多个IBA Subnet就需要用到IBA路由器(Router)或IBA网关器(Gateway)。
至于节点部分,Node想与IBA Subnet接轨必须透过配接器(Adapter),若是CPU、内存部分要透过HCA (Host Channel Adapter),若为硬盘、I/O部分则要透过TCA (Target Channel Adapter),之后各部分的衔接称为联机(Link)。上述种种构成了一个完整的IBA。
Mellanox IB卡介绍
1、它长什么样子???
2、为什么 Infiniband 协议需要使用 ib卡?
首先,这里介绍两种概念:
(1)、传统的网络通信协议 —— tcp、udp、ip、icmp 等…
(2)、新一代网络通信协议 —— InfiniBand … 等
传统的通信协议通过内核传递,这很难去支持 新的网络协议 及 发送/接收 端口。而 Infiniband 作为一种新一代的网络协议 ,从一开始就支持 RDMA 技术,由于 infiniband是 一种新的网络协议,因此需要支持该技术的网卡和交换机。
3、如何查看本机有没有ib卡?
user@ubuntu:~$ lspci | grep Mell
0b:00.0 Network controller: Mellanox Technologies MT27500 Family [ConnectX-3]
# 记得是大写的 M,千万要注意格式
4、如何简单使用:
1、在服务器上,插上ib卡,然后连接到服务器上
2、下载相应的ib驱动(点我下载)
3、启动驱动,然后查看ib口(iconfig -a)
4、配置ip,重启服务,进行 RDMA 连通性测试。
推荐:下载ib驱动包 以 基于ubuntu16.04安装ib驱动(步骤详细)
RDMA 连通性测试
4、如何简单使用:
1、在服务器上,插上ib卡,然后连接到服务器上
2、下载相应的ib驱动(点我下载)
3、启动驱动,然后查看ib口(iconfig -a)
4、配置ip,重启服务,进行 RDMA 连通性测试。
推荐:下载ib驱动包 以 基于ubuntu16.04安装ib驱动(步骤详细)
RDMA 连通性测试
版权声明:本文为CSDN博主「郑泽林」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/ljlfather/article/details/102892052
InfiniBand速率发展介绍
InfiniBand串行链路可以在不同的信令速率下运行,然后可以捆绑在一起实现更高的吞吐量。原始信令速率与编码方案耦合,产生有效的传输速率。编码将通过铜线或光纤发送的数据的错误率降至最低,但也增加了一些开销(例如,每8位数据传输10位)。
典型的实现是聚合四个链接单元(4X)。目前,InfiniBand系统提供以下吞吐量速率:
InfiniBand网络主要上层协议
InfiniBand为不同类型的用户提供了不同的上层协议,并为某些管理功能定义了消息和协议。InfiniBand主要支持SDP、SRP、iSER、RDS、IPoIB和uDAPL等上层协议。
SDP (Sockets Direct Protocol)是InfiniBand Trade Association (IBTA)制定的基于infiniband的一种协议,它允许用户已有的使用TCP/IP协议的程序运行在高速的infiniband之上。
SRP(SCSIRDMA Protocol)是InfiniBand中的一种通信协议,在InfiniBand中将SCSI命令进行打包,允许SCSI命令通过RDMA(远程直接内存访问)在不同的系统之间进行通信,实现存储设备共享和RDMA通信服务。
iSER(iSCSI RDMA Protocol)类似于SRP(SCSI RDMA protocol)协议,是IB SAN的一种协议 ,其主要作用是把iSCSI协议的命令和数据通过RDMA的方式跑到例如Infiniband这种网络上,作为iSCSI RDMA的存储协议iSER已被IETF所标准化。
RDS(Reliable Datagram Sockets)协议与UDP 类似,设计用于在Infiniband 上使用套接字来发送和接收数据。实际是由Oracle公司研发的运行在infiniband之上,直接基于IPC的协议。
IPoIB(IP-over-IB)是为了实现INFINIBAND网络与TCP/IP网络兼容而制定的协议,基于TCP/IP协议,对于用户应用程序是透明的,并且可以提供更大的带宽,也就是原先使用TCP/IP协议栈的应用不需要任何修改就能使用IPoIB。
uDAPL(User Direct Access Programming Library)用户直接访问编程库是标准的API,通过远程直接内存访问 RDMA功能的互连(如InfiniBand)来提高数据中心应用程序数据消息传送性能、伸缩性和可靠性。
iSER (iSCSI Extensions for RDMA)和NFSoRDMA (NFS over RDMA),SRP (SCSI RDMA Protocol) 等是InfiniBand中的一种通信协议,在InfiniBand中将SCSI命令进行打包,允许SCSI命令通过RDMA在不同的系统之间进行通信,实现存储设备共享和RDMA通信服务。
InfiniBand管理软件
***OpenSM***软件是符合InfiniBand的子网管理器(SM),运行在Mellanox OFED软件堆栈进行IB 网络管理,管理控制流走业务通道,属于带内管理方式。
OpenSM包括子网管理器、背板管理器和性能管理器三个组件,绑定在交换机内部的必备部件。提供非常完备的管理和监控能力,如设备自动发现、设备管理、Fabric可视化、智能分析、健康监测等等。
Infiniband的协议层次与网络结构
Infiniband的协议采用分层结构,如下图所示,各个层次之间相互独立,下层为上层提供服务。
其中,物理层定义了在线路上如何将比特信号组 成符号,然后再组成帧、 数据符号以及包之间的数据填 充等,详细说明了构建有效包的信令协议等;
链路层定义了数据包的格式以及数据包操作的协议,如流控、 路由选择、 编码、解码等;
网络层通过在数据包上添加一个40字节的全局的路由报头(Global Route Header,GRH)来进行路由的选择,对数据进行转发。在转发的过程中,路由器仅仅进行可变的CRC校验,这样就保证了端到端的数据传输的完整性;
传输层再将数据包传送到某个指定 的队列偶(QueuePair,QP)中,并指示QP如何处理该数据 包以及当信息的数据净核部分大于通道的最大传输单 元MTU时,对数据进行分段和重组。
Infiniband的网络拓扑结构如下图,其组成单元主要分为四类:
(1)HCA(Host Channel Adapter),它是连接内存控制器和TCA的桥梁;
(2)TCA(Target Channel Adapter),它将I/O设备(例如网卡、SCSI控制器)的数字信号打包发送给HCA;
(3)Infiniband link,它是连接HCA和TCA的光纤,InfiniBand架构允许硬件厂家以1条、4条、12条光纤3种方式连结TCA和HCA;
(4)交换机和路由器;
无论是HCA还是TCA,其实质都是一个主机适配器,它是一个具备一定保护功能的可编程DMA(Direct Memory Access,直接内存存取 )引擎。
如下图所示,每个端口具有一个GUID(Globally Unique Identifier),GUID是全局唯一的,类似于以太网MAC地址。运行过程中,子网管理代理(SMA)会给端口分配一个本地标识(LID),LID仅在子网内部有用。QP是infiniband的一个重要概念,它是指发送队列和接收队列的组合,用户调用API发送接收数据的时候,实际上是将数据放入QP当中,然后以轮询的方式将QP中的请求一条条的处理,其模式类似于生产者-消费者模式。
如下图所示,图中Work queue即是QP中的send Queue或者receive Queue,WQ中的请求被处理完成之后,就被放到Work Completion中。
如何使用IB verbs传送数据
Infiniband提供了VPI verbs API和RDMA_CM verbs API 这两个API集合,用户使用其中的库函数,就能很方便的在不同的机器之间传输数据。Infiniband建立连接的流程如下图所示:
其中buildcontext的流程如下:
连接建立完成之后,就可以调用ibv_post_recv和ibv_post_send收发数据了,发送和接收请求都被放在QP中,后台需要调用ibv_poll_cq来逐条处理请求,由于infiniband连接中,一旦有一条数据发送或者接收失败,其后所有的数据发送或者接收都会失败,因此一旦检测到WC的状态不是成功,需要立即处理此错误(此时最好断开连接)。
常见错误
ibv_poll_cq处理完队列中的数据后,WC会包含此次处理的全部信息,包括wr_id、操作状态、错误码等等,错误码包含的信息对于我们解决错误非常有用,这里我就列举一下我在编写代码中遇到的错误。
(1)错误码为4(IBV_WC_LOC_PROT_ERR ),这种错误通常意味着用户对内存的操作权限不够,需要检测在ibv_post_recv和ibv_post_send时scatter/gather list 中传入的内存地址与长度是否正确,或者ibv_reg_mr操作是否成功。
(2)错误码为5,(IBV_WC_WR_FLUSH_ERR ),在flush的时候出现错误,通常是因为前一个操作出现了错误,接下来的一系列操作都会出现
IBV_WC_WR_FLUSH_ERR的错误。
(3)错误码为13(IBV_WC_RNR_RETRY_EXC_ERR ),这种错误一般是因为本地post数据过快。在infiniband传输数据过程中,接收端首选需要注册内存并ibv_post_recv将此内存放入receive queue中然后发送端才能发送数据,如果接受端来不及完成这些操作发送端就发送数据,就会出现上述错误。
IB专业术语
-
处理器节点(processor Node):一组或多组处理器以及其内存,并通过主机通道适配器(HCA)与IBA光纤连接,每个HCA都有一个或多个端口;
-
端口(port):IBA设备与IBA链路连接的双向接口;
-
链路(link):用于两台IBA设备的两个端口间的双向高速连接。具体应用中以serdes实现,单条链路的传输速率可达2.5Gb/s,250MB/s的吞吐率(由于serdes中8b/10b的原因)。此外,还可以用4条或12条链路,达到1GB/s和3GB/s的吞吐率;
-
通道适配器Channel Adapter(CA):书中没有具体介绍,本人认为CA类似于网卡类设备。
每个CA port在配置时就具有唯一地址,当一个CA必须发送信息或者读取信息时,首先需要发送一个请求报文,该报文带有destination port ID,通过交换机和路由器的帮助,CA最终抵达目标CA。所以说终端必然是CA而不是交换机或路由器,CA是真正的操控者,交换机和路由器只是维护流量通道的。
- IO单元与IO控制器(IOU and IOC):IOU的组成包括,连接到IBA的目标通道适配器;一个或多个IO控制器提供的IO接口,其实现形式会是一个大量的存储矩阵;
- 子网(subnet)一些有相同子网ID和相同的子网管理器的端口和链路的集合。
(1)子网管理器(SM)会在子网启动时发现所有设备,配置它们,并在后续周期性检查子网的拓扑结构是否被修改;
(2)在配置过程中,子网管理器会为每个端口配置一个独有的本地ID和一个相同的子网ID,用以标识子网和端口位置;
(3)能交换数据包的所有的CA、路由器端口以及交换机端口都可以被叫做在同一个子网下;
(4)子网间可以通过路由器进行相互连接。
报文基本知识
报文是用来在两个CA之间发送请求(request)或者响应(response)信号,一个报文的有效荷载(payload)部分最大可以包含4KB数据。CA如果需要发送的报文大于此长度,需要对此进行切分,分为多个包传输。每个报文分为payload、路由报文头(header)、CRC校验等,其中header包含以下内容:
本地路由头部(LRH):包括目标端口本地ID(DLID)和源端口本地ID(SLID)。
两者都占据16-bits,前者用来表示报文通过交换机需要到达的子网目的地端口;后者用来表示报文源头的子网ID。
全局路由头部(GRH):包括目标端口全局ID(DGID)和源端口全局ID(SGID)。
两者都占据128-bits,高64-bits表示CA端口的子网ID,低64-bits表示端口的全局唯一ID(GUID)。
注意:GRH和LRH的区别主要在于,LRH是本地ID,报文在通过交换机进行传输时使用LRH,源端口和目标端口在同一子网下;而GRH是全局ID,报文通过IB光纤传输时需要GRH,源端口和目标端口在不同子网下。
基础传输头部(BTH):包括Opcode、DestQP和PSN;
Opcode表示报文操作类型;DestQP表示对端CA的目标QP(Queue Pair,是IB协议中信息传输的重要机制,在后续篇章中会介绍);PSN(Packet Sequence Number)占24-bits ,表示报文序列号,可以用于报文顺序检查和报文重传。
报文传输类型
IB协议中的消息传递是建立在CA间的,其本质是CA间的内存空间进行数据交换。
三类消息传输:
- 从本地CA的内存传输信息到目标CA的内存;
- 从目标CA的内存读取信息,并存储在本地CA的内存中;
- 对目标CA的内存执行原子操作(读/改/写),并将返回的数据存储在本地CA的内存。
1.向对端CA内存写信息,分为两种情况:
信息发送操作:请求信息不会通知CA数据该写到哪块内存中,而是对端CA自行决定数据的存放地址;
RDMA写操作:请求报文会指定数据需要写到对端CA的哪块内存中,报文包括了有效荷载,请求报文的内存起始地址、报文长度和允许该RDMA写操作的一个密钥。
2.从对端CA内存中读取信息:
CA向对端CA发出读指定内存中数据的请求,对端CA接收该请求后,会返回一个或多个响应报文,请求端将返回报文中的数据存储到指定内存中。
3.原子操作:IBA中分为以下两种原子操作
原子读取和加法操作:收到请求后,目标CA从其本地的指定内存中读取数据,将Add值与读取数据相加,并将结果写回本地内存。目标CA将读回的初始值以原子响应包的形式返回给请求端CA。收到响应数据包后,请求端CA将读数据写入自己的本地内存;
原子比较和交换操作:收到请求后,目标CA从其本地的指定内存中读取数据,将读取的数据与Compare值比较,若相等,将值写入指定位置,返回的响应操作与上述加法原子操作一致。
Single packet & Multiple packet
IBA标准中最大包的长度限制为4KB,大约4KB的信息并非不能传输,而是需要拆分为***多包传输(multiple packet)***。
如果信息总长在4KB~8KB,multiple packet将分为***Send First操作***与***Send Last操作***;
如果信息总长大于8KB,将分为***Send First***、Send Middle***和***Send Last操作,其中,非第一包和最后一包的数据都为Send Middle操作。
具体如下示意图:
交换器和路由器规则
当一个请求报文由CA发送后,会有以下两种情况:
- 源CA和目标CA直接连接:这种情况下,报文通过唯一链路,对头部中的DLID信息解码后直接找到目标CA port,目标CA接受请求后,并作出对应处理;
- 源CA和目标CA非直接连接:请求报文不能直接抵达目标CA,所以其需要先前往交换机或者路由器的port。
交换机规则:负责在同一子网内报文的路由,根据DLID查找交换机内部的转发表(由软件在启动阶段配置),确定报文需要从交换机的哪个端口输出。(一个报文在抵挡目标CA前可能需要经过多个交换机)
路由器规则:当源CA和目标CA不在同一子网下,请求报文会带有GRH。交换机会在子网下不断路由报文,直到抵挡路由器的一个port,然后路由器根据GRH:DGID确定目标CA在哪个子网下,与交换机类似,路由器内部存在路由表。(一个报文在抵挡目标CA前可能需要经过多个交换机)
属性与管理器
设备属性
所有IBA设备都有一系列属性(中继器因为在软件上不可见,所以不存在属性),这些属性由于各类原因可以被读写操作,具体属性如下:
- 查询是否有IBA设备存在;
- 查询IBA设备类型(CA、交换机、路由器);
- 确定设备的当前状态;
- 确定设备上的端口数;
- 控制设备的运行属性;
谁访问这些属性?
IBA中定义了一系列管理器,每个管理器都负责IBA设备中操作的各方面:
- 子网管理器 Subnet Manager(SM);
- 性能管理器 Performance Manager(PM);
- 设备管理器 Device Manager(DM);
- 交互管理器 Communications Manager(CM);
管理代理
每个IBA设备包含了一系列管理代理,每个管理代理处理各自的管理器发出的属性访问请求。
当设备中的MA收到来自其各自管理器的属性访问请求报文时,它会对指定的属性执行所请求的操作,并在大多数情况下以响应报文的形式返回结果。
管理器使用特殊的数据包(MAD)
各种管理器使用管理数据报(MAD)的特殊数据包来请求对设备属性执行操作(即方法)。请求MAD具有以下基本特征:
- MAD消息完全包含在单个数据包的数据有效载荷字段中,数据有效载荷字段总是包含精确的256字节。
- 管理类:标识发出数据包的管理器,标识处理请求MAD的设备中的管理代理。
- 方法:指定目标管理代理要对指定属性执行的操作类型。例如,Get方法执行属性读取操作,而Set方法执行属性写入操作。
- 属性ID:指定要执行的属性(例如,读或写)。
- 属性修改器:对于许多属性/方法组合并不需要,指定有关目标属性的附加信息。例如,如果管理员的目标是CA、路由器或交换机上的portinfo属性,则修改器指定目标端口号。
- 数据区域:内容取决于方法和属性。
- 如果“方法”是“Set”操作,则数据区域包含要写入指定属性的数据;
- 如果"方法"是"Get"操作,数据区内容在请求MAD中是未定义的,但是在设备返回的相应响应MAD中包含被请求属性的内容。
IBA中的属性不一定是单一数据格式的,可以是一个选项,可以是一张表,也可以是多种元素组成的数据结构。
IB核心传输引擎Queue Pair
双向信息传输引擎QP
在每个CA中会实现若干QP,数量最多可达16M(2^24)QPs,之所以叫Queue pair,是因为每个QP由两个队列组成,发送队列(Send Queue)和接收队列(Receive Queue)。
-
发送队列:软件将消息传输请求(WQE)发送到SQ,执行时,SQ将出站消息传输请求发送到对端QP的RQ;
-
接收队列:软件将工作请求(WQE)发送到此队列,以处理通过对端QP的SQ传输到RQ的不同类型的入站消息传输请求。
-
请求包与响应包:
QP的SQ会以一系列的一个或多个请求包的形式向远端QP的RQ传输消息传输请求;
根据QP类型,远端QP的RQ可以通过向对应的SQ发送一系列的一个或多个响应数据包来响应接收到的消息传输请求。
报文序列号PSN:
SQ生成的每个请求包都包含一个PSN,收到请求数据包后,RQ将验证数据包是否与期望的PSN (ePSN)一致。
与之对应的,RQ生成的每个响应包都包含一个PSN,该PSN将它与从远端SQ接收到的请求包关联,SQ收到每个响应包时, 将验证包的PSN是否与之前发出的请求相关联。
QP服务类型
在IBA中,主要根据信息的传播需求、场景不同,以及对信息重要性的不同,分为以下几种类型:
- 可靠连接 RC(Reliable Connected)QP;
- 非可靠连接 UC(UnReliable Connected)QP;
- 可靠数据报 RD (Reliable Datagram) QP;
- 非可靠数据报 UD (Unreliable Datagram) QP;
- 类似与隧道包,对非IBA协议的包进行封装的 RAW QP。
每种服务类型的具体区别与特点将在后续专题中进行介绍:占位符。
独立于OS的动作层verb API
软件接口与HCA接口是非直接关联的,软件应用的调用称为verb layer。可以将verb layer想象成松散的API (可以看作函数调用),并由每个操作系统供应商以特定方式实现。对于每个verb,规范定义了:
- 输入的参数
- 返回结果,输出的参数
- verb的操作类型
verb layer可以通过访问HCA的硬件接口(例如寄存器组)来完成期望的动作,verb layer还有以下特性:
- 需要时会调用OS。例如它可以调用OS的内存管理器,为verb或者HCA的使用分配物理内存;
- 必须通过verb调用请求的操作,才能访问主存。例如,在特定的操作系统环境中,软件应用可以在主存中构建一个消息传输工作请求(WR),然后执行Post Send Request verb调用,将WR发布到QP的SQ中进行处理。它将在主存中提供WR的起始地址作为Post Send Request verb的输入参数之一,然后verb将访问主存以读取WR,将WR发送到目标QP的SQ。
装载QP操作特征的QP Context
在使用QP进行发送或接收信息前,软件会先创建一个QP,并提供一些其在发送、接收过程中需要用到的特征。QP Context大致会包含以下内容(每个内容的具体含义暂不展开介绍):
- 本地端口号(在QP创建时确定);
- QP类型;
- SQ开始PSN(SQ发送的第一包插入开始PSN,后续实时更新current PSN);
- RQ期望PSN;
- 最大payload尺寸(0.25KB、0.5KB、1KB、2KB、4KB,也被称作path maximum transfer unit,PMTU);
- 目标端的本地ID;
- 期望的本地QoS;
- 报文注入延迟(因为链路的宽度不同,内部报文延迟也不同,防止快速链路的流量超过较慢链路的流量,定义了强制观测延迟);
- 本地应答超时(指定时间内没收到ack报文,即为应答超时,需要重发对应报文);
- Ack timeout/丢包重传计数;
- RNR重传计数;
- 源端口本地ID;
- 全局的源端/目标端地址;
QP传输示例
本文以RC服务类型的QP举例,详细描述了QP是如何传输一个数据包的;
假设QP已创建,且:
- SQ PSN起始地址在CA X为100,CA Y为2000;
- QP都为刚创建完成状态;
- RQ 期望PSN CA X为2000,CA Y为100;
- 需要发送的信息为5KB,报文payload最大尺寸限制为2KB;
- Ack重传计数为7,RNR重传计数为7;
- Source CA与destination CA在同一子网下;
注意:这里只举例了报文第一包发送与响应过程,后续包的过程稍有不同,但整体类似。
发送第一个请求报文
-
SQ开始处理顶层条目,WQE指定一个多包发送操作,将5KB消息从HCA本地内存发送到对端CA的QP;
-
SQ检查QP Context中的PMTU来决定请求报文的最大数据大小,在本例中,SQ会选择前2KB数据作为第一个请求报文发送;
-
SQ在第一包的Opcode内容中填入Send first,向对端RQ表示,该包是第一发送包,并填入PSN=100,同时根据QP context内容设置目标QP;
注:RQ在接收到send last的报文前,都不知道报文的真实长度; -
SQ将请求包转发到端口X进行传输时,向端口提供基本LID地址的偏移量,以替代包的SLID;
-
SQ将第一个请求包内的DLID设置为目标CA端口的QP的DLID,DLID来自QP Context;
-
SQ根据QP context内容设置服务等级(Service Level);
-
如果请求操作中存在全局ID,SQ需要在第一包中插入GRH(但在本例中不需要);
-
Send操作的第一个请求包被发送到网络层,然后转发到HCA端口(X)的链路层。此外,SQ还做以下工作:
a) 将nPSN从100更新到101,这是将在发送的下一个请求包中插入的PSN。
b) 等待收到“Send First”请求包的对应Ack包。
c) 形成下一个请求包发送到链路层进行传输。 -
当从网络层接收到第一个报文后,端口的链路层将:
a) 在端口的base LID上加入偏移,并将此LID插入在请求报文中的SLID中;
b) 如果目标CA和源CA不在同一子网下,会生成一个128-bits的SGID;
c) 在配置过程中,SM设置了端口的SLtoVLMappingTable属性表,将16个可能的SL值映射到特定的链路层传输缓冲区。SM还建立了一个仲裁方案,为每个传输缓冲区分配一个重要级别。定义了传输缓冲区以什么顺序将数据包传输到端口的物理层;
d) 请求包被发布到链路层选择的传输缓冲上;
e) 当该VL传输缓冲区进行报文传输时,端口的链路层将请求报文转发给端口的物理层进行传输。数据包的VL字段标识了各自的VL接收缓冲区,该缓冲区将在与该端口连接的物理链路的另一端接收数据包。 -
从X链路层端口流出的请求报文将根据serdes的规范,编码为10-bits的串行流;
-
请求包经过一个或多个链路,最后到达目标端口。每个交换机查找内部转发表,并根据包内的DLID确认向何处转发;
-
目标QP端口对从物理层收到的数据解串行化,恢复8-bits数据流,并传递给链路层;
-
链路层解析包内的DLID项,确定数据前往哪个端口,并将数据传输到数据包指示的VL接收缓冲区,紧接着,请求包转发至网络层,网络层根据DestQP项将数据传递到对应RQ;
-
RQ将请求包的PSN与ePSN比较,确定是否出现丢包(如果PSN为之前请求包范围内的PSN,代表是一个重复包,不需要响应其动作,但要回复ack);
-
RQ将检查包的opcode,确认是否需要WQE将报文写入CA Y的本地内存中。如果opcode是send或RDMA write,WQE则需要完成此动作。如果RQ当前没有发布WQE,则需要返回对端SQ一个RNR NAK包;
-
进一步确认opcode,本例中为send first,不能是send middle,send last;
-
RQ返回一个ack包,并使用顶端的WQE确认将payload写入本地内存何处;
-
Payload使用散列缓冲链表写入CA本地内存中,同时RQ向WQE更新下一包需要写入的内存地址;
-
最后,RQ更新期望PSN(ePSN=101);
第一个ack包返回
当RQ成功接收send first包,返回ack包的过程如下:
- RQ将ack包发送到网络层,然后转发至端口的链路层;
- Ack包不包含payload,但是包含opcode和确认扩展传输头(AETH)字段,opcode表示这是一个Ack报文,AETH表示Ack报文的类型:positive Ack或negative Ack (Nak)。如果是Nak包,Nak的原因也会被指出;
- Ack的目标QP会被写入QPN;
- Ack包中的SL和请求包中的SL一致,SLID和DLID与请求包中相反;
- CA Y的端口根据SL查表确定,Ack包需要发布到哪个VL传输缓存;
- 当该VL缓存区传输时,将Ack包从链路层传给对应的物理层;
- 和之前物理层的处理一样,数据将被串行化,通过传输介质后,由另一端的物理层解串;
- 对端链路层解析包中的DLID,确定该传输到哪个端口;
- 链路层将接收到的ack包放至对应的VL接收缓存区,进一步转发至网络层;
- 网络层将ack包发送给对应SQ,QP与上一步发送请求报文的QP一致;
- SQ验证是否是ack包,检查PSN是否和send first包的PSN一致;
字体
滚滚滚color=#0099ff size=6 face="黑体"灌灌灌灌
滚滚滚color=#0099ff size=6 face="黑体"灌灌灌灌
滚滚滚color=#0099ff size=6 face="黑体"灌灌灌灌
滚滚滚color=#0099ff size=6 face="黑体"灌灌灌灌
滚滚滚滚滚滚热热热太阳眼镜
红:255,0,0 #FF0000
橙: 255,125,0 #FF7D00
黄:255,255,0 #FFFF00
绿:0,255,0 #00FF00
蓝:0,0,255 #0000FF
靛: 0,255,255 #00FFFF
紫: 255,0,255 #FF00FF加粗样式