基于窗口动态边界的RDMA读请求报文切割方法及系统与流程

摘要: 本发明涉及网络通信,尤其涉及基于窗口动态边界的rdma读请求报文切割方法及系统。背景技术:1、rdmaread(remotedirectmemoryaccess...
基于窗口动态边界的RDMA读请求报文切割方法及系统与流程

本发明涉及网络通信,尤其涉及基于窗口动态边界的rdma读请求报文切割方法及系统。

背景技术:

1、rdma read(remote direct memory access,rdma)是rdma(远程直接内存访问)操作中的一种单边操作(one-sided operation)。所谓“单边”,是指完成整个操作只需要请求方(initiator)的主动参与,而响应方(responder)的cpu无需介入处理或感知这次内存访问。这对于降低远程节点cpu开销、提升延迟和带宽至关重要。

2、一个rdma read请求报文的核心作用是:请求方直接从响应方的指定内存地址读取一段数据,并将其存储到请求方本地的指定内存地址中。

3、请求方rnic(网卡)构造并发送read请求报文。响应方rnic接收到报文后,无需唤醒响应方cpu,直接根据报文中的remote stag(这是一个“密钥”,它代表了响应方预先注册好的内存区域。只有持有这个密钥,请求方才有权限访问对应的远程内存)和目标内存信息校验访问权限。如果有效,则从对应的内存地址读取数据。

4、响应方rnic将读取到的数据封装在一个或多个rdma read响应报文中,发回给请求方。响应报文中也包含psn(packet sequence number,报文序列号,每个报文都有一个唯一的序列号,用于保证可靠传输和报文顺序。),与请求报文的psn相关联。

5、请求方rnic接收到read响应报文后,将其中的数据直接写入到指定的本地内存中,并通知请求方应用程序操作完成。

6、read请求报文的发送需满足以下条件:

7、1.报文的psn范围须与其要求读取的数据长度相对应;

8、2.报文的psn须处于当前允许发送的psn窗口(new allowed psn window)内。

9、该窗口大小通常由硬件寄存器与队列对上下文(qp context)共同决定,并随响应方已处理报文的psn动态调整。

10、new allowed psn window的大小一般由寄存器配置和qp context共同决定,在需要流控的情况下通过cc算法可以更灵活地动态调整,其位置根据响应方处理完的报文的psn值动态调整。

11、理论上,rc协议通过一个极大的psn空间(通常为22位或24位)和滑动窗口机制来管理报文发送与确认,其发送窗口(tx window)大小由协议本身的psn位数上限所定义。在此模式下,除非遇到极端的长延迟或重传场景,否则一个read请求报文因其psn范围超出这个巨大静态窗口而被阻塞的情况极为罕见。

12、然而,在现代数据中心网络中,为了应对网络拥塞、避免丢包、并保证公平性,rdma协议(如rocev2)通常需要与基于窗口的拥塞控制(window-based congestion control)算法(如dcqcn、hpcc等)协同工作。这些cc算法通过动态调整发送速率来响应网络状态。

13、其核心机制之一是动态调整每个队列对(qp)的允许发送窗口(new allowed psnwindow)大小。该窗口不再是一个固定的、巨大的理论值,而是一个由cc算法根据实时网络拥塞反馈(如ecn、cnp)动态计算出的、远小得多的值。具体表现为:

14、窗口收缩(shrink): 当网络出现拥塞时,cc算法会迅速减小new allowed psnwindow,以降低发送速率,缓解网络压力。

15、窗口增长(grow): 当网络畅通时,cc算法会逐步增大窗口,以提高吞吐量。

16、在这一背景下,现有技术中的拥塞控制方法主要聚焦于如何动态调整发送窗口或发送速率以适应网络状态,如公开号为cn115665046a公开了一种数据流控方法,包括:获取第一数量,第一数量为当前可发送数据包的数量;判断第一数量是否大于第一预设阈值;若是,则向接收端发送数据包,并在数据包发送成功时对第一数量进行实时更新;当检测到更新后的第一数量小于或等于第一预设阈值时,暂停向接收端发送数据包。相比于现有技术中,通过滑动窗口、拥塞队列等通讯时延较高的复杂机制来进行网络通讯。该专利虽然本可以解决了现有技术中网络通讯过程中产生的网络拥塞导致通讯时延增加的问题,但是其核心在于控制发送速率,而非解决大容量请求报文在受限窗口下的发送问题。

17、一个rdma read请求报文要求读取的数据长度(dma_len)决定了其需要使用的psn范围。当应用程序发起一个大规模数据读取请求时,其所需的psn范围可能非常大。

18、在标准rc协议中,这通常不是问题。但在启用了动态拥塞控制的场景下,一旦网络出现轻微拥塞,cc算法会立即收缩发送窗口。此时,一个正在等待发送的大尺寸read请求报文,其所需的psn范围([psn_nxt, read_req_eop_psn])很可能远超当前被收缩后的、较小的psn_allowed_max。

19、根据协议规则,整个read请求报文必须在其psn完全位于当前允许的窗口内时才能被发送。因此,请求方rnic只能暂停发送,等待响应方处理完窗口内的旧报文并返回ack,从而使窗口滑动、psn_unack更新后,才有可能获得足够的窗口空间。这种等待完全违背了rdma低延迟、高带宽的设计初衷,造成了:

20、链路带宽利用不足: 在等待窗口更新的空闲期,物理链路带宽被浪费。

21、传输效率下降: 整体传输时间被拉长,尤其在大规模数据读写或高并发场景中,性能下降尤为明显。

22、拥塞响应僵化: 发送端的停滞无法向cc算法提供有效的流量负载反馈,可能影响拥塞控制的准确性和敏捷性。

23、因此,迫切需要一种智能的方法,能够在动态小窗口的限制下,保证大尺寸read请求的持续、高效发送,从而弥补动态拥塞控制机制带来的这一副作用。

技术实现思路

1、本发明的目的是针对现有技术的缺陷,提供了基于窗口动态边界的rdma读请求报文切割方法及系统,能够在psn窗口受限的情况下,将大容量read请求报文分割为多个符合窗口限制的子报文,从而实现持续发送,提高带宽利用率和整体传输性能。

2、为了实现以上目的,本发明采用以下技术方案:

3、基于窗口动态边界的rdma读请求报文切割方法,应用于请求端设备,包括:

4、s1.获取待发送的读请求报文,所述读请求报文具有起始报文序列号和结束报文序列号;s2.获取当前允许发送的最大报文序列号值;

5、s3.获取当前的发送偏移量;

6、s4.判断读请求报文的结束报文序列号是否大于当前允许发送的最大报文序列号值,若是,则以当前允许发送的最大报文序列号值为切割边界,将读请求报文切割为第一子报文和第二子报文;若否,直接发送完整的读请求报文;

7、s5.发送第一子报文,并根据第一子报文所占用的报文序列号数量更新发送偏移量;

8、s6.将第二子报文作为待发送的读请求报文,获取更新后的当前允许发送的最大报文序列号值,重复执行步骤s3-s6,直至发送偏移量等于读请求报文的总报文序列号数量。

9、进一步的,所述步骤s2中当前允许发送的最大报文序列号值包括接收端下一个待处理的报文序列号,以及当前允许的未完成报文序列号数量。

10、进一步的,所述步骤s3中发送偏移量的初始值为零。

11、进一步的,所述步骤s4中第一子报文的报文序列号范围为从读请求报文的起始报文序列号至当前允许发送的最大报文序列号值。

12、进一步的,所述步骤s4中第二子报文的报文序列号范围为从当前允许发送的最大报文序列号值加1至读请求报文的结束报文序列号。

13、进一步的,切割方法在rdma请求端的网卡硬件固件或主机驱动软件执行。

14、相应的,还提供基于窗口动态边界的rdma读请求报文切割系统,用于执行所述的基于窗口动态边界的rdma读请求报文切割方法,切割系统包括处理器,所述处理器内设置有:

15、第一获取模块,用于获取待发送的读请求报文,所述读请求报文具有起始报文序列号和结束报文序列号;

16、第二获取模块,用于获取当前允许发送的最大报文序列号值;

17、第三获取模块,用于获取当前的发送偏移量;

18、判断模块,用于判断读请求报文的结束报文序列号是否大于当前允许发送的最大报文序列号值;

19、切割模块,用于判断模块的输出为是时,则以当前允许发送的最大报文序列号值为切割边界,将读请求报文切割为第一子报文和第二子报文;

20、发送模块,用于发送第一子报文;

21、偏移量管理模块,用于根据第一子报文所占用的报文序列号数量更新发送偏移量;

22、循环模块,用于将第二子报文作为新的待发送的读请求报文,触发所述第二获取模块、判断模块、切割模块、发送模块、偏移量管理模块重复执行,直至发送偏移量等于读请求报文的总报文序列号数量。

23、进一步的,所述处理器上连接有用于存储数据或指令的存储器。

24、进一步的,所述处理器上连接有用于与外部设备数据传输的传输设备。

25、进一步的,所述处理器上连接有用于与输入或输出信息的输入输出设备。

26、与现有技术相比,本发明具有以下有益效果:

27、在传统模式下,当请求数据量巨大而psn窗口较小时,整个传输过程会被分割为多个完整的“请求-响应”周期。每个周期结束后,发送方必须等待接收方的ack确认以滑动窗口,才能发起下一个read请求。这期间,链路带宽会因等待而闲置。

28、本发明通过动态切割,将一次大的read请求在窗口边界处“化整为零”,使得发送方可以持续不断地利用当前允许的每一个psn来发送请求片段,无需等待整个请求响应完成。它将等待时间从“一个完整的rtt(往返延迟)”缩短为“处理一个窗口片段的时间”,极大地减少了链路空闲时间。