做网站界面,重庆专业微信网站制作,一台vps主机可以建设多少个网站,低代码平台 开源文章目录 基础信息建链 3次握手断链4次挥手建联状态active端passive端 报文结构函数关系其他后记 基础信息 CM: Communication Management 通信管理 连接管理SIDR: Service ID Resolution Protocol. 作用#xff1a; enables users of Unreliable Datagram service to locate … 文章目录 基础信息建链 3次握手断链4次挥手建联状态active端passive端 报文结构函数关系其他后记 基础信息 CM: Communication Management 通信管理 连接管理SIDR: Service ID Resolution Protocol. 作用 enables users of Unreliable Datagram service to locate Queue Pairs supporting their desired service.MAD Management Datagrams 管理报文GSIGeneral Services Interface 通用服务接口QP1专用与rdma cm建链分为server端和client端在RDMA中server端叫passive端被动、client端叫active端主动
建链 3次握手 req包、rep包、RTU包rdma中叫做msgRequest (REQ) messageResponse (REP) messageRTUReady To Use。 在内核消息处理中收到该msg之后会将qp attribute设置RTS和RTR。 read to send read to receiveQueue Pair Number (QPN) QP数字EEC End to End Context 端到端上下文req中告诉对端cid、qkey、qpn、guid以及udp的sportrep中同样告诉对端cidcommunication id 通信id相当于session回话的id每次建联有一个id、qkey、qpn。相当于也是对req的一个ack同时携带自己的信息rtu包含了lcid和rcid表示本地和远端的cid算是以此确认。同样的后面讲的dreq中也会携带lcid和rcid
断链4次挥手
双端都需要发送所以累计四次
建联状态
active端 passive端 报文结构
报文结构BTH | DETH | MAD header| MAD payload | CRC其中MAD payload根据消息不同是不同的消息内容req、rep、mra、rtu等BTHBase Transport Header基础传输头主要是opcode比如write 0x10、send 0x4、ack 0x17、Partition key和目标QPcm的目标QP都是1以及报序号DETHDatagram Extended Transport Header数据报文扩展传输头。主要是query key和source QP。BTH中是dst qpdeth中是src qp有点类似以太的smac和dmac。MADManagement Datagrams 管理报文。主要包含Method是send recv等、Attribute ID属性ID比如req 0x10、rep 0x13、mra 0x11、rtu 0x14、dreq 0x15、drep 0x16管理路线BEM结构 E表示extendE可以是DETH(数据)、AETHack、RETH(rdma)数据路线BD结构BTH头部和Data的数据比如rdma send数据BTH找QP与optype、DETH找sq和key、MAD找attid比如cm req、MAD payload找具体的cm msg信息比如cmd id 等
函数关系
内核中处理msg的发包函数都是ib_send_cm_xxx开头比如ib_send_cm_req、ib_send_cm_rep、ib_send_cm_mra、ib_send_cm_rtu…收包函数都是cm_xxx_handler比如cm_req_handler、cm_rep_handler、cm_rtu_handler、cm_mar_handler、cm_dreq_handler…内核收包处理流程是ib_cm.ko中调用ib_register_mad_agent注册cm_recv_handler到mad层进行收包cm_recv_handler中收到后会启动一个work然后通过work event发给内核work上下文进行处理也就是cm_req_xxx这些函数会在work上下文处理work的入口函数是cm_work_handler。然后cm_work_handler根据event是req、rep等调用到对应的cm_xxx_handler.rdma对应的API调用底层关系是 rdma api - rdma cm文件infiniband/rdma_cm - 发送write dev函数 - 内核态ucma处理 - 内核态rdma接口处理 - 内核态cma代理处理 - 内核态cm处理 - 内核态mlnx处理 - 网卡硬件处理比如rdma_acccpt接口实现就是 打开infiniband/rdma_cm文件封装wirte数据命令 CM_CMD_ACCEPT通过write发送给内核内核根据cmd的值在ucma_cmd_table中进行match匹配后调用对应函数ucma_accept函数然后调用[k] rdma层的rdma_accept、然后调用cm代理cma层的cma_accept然后继续往后调用rdma_connect会发送req 报文rdma_listen会监听进入rdma_accept后会发送rep报文或者mra其他报文类似ib_send_cm_xxx最后都会调用ib_post_send_mad发送给mad层然后mad层调用ib_send_mad调用ib_post_send然后调用到mlx5_ib_post_send异步发送
其他
所有的RoCE v2的报文都会经过UDP可以通过tcp抓包但是tcp抓包需要指定端口是mlx5的端口而不是eth口。
后记
更多细节以后逐渐补充。
