参考论文SRDMA(A Scalable Architecture for RDMA NICs ):https://download.csdn.net/download/zz2633105/89101822
借此,对论文内容总结、加以思考和额外猜想,如有侵权,请联系删除。
如有描述不当之处,欢迎留言指正,拜谢!
概述
RDMA 被期望具有高度的可扩展性:在不可避免存在丢包的大规模数据中心网络中表现良好(高网络可伸缩性),并支持每个服务器的大量高性能连接(高连接可伸缩性)。商用 RoCEv2 网卡(rnic)由于依赖于无损的、有限规模的网络结构,缺乏可伸缩性,并且只支持少量的性能连接。最近的研究IRN通过放宽无丢包网络的要求来提高网络的可扩展性,但连接的可扩展性问题仍未得到解决。
本文描述旨在提高网络可伸缩性及连接可扩展性。
伸缩性
商用RoCEv2网卡基于目前以太网络设施部署,需要 PFC 来实现无损网络结构,基于优先级的流控制(PFC)引起了网络可伸缩性问题。 PFC 带来了诸如离线阻塞、拥塞扩散、偶尔死锁和大规模集群中的 PFC 风暴等问题 。因此,数据中心运营商倾向于将 PFC 配置限制在较小的网络范围内(例如,中等规模的集群)。
RoCEv2网卡通过特殊处理明显改善网络状况,方案有两种:1)引入额外内存开销的方案;2)扩展IB协议的选择性重传方案。
通过引入额外内存开销的方案
核心思想是:通过引入额外内存消耗的解决乱序问题、降低网络中负载以及选择性重传read response丢失的报文请求,可以一定程度上提高了网络伸缩性,但还需PFC协助尽可能减少丢包。
响应端
思路很简单,假定逻辑有非常大的缓存空间,将请求端所有包接收下来,对于乱序包则重排处理,对于丢包则等对端超时重传或主动NAK。
①一个数据包到达响应端,包的PSN与预期ePSN一致,则表示是正常顺序包,将由逻辑正常处理:对于send,先从RQ中取RWQE解析地址,再将数据写到host ddr;对于write/read,检查合法性无误则写入host ddr。
②数据包的PSN与预期ePSN不一致,则认为是乱序包,乱序包整包送入到QP的重排缓存区,进入OOO模式(乱序重排模式),由ePSN - PSN 计算出offset置位bitmap。
③当bitmap 0bit非0时,将通过data ptr指针找到乱序重排缓冲区0bit对应的整包,取到OOO模块解析处理,对于send,先从RQ中取RWQE解析地址,再将数据写到host ddr;对于write/read,检查合法性无误则写入host ddr。最后bitmap右移1bit,data ptr指向下一个packet。
④当bitmap全0时,退出OOO模式。
Reorder Buffer需要内存比较大,一般放在HOST DDR上,也就是说,对于乱序包,先送到HOST DDR重排缓存空间等待排队就绪,然后RNIC再从HOST DDR中读下来解析处理,最后送到HOST DDR真正的用户内存空间。相比乱序直接NAK让请求端重传的做法,这种方案只牺牲响应端部分PCIe带宽便可减小网络上压力,一定程度上提高了网络伸缩性。该方案QPC需要存放乱序维护结构,增加了sram消耗,此外,乱序重排BUF也需要占用host较大内存。
上述只能解决出现乱序报文问题,对于丢包则无太大益处。对于丢包,可直接等待请求端超时重传(时间较长),也可由响应端主动回复NAK触发重传。可选方案,以一定算法监测bitmap中空洞,当空洞较长时间未填补或后续bit位连续多个置位后,认为该空洞对应报文已丢失,主动触发NAK重传。
请求端
send & write & read
对于超时请求,正常重发;对于NAK请求,正常重发。
read response
请求端收到的read response可能乱序或丢包。
①收到read response PSN与预期ePSN一致,则认为是顺序包,将由正常传输逻辑处理送到HOST DDR。
②收到read response PSN与预期ePSN不一致,则认为发生了乱序或丢包,将进入SR(选择性重传)模式。接收的数据将正常送入用户HOST DDR中,同时由ePSN - PSN 计算出offset置位bitmap。
③当bitmap 0bit非0时,将整个bitmap右移,直到0bit为0。以一定算法监测bitmap中空洞,当空洞较长时间未填补或后续bit位连续多个置位后,认为该空洞对应报文已丢失,主动重传部分read请求。例如,请求端发起一个长度为7个pmtu的read请求报文,响应端接收请求回复7个pmtu报文,但是网络中丢失了0、4、6号报文,则请求端可以分别发送1个pmtu的read报文请求0、4、6号位置数据,从而选择性重传部分read请求,以便减少网络上负载,一定程度上提高了网络伸缩性。
由于是请求端主动发起的请求,所以只需要给活跃的QP的QPC中分配read response维护结构即可,对sram消耗增加不大。
扩展IB协议的选择性重传方案
核心思想:通过扩展IB协议,指示响应端准确的将任意包放入用户内存中,解决因乱序、丢包导致响应端无法立即处理报文问题;通过扩展IB协议,指示请求端需要重传哪些请求,精确重传丢失报文,去掉无效报文,保障了网络伸缩性。
当乱序或丢包发生,响应端接收报文无法正确处理,要么乱序重排,要么NAK重传,将极大影响吞吐率。通过扩展IB协议,在请求报文中额外附加信息告诉响应端怎么处理报文,实现报文就地重排上送用户内存中。
注意:发送端与请求端是在不同场景下不同称呼而已,同理接收端与响应端也是。
send
对于send报文,接收端接收到预期之外PSN报文将不知如何处理,如下图。
发送端发送了3个send报文,报文在网络中丢失了PSN0,接收端预期接收PSN0的报文,但却先接收到了PSN1的报文,此时接收端无法立即处理PSN1报文,因为接收端不知道PSN0的报文类型,不能准确使用RWQE(QP RQ中资源),只能将PSN1报文丢弃或放入缓存中等待乱序重排。
通过扩展IB协议,发送端在BTH之后附加SSN、PSN_OFFSET、RWQEN,那么接收端就可以准确处理任何send报文。
- 发送方发送了4个包给对面;
- 数据包在网络中丢失了3个;
- 接收端只接受到PSN4的数据包;
- 接收端根据包中扩展内容可以知道这个包需要使用RWQE1且数据偏移一个PMTU,接收端将数据放入用户内存;
- 接收端将乱序报文PSN与预期ePSN送给软件,由软件跟踪丢包信息。
可选的丢包恢复措施:
- 接收端软件择机触发硬件回复NAK(PSN 0)并附加指示信息指示对端重传哪些报文,例如丢包的bitmap信息0x0003,指示发送端精确重传丢失报文。
- 接收端等待ACK超时主动重传所有请求。
write
对于write报文,响应端接收到预期之外PSN报文将不知如何处,如下图。
请求端发送了3个报文,报文在网络中丢失了PSN0,接收端预期接收PSN0的报文,但却先接收到了PSN1的报文,此时接收端无法立即处理PSN1报文,因为write last中没有addr、key、len等信息。
通过扩展IB协议,请求端在BTH之后附加每个write需要写的目的addr、key、len、PSN_OFFSET,那么接收端就可以准确处理任何write报文。
- 请求端发送了4个包给对面;
- 数据包在网络中丢失了3个;
- 响应端只接受到PSN4的数据包;
- 响应端根据包中扩展内容查询MTT表项将数据写入用户内存;
- 响应端将乱序报文PSN与预期ePSN送给软件,由软件跟踪丢包信息。
可选的丢包恢复措施:
- 接收端软件择机触发硬件回复NAK(PSN 0)并附加指示信息指示对端重传哪些报文,例如丢包的bitmap信息0x0003,指示发送端精确重传丢失报文。
- 接收端等待ACK超时主动重传所有请求。
read
通过扩展IB协议,请求端在请求报文中添加本端数据存放的laddr、lkey、len等元数据信息,响应端回复read response中附加元数据信息返回给请求端。
对于read请求报文丢失,由请求端超时重发或响应端主动NAK请求端重发均可。
对于read response报文,由于response中携带有本地的laddr、lkey、llen、PSN_OFFSET等信息,可以任意接受乱序报文并准确将数据写入本端用户内存,此外由软件维护乱序response bitmap,以便决定选择性重传更小粒度read请求,如下图所示。
- 请求端发送read请求(IB协议本身包含对端raddr、rkey、len,扩展包含本端数据存放的laddr、lkey);
- 响应端接收请求根据rkey查询MTT,再从raddr开始读取len数据;
- 响应端组装read response报文,并附加请求端送来的元数据(laddr、lkey)以及len和PSN OFFSET;
- read response在网络中丢失了PSN1报文;
- 请求端接收到PSN0报文,根据扩展信息查询MTT并写入数据到用户内存;
- 请求接收到PSN2报文,发现与预取ePSN不一致,则进入丢包恢复流程,将报文元数据送给软件,但数据将写入用户内存中;
- 请求端软件以一定算法扫描bitmap空洞,择机选择性重传更小粒度read请求。
read response中携带PSN OFFSET是为了在丢包时好让软件跟踪bitmap。
注意:正常情况下,请求端本端会维护read未完成报文元数据PSN、 MSN、 PSN_OFFSET 之间的映射,所以响应端任意回复(乱序)报文也能正确放入本端用户内存中。那么为什么还要在read请求报文中添加本端数据存放的laddr、lkey、len等元数据信息呢?下面文章中揭晓。
连接扩展性
连接可伸缩性问题是当QP连接数量超过某个小阈值(如256)时,RDMA 性能急剧下降的现象,这种性能崩溃现象的根本原因是连接增多后,QP context之间的上下文切换导致缓存丢失 。
先看一张mlx实验性能图。
商用RNIC性能下降的根本原因通常被认为是缓存缺失。商用 RNIC 通常采用无 DRAM 架构,不将DRAM 直接连接到 RNIC 芯片以降低成本、功耗和面积,而只有有限的片上 SRAM。因此, rnic 只能在芯片上缓存少量 QP,而将其余 QP 存储在主机内存中。当活动 QP 的数量增加到超出片上内存大小时,频繁的缓存缺失和主机内存和 RNIC 之间的上下文切换将导致性能崩溃。上图中的实验在某种意义上证实了这一点,在性能崩溃期间,观察到显著的额外 PCIe 带宽(b绿色)和 ICM 缓存错误(b蓝色)的增加。这两个指标都反映了某些类型的缓存丢失,导致 256 个 QP 后额外的 PCIe 流量增加。
虽然片上 SRAM 是有限的,但性能下降这么早,这是不正常的。给定一个片上内存大小和 QP context(QPC)大小,可以估计在没有缓存丢失和性能崩溃的情况下可以支持的性能 QP 的最大数量: max_QPS=srma_memory_size/sizeof(QPC)。
以 Mellanox CX-5 为例。它的片上内存大小为2 MB,一个 QPC 需要375 B,因此 CX-5 支持的性能 QP 的最大数量可以达到 5.6K (2 MB/375 B),这与上图所示的事实相矛盾,即 CX-5 的性能在 256个 QP 时开始崩溃得更早。这种矛盾意味着存在显著提高连接可伸缩性的空间。 基于这一矛盾,系统地分析 rnic 的内存需求,并在深入分析内存的基础上提高了连接的可伸缩性。
由于商业 rnic 是黑盒,不能使用它们的微架构作为参考。本文利用具有选择性重传的有损 RDMA概念模型来推导相关的数据结构,将这些数据结构归纳归类为两类:RDMA 一般需要的通用数据结构和有损耗 RDMA 带来的选择性重传特定数据结构,并分别讨论了将其最小化的不同优化策略,以提高连接的可伸缩性。
上图前三列显示了典型的数据结构及其使用 10K qp 时的内存需求。
通用数据结构
一般来说,公共数据结构对于 RDMA 是必不可少的,无论底层网络是有损耗的还是无损耗的。
Receiving Buffer
Receiving Buffer:RNIC网卡模块中的接收缓冲区用于对所有传入数据包进行排队。它的主要目的是吸收由上游以太网端口和整个下游 RNIC 处理逻辑之间的时间性能差距引起的突发。
优化方案:这部分结构是必须的,暂时无更好的优化方案。
QPC
QPC:维护一个 QP 的所有上下文,包括 DMA 状态(例如,开始和结束地址, SQ 和 RQ 的读写指针)和连接状态(例如,期望和下一个数据包序列号,拥塞控制的窗口或速率)。为每个 QP 分配的 QPC 大小为210 B,因此 10K QP 的总大小为 2.0 MB。
优化方案:将QPC拆成SQC和RQC两部分。对于RQC,由于不能预先知道什么时候会收到send报文,因此所有RQC都必须放置在本地SRAM中;对于SQC,由于本端知道何时调度到这个QP,可以将所有SQC放在host DDR中,本地只存放活跃QP(由调度模块调度就绪排队的QP,参见WQE Cache部分)的SQC。
注意:该部分的优化是个人猜想,在SRNIC原文中并未对其优化。
MTT
MTT:RDMA 使用数据包中的虚拟地址,而 PCIe 系统依赖于物理地址来执行 DMA 事务。为了执行地址转换, RNIC 维护一个 MTT 来将内存区域的虚拟页映射到物理页。 MTT 的大小取决于内存区域的总大小和页面大小,与连接数无关。
SRNIC原文中只描述了SRAM存放一个MTT表(4G内存)存放大小优化,这对应商用rnic是不可取的,因为多个QP的SQ和RQ可能同时需要查不同MTT表。
优化方案:将MTT一级表放本地SRAM,由key索引,MTT二级表放HOST DDR,同时让HOST使用2MB巨页存放用户数据和QP Buf,尽可能的减小MTT表项大小以及提高MTT一级表直接击中连续物理地址的概率。
WQE Cache
WQE Cache:SQ WQE 缓存可以用于缓存从主机内存中的 SQ 中获取的 Send WQE。假设每个 QP 在专用缓存中存储 8 个 WQEs (64b *8), 10K QP 占用 4.9 MB 的片上内存。类似地, RNIC 需要从 RQ 中获取 ReceiveWQEs 来处理传入的 SEND 请求,并且可以分配一个 RQ WQE 缓存来存储获取的 Receive WQEs。 RQ WQE缓存的内存大小与 SQ WQE 缓存的内存大小相似。
优化方案:
RQ:对于RWQE,由于难以预测哪个QP会收到对端的send报文,因此需要为每个QP都预取一些RWQE下来,但这样将大量浪费SRAM,因此决定采用无预取RWQE的方案,而是将RQC放到本地SRAM中,当接受到send报文便查询RQC拿到RQ Buf地址,再去host 取下RWQE使用,相比于提前预取RWQE多出1us左右的PCIe数据来回时延,但在数据中心,小消息的典型 RDMA 网络延迟是几十微秒,增加的 1µs 延迟一般可以忽略不计。对于延迟敏感的场景(1µs 很重要),例如机架级部署,可以通过SRQ的RWQE 缓存以优化延迟,即SRQ支持RWQE预取,减小片上SRAM需求,但对应用编程有挑战。
注意:SRNIC原文描述的是RQ使用共享RWQE Cashe的策略优化延时,但这还是难以解决大量QP突发性收到send的问题,因此从用户使用场景上要求以及逻辑配合优化更加容易实现,即SRQ预取方案。
SQ:SQ 在包含 WQE 时是活动的,在其他情况下是不活动的。 SQ 调度器每次从主机内存中的数万个SQs 中选择一个活动 SQ 来发送接下来的消息。SQ 调度器的设计挑战如下:
- 挑战1:活动 SQs 不能盲目调度,因为它们也受到拥塞控制。一个 SQ 一旦被调度,如果由于拥塞控制的信用不足而不允许发送消息,调度不仅不能生效,而且会浪费时间,降低性能。
- 挑战2:RNIC 和主机内存之间的 PCIe 往返延迟很高(基于 FPGA 的 RNIC 大约 1µs),并且至少需要两个 PCIe事务(一个 WQE 获取和一个消息获取)来执行一个调度决策。如果没有仔细的设计,调度迭代之间的高延迟将显著降低性能。
- 挑战#3:主机内存中有成千上万个 SQs,但 RNIC 内的片上内存非常有限。禁止在 RNIC 中为不同的 SQs 使用单独的 WQE 缓存。
为了解决这些挑战,提出指导原则:SQs 应该在它们既活跃又有信用时调度,即应对挑战1;使用适当的批次处理事务和少量WQE缓存,来隐藏PCIe 延迟,即应对挑战2和挑战3。
在这些原则的指导下,提出了一种无缓存 SQ 调度器,它可以在数万个 qp 之间进行快速调度,并且对片上内存的需求最小。
事件 Mux (EMUX): EMUX 模块处理所有调度相关事件,包括,(1)来自主机的 SQ 门铃(doorbell),以指示哪个 SQ 有新的 WQEs 和消息要发送;(2)来自拥塞控制模块的信用更新,以指示连接/SQ 的窗口或速率调整;(3)从调度队列中 dequeue 事件,表示一个 SQ 已被调度。 在接收到一个事件时, EMUX 改变 QPC 中的调度状态。有三种调度状态:active状态表示 SQ 有 WQEs;credit 值表示允许发送的消息字节数, ready 状态表示 SQ 在调度队列中并准备调度。一个 SQ 只有在它既活跃又有可用积分时才准备好调度,这解决了挑战#1。
Scheduler:调度器利用一个调度队列来维护准备进行调度的 SQs 列表。调度器在调度策略模块中实现循环策略,每次从调度队列头部弹出一个就绪 SQ,并从该 SQ 获取给定数量的 wq 和消息。在这个调度迭代之后,如果SQ 仍然准备好调度,它将被 EMUX 推回调度队列。其他调度策略(例如,加权轮询和严格优先级)可以通过修改调度策略模块来实现。
DMA 引擎:当调度一个 SQ 时, DMA 引擎从该 SQ 中获取最多 n 个 WQEs 和最小(burst_size,credit)字节的消息来解决挑战2。在调度迭代之后,如果与 n 个 WQEs 相关联的总消息大小超过 min(burst_size,credit)字节,则RNIC 中可能还有未使用的 WQEs。未使用的 wq 将被丢弃,而不是缓存在 RNIC 中,并且它们将在下一次SQ 被调度时再次获取。 使用少量WQE缓存来隐藏读取WQE时PCIe来回时延,也就是说,至少保证一次PCIe来回时延内,之前QP取下的WQE缓存未消耗完,这种原则下,能够实现少量WQE缓存调度,以解决挑战3。
有两个关键参数(n 和 burst_size)来平衡权衡。 n 是 wqe 的最大数量, burst_size 是在每个调度迭代中允许获取的消息的最大字节数。 n 反映了 PCIe 带宽使用和 PCIe 延迟隐藏之间的权衡。 n 越小,在取-放策略中浪费的PCIe 带宽就越少,但很难隐藏 PCIe 延迟或让小消息饱和 PCIe 带宽,而 n 越大则相反。“SRNIC”中, n = 8是为了平衡 PCIe 的带宽利用率和隐藏时延。在此设置下,单个 QP 的最大消息速率为每秒 800 万请求(Mrps)(即每 1µs 8 条消息)。至于 burst_size,它反映了 PCIe 带宽利用率和调度粒度之间的权衡。更小的burst_size 可以实现更细的调度粒度,因此 HoL 更少,但更难饱和 PCIe 带宽,而更大的 burst_size 则相反。基于此分析,将 burst_size 设置为 PCIe BDP,即 16kb,以平衡性能和调度粒度。
注意:SRNIC原文描述可以无WQE缓存,但从SRNIC使用来看,至少也需要8个WQE缓存(n=8),此外,文章没有考虑商用rnic最差情况,即每个活跃QP只有一个WQE可以使用,因此需要更多WQE缓存,但这个缓存对于整个片上SRAM来说是极小的。
选择重传特定数据结构
这些数据结构都是由有损耗 RDMA 引入的,采用选择性重传作为损耗恢复机制。
Bitmap
Bitmap:位图用于跟踪接收或丢失的数据包。正如 IRN(Revisiting network support for rdma,In Proc. SIGCOMM, 2018)中提到的,每个 QP 需要 5 个 BDP(带宽延迟乘积,bandwidth-delay product)大小的位图(每个位图有 500 个插槽,以适应带宽 100 Gbps 和 RTT 40µs的网络的 BDP 上限), 10K QP总共需要 3.0 MB 内存。
优化方案:
可以观察到,当没有丢包或乱序时,来自同一个 QP 的数据包依次发送和接收,响应端一个期望的 PSN (ePSN)和请求端一个最后确认的 PSN (lACK)就足以分别跟踪请求和响应数据包的顺序接收,而不需要bitmap来跟踪;丢包或乱序时出现OOO报文,位图只用于跟踪 OOO 报文。
基于上述观察,为每个 QP 维护一个 ePSN 和 QPC 中的 lACK 来处理硬件中的顺序数据包,并将所有bitmap加载到主机内存中以跟踪 OOO 数据包。假设丢包率较低且以顺序包为主,则大部分流量由硬件直接处理,少量包含 OOO 包的流量由软件处理,占用主机内存的位图占用内存。通过这种方式,实现了高性能和高连接可伸缩性之间的平衡。
下图展示基本处理流程:
响应端
①接收到报文判断是否与预期ePSN一致;
②对于PSN与ePSN一致的报文,将送入正常传输逻辑处理;对于PSN与ePSN不一致的报文,将数据存入用户内存后,再将把ePSN与报文基本信息送入系统软件(一般是host驱动)由软件追踪,并使硬件进入OOO模式(乱序报文),后续进入硬件都报文即使PSN与ePSN一致,也会把报文基本信息送给软件,直到OOO模式退出;
③软件跟踪丢包bitmap,当0 bit开始出现连续1且后续再无1,则更新逻辑ePSN并退出OOO模式。
请求端
①收到响应端回复的报文,判断与预期ePSN是否一致;
②对于PSN与ePSN一致的报文,将送入正常传输逻辑处理并更新ePSN;对于PSN与ePSN不一致的报文,将数据存入用户内存后(read response),再将把ePSN与报文基本信息送入系统软件(一般是host驱动)由软件追踪,并进入丢包恢复模式;注意,这里read response能够准确放入用户内存是因为附加了额外的请求信息,查看 扩展IB协议的选择性重传方案 read部分;
③软件跟踪丢包bitmap(一般是read response),择机决定选择性重传更小粒度read请求,重传请求通过每个QP的重试队列提交;当所有重传报文都成功下发后(收到ACK),请求端退出丢包恢复模式。
可选的丢包恢复措施:
①响应端软件择机触发硬件回复NAK并附加丢包的bitmap信息,指示发送端精确重传丢失报文。
②请求端超时重发所有请求(非read)。
上面描述处理方案可以将片上Bitmap结构移到host软件(一般是driver),去除大量sram消耗。
Reordering Buffer
Reordering Buffer:重排序缓冲区用于重新排列无序的数据包,并确保有序地传递到主机内存中的数据缓冲区。重排序缓冲区在标准 RoCEv2 报头的有损 RNIC 实现中是必需的。由于 RoCEv2 是为无损网络设计的,它的报头缺乏必要的信息来支持无序数据包接收,而没有额外的重排序缓冲区。 一种选择是为每个 QP 分配单独的重排序缓冲区。每个 QP 需要一个 bdp 大小(0.5 MB)的重排序缓冲区,因此支持 10K QP 需要 4.9 GB内存。 另一种选择是为所有 qp 维护一个共享的重排序缓冲区,但它无法扩展,当多个 qp 遇到乱序包时,由于片上 SRAM 有限,它可能很快就会耗尽共享缓冲区。
优化方案:每个 QP 使用重排序缓冲区重新排列 OOO 包,并确保按顺序传递到用户应用程序的数据缓冲区。通过就地重排可以拜托每个 qp 的重排序缓冲区,即利用固定在主机内存中的用户数据缓冲区作为重排序缓冲区。为了实现这一点,所有传入的数据包都应该直接放在正确地址的用户缓冲区中。 如 扩展IB协议的选择性重传方案 部分描述的一样,可以进行一下操作:1)有 SEND 包都携带发送消息序列号(SSN)、PSN_OFFSET、RWQEN,RNIC 接收端可以使用它来定位相应的接收 WQE 及其相关接收缓冲区中的偏移量;2)所有的write报文都携带它们的目标addr、key、len、PSN_OFFSET;3)所有的read response都携带addr、key、len、PSN_OFFSET。
Outstanding Request Table
Outstanding Request Table:未处理请求表用于维护未处理请求报文与其元数据之间的映射关系,用于快速定位和重传丢失报文。这些元数据包括,(1)数据包序列号(PSN),用于跟踪数据包序列, (2)消息序列号(MSN),用于跟踪消息序列并快速定位与该消息相关的 WQE,以及(3)数据包偏移量(PSN_OFFSET),用于定位相应数据缓冲区中的数据偏移量。使用这些字段,每个 QP 的未完成请求表大小为 11.7 KB(假设条目大小为 24 B,条目数500,大小为 BDP), 10K QP 总共消耗 114.4 MB。
优化方案:通过在包头上携带这些每个包的元数据,而不是将它们存储在片上存储器中。具体来说,让所有未完成的请求包在它们的头上携带这些元数据,并让它们的响应包回显相同的元数据。通过这种方式,请求端可以使用响应包报头中的元数据快速定位 WQE 及其消息。
在 扩展IB协议的选择性重传方案 read部分说道‘为什么还要在read请求报文中添加本端数据存放的addr、lkey、len等元数据信息呢’,原因就是去除Outstanding Request Table结构。
总结
通过上面所述优化,可以节省大量sram,从而存放更多的QPC,进而大幅度提高连接扩展性,即大规模连接下不会损失性能。此外,通过扩展IB协议可能很好的应对无损和有损网络,大幅度降低对PFC需求,甚至可以摒弃PFC。