中国住房与城乡建设厅网站,亚马逊查关键词搜索量的工具,网页源代码修改后怎么保存,大庆医院网站建设方案本文首发于#xff1a;RDMA在典型场景下的技术应用分析与探索 1.业务适配RDMA类型
RDMA传输的适配#xff0c;从业务场景的使用角度来看#xff0c;大致可分为如下几种类型。
场景一#xff1a;机器学习、分布式存储等场景#xff0c;使用社区成熟的方案#xff0c;如在…本文首发于RDMA在典型场景下的技术应用分析与探索 1.业务适配RDMA类型
RDMA传输的适配从业务场景的使用角度来看大致可分为如下几种类型。
场景一机器学习、分布式存储等场景使用社区成熟的方案如在机器学习场景中使用的NCCL、Tensorflow等框架中都适配了多种传输方式包含tcp、rdma等块存储Ceph中也同时支持tcp及rdma两种通信模式这种业务场景下业务侧更多关注的是配置及使用在IAAS基础设施侧将RDMA环境准备好后使能框架使用rdma的传输模式即可。
场景二业务程序使用类似于RPC远程调用的通信方式业务侧需要将原有使用的RPC大部分是GRPC调用改为ORPC调用在这种场景下业务和传输更像是两个独立的模块通过SDK的方式进行调用所以适配起来改造的代码并不多通常是业务层面修改调用RPC的接口方式。但由于业务方可能使用多种编程语言RPC over RDMA需要进行编程语言进行适配。
场景三业务程序通信是私有化通信比如使用socket套接字结合epoll完全自有实现的一套通信机制。这种场景下其实改造也区分情况即业务IO与网络IO是否耦合若比较解耦代码中抽象出一层类似于最新Redis代码中ConnectionType这样的架构[2]那么只需要实现一套基于RDMA通信且符合Redis ConnectionType接口定义的新传输类型即可改造量相对可控并且架构上也比较稳定而若业务IO与网络IO结合的较为紧密的情况下这种场景下往往改造起来会比较复杂改造的时候需要抽丝剥茧的找出业务与网络之间的边界再进行网络部分的改造。
2.Redis RDMA改造方案分析
首先以Redis改造为RDMA传输为例分析基于RDMA传输的应用程序改造逻辑与流程。
第一步是需要梳理出来Redis中与网络传输相关的逻辑这部分有比较多的参考资料这里简单总结一下。 Redis中实现了一套Reactor模式的事件处理逻辑名为AE其主要流程为
1、使用epoll等机制监听各文件句柄包括新建连接、以及已建立的连接等
2、根据事件的不同调用对应的事件回调处理
3、循环进行epoll loop并进行处理。
参考[2]中分析了当前redis的连接管理是围绕connection这个对象进行管理可类比socket套接字的管理抽象一层高于socket的connection layer以便兼容不同的传输层各个字段解释如下。 type各种连接类型的回调接口定义了诸如事件回调、listen、accept、read、write等接口类比tcp socket实现的proto_ops。
state当前连接的状态如CONNECTING/ACCEPTING/CONNECTED/CLOSED等状态类比TCP的状态管理。
fd连接对应的文件句柄。
iovcnt进行iov操作的最大值。
private_data保存私有数据当前存放的是redis中client的指针。
conn_handler/write_handler/read_handler分别对应连接connect、write、read时的处理接口。
get_type: connection的连接类型当前redis已支持tcp、unix、tls类型返回字符串。
init在每种网络连接模块注册时调用各模块私有初始化如tcp、unix类型当前未实现tls注册时做了一些ssl初始化的前置工作。
ae_handler: redis中的网络事件处理回调函数redis中使用aeCreateFileEvent为某个fd及事件注册处理函数为ae_handler当redis的主循环aeMain中发现有响应的事件时会调用ae_handler进行处理如在tcp连接类型中ae_handler为connSocketEventHandler该函数分别处理了链接建立、链接可读、链接可写三种事件。
listen: 监听于某个IP地址和端口在tcp连接类型中对应的函数为connSocketListen该函数主要调用bind、listen。
accept_handler: redis作为一个服务端当接收到客户端新建连接的请求时候的处理函数一般会被.accept函数调用比如在tcp连接类型中connSocketAccept调用accept_handler该方法被注册为connSocketAcceptHandler主要是使用accept函数接收客户端请求并调用acceptCommonHandler创建client。
addr: 返回连接的地址信息主要用于一些连接信息的debug日志。
is_local返回连接是否为本地连接redis在protected模式下时调用该接口判断是否为本地连接进行校验。
conn_create/conn_create_accepted创建connection对于tcp连接类型主要是申请connection的内存以及connection初始化工作。
shutdown/close释放connection的资源关闭连接当某个redis客户端移除时调用。
connect/blocking_connect实现connection的非阻塞和阻塞连接方法在tcp连接类型中非阻塞连接调用aeCreateFileEvent注册连接的可写事件继而由后续的ae_handler进行处理实现非阻塞的连接而阻塞连接则在实现时会等待连接建立完成。
accept该方法在redis源码中有明确的定义可直接调用上述accept_handlertcp连接类型中该方法被注册为connScoketAccept。
write/writev/read和linux下系统调用write、writev、read行为一致将数据发送至connection中或者从connection中读取数据至相应缓冲区。
set_write_handler注册一个写处理函数tcp连接类型中该方法会注册connection可写事件回调函数为tcp的ae_handler。
set_read_handler注册一个读处理函数tcp连接类型中该方法会注册connection可读事件回调函数为tcp的ae_handler。
sync_write/sync_read/sync_readline同步读写接口在tcp连接类型中实现逻辑是使用循环读写。
has_pending_data检查connection中是否有尚未处理的数据tcp连接类型中该方法未实现tls连接类型中该方法被注册为tlsHasPendingDatatls在处理connection读事件时会调用SSL_read读取数据但无法保证数据已经读取完成[3]所以在tlsHasPendingData函数中使用SSL_pending检查缓冲区是否有未处理数据若有的话则交由下面的process_pending_data进行处理。has_pending_data方法主要在事件主循环beforesleep中调用当有pending data时事件主循环时不进行wait以便快速进行下一次的循环处理。
process_pending_data处理检查connection中是否有尚未处理的数据tcp连接类型中该方法未实现tls连接类型中该方法被注册为tlsProcessPendingData主要是对ssl缓冲区里面的数据进行读取。process_pending_data方法主要在事件主循环beforesleep中调用。
get_peer_certTLS连接特殊方法。
结合当前代码中tcp及tls实现方法梳理出和redis connection网络传输相关的流程 图Redis Connection Call Graph 对于redis来说新增一个RDMA方式的传输方式即是要将connection中的各种方法按照上述定义去使用RDMA编程接口去实现。RDMA编程一般采用CM管理连接加Verbs数据收发的模式客户端与服务端的交互逻辑大致如下图所示,参考[16]。 字节跳动的pizhenwei同学目前在redis社区中已经提交了redis over rdma的PR参见[4]具体的代码均在rdma.c这一个文件中。由于RDMA在做远程内存访问时需要使用对端的内存地址所以作者实现了一套RDMA客户端与服务端的交互机制用于通告对端进行远程内存写入的内存地址参见[5]。 交互逻辑及说明如下
1、增加了RedisRdmaCmd用于Redis客户端与服务端的控制面交互如特性交换、Keepalive、内存地址交换等
2、在客户端及服务端建立完成RDMA连接后需要先进行控制面的交互当内存地址交换完成后方可以进行Redis实际数据的交互及处理
3、控制面消息通过IBV_WR_SEND方式发送Redis数据交互通过IBV_WR_RDMA_WRITE_WITH_IMM发送通过方法的不同来区分是控制面消息还是Redis的实际数据 4、客户端及服务端共享了一片内存则需要对内存的使用管理目前有三个变量用户协同读写双方的内存使用。
tx.offset为RDMA发送侧已经对内存写入的偏移地址从发送端角度看内存已经使用到了tx.offset位置下次发送端再进行RDMA写入时内存地址只能为tx.offset 1rx.offset为RDMA接收侧已经收到的内存偏移地址虽然数据可能实际上已经到了tx.offset的位置但由于接收侧需要去处理CQ的事件才能获取到当前数据的位置rx.offset是通过IMM中的立即数进行传递的发送侧每次写入数据时会将数据长度所以rx.offset tx.offsetrx.pos 为接收方上层业务内存的偏移地址rx.pos rx.offset。
5、当rx.pos等于memory.len时说明接收侧内存已满通过内存地址交换这个RedisRdmaCmd进行控制面交互将tx.offset、rx.offset、rx.pos同时置零重新对这片共享内存协同读写。 Connection各方法的主要实现逻辑及分析如下
listen主要涉及RDMA编程图示中listen、bind的流程结合redis的.init相关调用流程会将cm_channel中的fd返回给网络框架AE当后续客户端连接该fd时由AE进行事件回调即后续的accepHandler。
accept_handler该函数作为上述listen fd的事件回调函数会处理客户端的连接事件主要调用.accept方法进行接收请求并使用acceptCommonHandler调用后续的.set_read_handler注册已连接的读事件参见图Redis Connection Call Graph。
accept要涉及RDMA编程图示中accept的流程处理RDMA_CM_EVENT_CONNECT_REQUEST、RDMA_CM_EVENT_ESTABLISHED等cm event并进行cm event的ack。
set_read_handler设置连接可读事件的回调为.ae_handler。
read_handler实际处理中会被设置为readQueryFromClient。
read从本地缓冲区中读取数据该数据是客户端通过远程DMA能力写入。
set_write_handler将write_handler设置为回调处理函数这里和tcp、tls实现的方式有所区别并没有注册connection的可写事件回调是因为RDMA中不会触发POLLOUT可写事件connection的写由ae_handler实现。
write_handler实际工作中被设置为sendReplyToClient。
write将Redis的数据拷贝到RMDA的本地缓冲区中通过ibv_post_send这部分数据会通过远程DMA能力写入对端。
has_pending_data检查内部的pending_list在收到RDMA_CM_EVENT_DISCONNECTED等事件时会将当前connection加入到pending_list中由后续beforeSleep时调用process_pending_data进行处理。
process_pending_data检查pending的connection并调用read_handler读取connection中的数据。
ae_handler该方法有三个处理流程第一是处理RDMA CQ事件包括接收处理RedisRdmaCmd控制面消息接收RDMA IMM类事件增加rx.offset第二是调用read_handler和write_handler这部分是与tcp、tls流程一致第三是检查rx.pos和rx.offset的值若rx.pos memory.len时发送内存地址交换这个RedisRdmaCmd控制面消息。
3.Redis RDMA测试
Redis测试通常采取自带的redis-benchmark工具进行测试该工具复用了redis中的ae处理逻辑并调用hiredis进行redis数据的解析在参考[6]中fork并改造了一份基于RDMA的redis-benchmark可直接编译使用接下来使用该工具进行tcp及RDMA方式的性能测试对比。
在实际测试中使用的是同一个交换机下的两台服务器传输方式是rocev2经过qperf的测试tcp的latency为12usrocev2的latency为4us。 3.1 单并发单线程
TCP方式
RedisServer./src/redis-server --protected-mode no
RedisBenchmark./src/redis-benchmark -h xx.xx.xx.xx -p 6379 -c 1 -n 500000 -t get RDMA方式
RedisServer./src/redis-server --loadmodule src/redis-rdma.so port6379 bindxx.xx.xx.xx --protected-mode no
RedisBenchmark./src/redis-benchmark -h xx.xx.xx.xx -p 6379 -c 1 -n 500000 -t get --rdma 3.2 多并发多线程
Redisbenchmark单线程4连接 Redisbenchmark单线程8连接 Redisbenchmark单线程16/32连接 注在我们的测试环境中16个连接时redis-benchmark已经100%再进行增加连接数测试时qps也不会再增加。
Redisbenchmark 4线程4连接 Redisbenchmark 4线程16连接 Redisbenchmark 4线程32/64连接 注在我们的测试环境中4线程32连接时redis-server已经100%再进行增加连接数测试时qps也不会再增加。
更多的连接和线程 3.3 测试总结 整体而言在我们的测试环境下redis服务能力rocev2rdma的传输方式相较tcp有~50% 到 ~100%左右的能力提升。可以发现由于rdma bypass了内核协议栈相同物理拓扑下redis一次读取时延下降了16us左右见3.1单并发测试数据这里额外做了一个测试选取了另外一组相隔较远的机器进行测试发现读取时延仍然缩小的是这个数量级见下图。 rdma方式建链的时间较长实际测试中连接数越多redis-benchmark真正开始测试的时间越长。
4.开源程序基于RDMA方案
4.1 Tensorflow RDMA
Tensorflow是一个广泛使用的深度学习框架在Tensorflow中数据通常表示为Tensor张量Tensor是一个多为数据可以在不同的设备之间进行传输以便进行分布式计算。
在分布式系统中Tensorflow可以通过网络传输将Tensor从一个节点传输到另一个节点从1.1版本开始支持RDMA传输以下为其基于RDMA传输的主要方案参考[7] [8]。
在RDMA传输通道建立之前使用基于tcp的grpc通道传输传递RDMA的内存地址、MR key、服务地址等信息内存拷贝方案
a对于可以DMA的Tensor包括CPU上的内存或者GPU Direct的内存采用直接从源Tensor写到目标Tensor中的方案实现内存零拷贝
b对于非DMA得Tensor用protobuf序列化后通过RDMA方式写到接收端预先注册的内存中
c对于不支持GPU Direct的Tensor通过RDMA方式写到接收端的CPU内存再在接收端通过拷贝的方式到GPU中发送与接收CPU之间不存在内存拷贝
内部使用RdmaBuffer用于RDMA读写的内存单元RdmaBuffer有三个派生类分别是RdmaAckBuffer、RdmaMessageBuffer和RdmaTensorBufferRdmaMessageBuffer负责发送 message 比如请求一个tensor等等。一旦一个message被发送message的接收方需要通过RdmaAckBuffer发送一个ack来释放发送方的message buffer。一个RdmaAckBuffer和唯一的RdmaMessageBuffer绑定。RdmaTensorBuffer负责发送tensortensor的接收方需要返回一个message来释放发送方的buffer对于一个具体的recv和send流程如下 a接收侧发送RDMA_MESSAGE_TENSOR_REQUEST消息其中包含目的Tensor的地址以用于发送侧进行RDMA写入。
b为避免在每个步骤中发送额外的元数据消息为每个Tensor维护一个本地元数据缓存仅在更改时才会更新每个RDMA_MESSAGE_TENSOR_REQUEST将包含接收方从本地缓存中获取的元数据。发送方将比较消息中的元数据和Tensor的新元数据如果元数据更改发送侧发送包含新元数据的RDMA_MESSAGE_META_DATA_RESPONSE。
c当接收方收到 RDMA_MESSAGE_META_DATA_RESPONSE 时将更新本地元数据缓存重新分配结果/代理Tensor重新发送Tensor请求。为了可追溯性新的消息具有不同的名称RDMA_MESSAGE_TENSOR_RE_REQUEST。
d当发送方收到 RDMA_MESSAGE_TENSOR_RE_REQUEST 时它将使用消息中指定的请求索引定位相关的 RdmaTensorResponse并调用其 Resume方法该方法将 RDMA 写入之前克隆的Tensor的内容到重新请求中指定的新远程地址。
e当接收方接收到 RDMA 写入时它将使用立即值作为请求索引找到相关的 RdmaTensorRequest然后调用其 RecvTensorContent方法包含可能存在的内存复制、反序列化等工作。 4.2 Brpc RDMA
百度的brpc当前的RDMA传输实现中数据传输是使用RMDA_SEND_WITH_IMM进行操作这就要求接收端在接收数据前要先准备好内存并预先POST RECV。为了实现高效的内存管理brpc内部实现了静态内存池且在RDMA数据传输实现中做了如下几点优化参考[9][10]。
数据传输零拷贝要发送的所有数据默认都存放在IOBuf的Block中因此所发送的Block需要等到对端确认接收完成后才可以释放这些Block的引用被存放于RdmaEndpoint::_sbuf中。而要实现接收零拷贝则需要确保接受端所预提交的接收缓冲区必须直接在IOBuf的Block里面被存放于RdmaEndpoint::_rbuf。注意接收端预提交的每一段Block有一个固定的大小recv_block_size。发送端发送时一个请求最多只能有这么大否则接收端则无法成功接收。数据传输有滑动窗口流控这一流控机制是为了避免发送端持续在发送其速度超过了接收端处理的速度。TCP传输中也有类似的逻辑但是是由内核协议栈来实现的brpc内实现了这一流控机制通过接收端显式回复ACK来确认接收端处理完毕。为了减少ACK本身的开销让ACK以立即数形式返回可以被附在数据消息里。数据传输逻辑的第三个重要特性是事件聚合。每个消息的大小被限定在一个recv_block_size默认为8KB。如果每个消息都触发事件进行处理会导致性能退化严重甚至不如TCP传输TCP拥有GSO、GRO等诸多优化。因此brpc综合考虑数据大小、窗口与ACK的情况对每个发送消息选择性设置solicited标志来控制是否在发送端触发事件通知。
4.3 NCCL RDMA
NCCL的网络传输实现是插件式的各种不同的网络传输只需要按照ncclNet中定义的方法去具体实现即可。
其中最主要的是isend、irecv及test方法在调用 isend 或 irecv 之前NCCL 将在所有缓冲区上调用 regMr 函数以便 RDMA NIC 准备缓冲区deregMr 将用于注销缓冲区。
以下是NCCL RDMA的实现部分逻辑基于当前NCCL最新版本GitHub - NVIDIA/nccl at v2.18.3-1分析主要参考[11]及参考[12]当前实现与参考中略有不同.
在NCCL基于RDMA的传输实现中目前的数据传输主要是通过RDMA_WRITE操作由于发送端进行RDMA_WRITE时需要预先知道对端的DMA地址NCCL中发送/接收端是通过一个缓冲区ncclIbSendFifo进行交互ncclIbSendFifo是发送端申请的一块内存缓冲区在connect与accept阶段通过传统tcp socket的方式携带给接收端在接收端异步进行接收时recvProxyProgress调用irecv接口进行接收在RDMA的实现中对应的是将本端DMA的地址通过ncclIbSendFifo RDMA_WRITE至发送端发送端进行发送时sendProxyProgress调用isend接口进行发送在RDMA中对应的是从ncclIbSendFifo中获取接收端的DMA地址将上层的data直接RDMA_WRITE至接收端的DMA地址中 接收端维护本地的remFifoTail游标每次接收时游标后移一位接收端会将idx设置为一个自增的索引同时将上层的DMA地址通过ncclIbSendFifo携带给发送端发送端维护本地的fifoHead游标每次发送后游标后移一位发送端检查fifo中元素的idx值是否为预期索引来判断该fifo是否已经被接收端设置过即接收端的DMA地址已经可以写入 struct ncclIbSendFifo { uint64_t addr; int size; uint32_t rkey; uint32_t nreqs; uint32_t tag; uint64_t idx; }; // 发送端 ncclIbIsend uint64_t idx comm-fifoHead1; if (slots[0].idx ! idx) { *request NULL; return ncclSuccess; } comm-fifoHead; //接收端 ncclIbIrecv - ncclIbPostFifo : localElem[i].idx comm-remFifo.fifoTail1; comm-remFifo.fifoTail;
4.4 Libvma及SMC-R方式
除了上述修改业务源码的方案业内也有“零入侵”业务程序的方案比如libvma及smc-r方式。
SMC-R
smc-rSMC over RDMA是IBM在2017提交至linux kernel的一种兼容socket层使用共享内存技术、基于RDMA技术实现的高性能内核网络协议栈。smc-r的主要实现是在内核态实现了一个新的af_smc协议族基于RDMA verbs接口实现内核proto_ops中的各方法。 smc-r支持fallback回退机制在通信双方最开始建立连接时是使用tcp握手特定的tcp选项进行协商是否双方均支持SMC-R能力当协商不成功时fallback为原始的tcp通信。完成协议协商并建立连接后协议栈为SMC-R socket分配一块用于缓存待发送数据的环形缓冲区sndbuf和一块用于缓存待接收数据的环形缓冲区RMBRemote Memory Buffer。
发送端应用程序通过socket接口将待发送数据拷贝到本侧sndbuf中由SMC-R协议栈通过RDMA WRITE操作直接高效地写入对侧节点的RMB中。同时伴随着使用RDMA SEND/RECV操作交互连接数据管理消息用于更新、同步环形缓冲区中的数据游标。接收端SMC-R协议栈感知到RMB中填入新数据后通过epoll等方式告知接收端应用程序将RMB中的数据拷贝到用户态完成数据传输。所以在SMC-R中RMB充当传输过程中的共享内存。 下面是一个基于smc-r通信的实际测试场景的协商交互抓包 Libvma
Libvma是Mellanox公司开源的一款高性能的用户态网络协议栈它将socket的相关接口全部在用户态空间实现实现对内核的旁路使用RDMA verbs接口直接调用网卡驱动从而节省了大量的上下文数据拷贝节省了 CPU 的资源降低了时延业务在使用libvma时只需要使用LD_PRELOAD libvma.so替换原有的系统调用即可完成传输协议的替换。
Libvma内部在tcp协议栈的实现上使用了lwip方案重写了epoll使用了hugepage内部使用单独的线程去轮询RDMA CQ事件等方案相较于内核协议栈的实现在主机侧的处理延迟有200%至500%的降低。
此外在实际测试过程中发现libvma虽然使用的是RDMA verbs接口但实际针对Mellanox mlx5系列驱动的网卡是直接用户态驱动网卡发送的仍然是原始基于tcp的以太报文并不是rocev2的报文具体讨论可以见github上的issue参考[15]。
下面是基于libvma测试redis的场景由于libvma bypass协议栈并且重写了epoll等其它特性性能提升大概3倍 总结
相较于业务使用raw verbs进行源码修改libvma及smc-r方式可以提供“零入侵、零修改”源码的优势但由于应用程序在将数据提供给socket接口时仍然存在一次拷贝所以性能上对比verbs方案来说有一定的损耗对于想快速验证RDMA能力的业务是一个不错的POC验证方式。
目前阿里云的Alibaba Cloud Linux3默认支持smc-r能力结合阿里云的eRDMA能力网卡可以使业务进行透明无损的RDMA传输替换减少cpu的使用率降低一定的通信延时。但目前该能力在阿里云上属于公测能力生产稳定性待验证参考[14]。
libvma方式没有linux社区的支持并且更多的是针对Mellanox系列网卡的支持在工业界使用的场景也不太多目前在金融的高频交易领域有一些使用尝试。 5.总结与展望
前面主要分析和调研了一些开源应用在进行业务适配RDMA传输的方案整体来看RDMA改造的方案是分为两部分分别为通信接口的改造以及RDMA内存管理设计。
通信接口改造主要指将tcp socket的传输接口修改为ib verbs或者cm接口这部分同时涉及到适配现有业务网络事件的处理模型。
由于RDMA传输数据时需要预先将内存注册到HCA卡上所以RDMA内存管理会比较复杂同时也是性能高低与否的关键。
1数据传输时申请内存并进行内存注册再进行RDMA操作。显然这种模式在代码实现上最为简单但是性能及效率最低现有方案中很少有在fast path中使用这种内存管理方案。
2提前注册好一大块内存在上层业务需要发送数据时将数据拷贝至RDMA注册好的内存。这种模式性能相较第一种有提升但存在一定的内存拷贝。
3使用内存池业务及RDMA的内存使用同一块。性能明显是最优的但是实现逻辑较复杂需要管理好内存的申请及释放、某些实现中通信双方也需要做内存使用量的协商。
结合前面应用的RDMA方案汇总如下表 应用名称 网络处理模型 内存方案 其它特性 Redis pr stage 1.适配原有的单线程reactor非阻塞模式 2.rdma无pollout时间在业务逻辑中额外处理 3.网络支持插件式不同的传输模式实现相同的网络方法 1.预注册内存,RDMA Write模式 2.DMA地址通过控制消息交互 3.应用与RDMA之间存在拷贝 1.有控制面交互如xferbuffer 2.控制面信息复用RDMA通道 Tensorflow 异步发送、阻塞接收 1.RDMA Write模式 2.应用及RDMA共享内存池 3.通信双方通过消息交互DMA地址 1.使用基于TCP的GRPC通道进行RDMA链接的协商 2.有控制面消息交互如metadata更新 3.控制面信息复用RDMA通道 BRPC reactor模式 1.内存池模式 2.使用RDMA Send模式 1.额外的流控机制 2.事件聚合 NCCL 1.reactor模式 2.网络支持插件式不同的传输模式实现相同的网络方法 1.RDMA Write模式 2.通信双方通过一个共享fifo来交互具体的DMA地址 3.DMA地址是预先注册的内存 1.RDMA建立阶段使用TCP链接进行协商
随着AI的火热国产DPU、GPU的高速发展数据中心内在高性能计算、机器学习、分布式存储等场景下的业务也需要随着硬件能力的提升去适配使用这些能力RDMA因其诸多优点目前已经广泛被应用。调研学习现有的方案是为了更好地适配及修改自研的业务相信随着越来越多业务场景下RDMA的使用其相关生态及应用方案也会越来越成熟。 内容基于网上资料及源码分析整理欢迎讨论及批评指正。 参考
[1]orpc 基于RDMA的云服务能力实践与探索
[2]redis网络连接层 Redis网络连接层的过去、现状和展望-腾讯云开发者社区-腾讯云
[3]openssl pendingssl的消息读写以及和tcp语义的异同_weixin_33816300的博客-CSDN博客
[4]redis over rdma : GitHub - pizhenwei/redis at feature-rdma
[5]redis over rdma protocol https://github.com/pizhenwei/redis/blob/feature-rdma/RDMA.md
[6]redis over rdma test: forsakening/rdma-redis-test · GitHub
[7]tensorflow over rdma https://github.com/tensorflow/networking/blob/master/tensorflow_networking/verbs/README.md
[8]tensorflow rdma源码剖析 https://github.com/chenpai/TensorFlow-RDMA/blob/master/TensorFlow%20RDMA%20%E6%BA%90%E7%A0%81%E5%89%96%E6%9E%90.md
[9]brpc的rdma特性 https://github.com/apache/brpc/blob/master/docs/cn/rdma.md
[10]brpc的rdma实现 brpc源码学习十- RDMA通信_brpc rdma_KIDGINBROOK的博客-CSDN博客
[11]nccl多机通信流程 NVIDIA NCCL 源码学习十- 多机间ncclSend和ncclRecv的过程_KIDGINBROOK的博客-CSDN博客
[12]nccl net plugin https://github.com/NVIDIA/nccl/blob/master/ext-net/README.md
[13]libvma GitHub - Mellanox/libvma: Linux user space library for network socket acceleration based on RDMA compatible network adaptors
[14]阿里云smc-r SMC-R是什么,使用方法有哪些_云服务器 ECS-阿里云帮助中心
[15]libvma packet type issue NOT see any rocev2 packet · Issue #1036 · Mellanox/libvma · GitHub
[16]RDMA CM交互流程 IBM Documentation
