RDMA 背景知识

A. RDMA verbs

verbs决定了通信操作的类型。RDMA的verbs可以分成两类，双边two-sided(SEND, RECV)的和单边的one-sided(READ, WRITE)。two的涉及到两个通信端点，这种情况下，远程主机需要提前发布（pre-post）RECV,本地主机需要发布SEND。one-part仅仅涉及一个通信端点（源）。使用WRITE可以直接在远程主机写入数据，使用READ直接从远程主机内存直接读取数据，并且不需要通知远程主机。

RDMA的动词遵循异步I/O模型。数据传输是非阻塞的，因此允许程序在发布的请求完成之前继续执行。通过向完成队列发送CQE信号，告知完成；应用程序轮询队列接收CQE确定完成。

B. RDMA transport

RDMA提供了不可靠（UD）和可靠（RC）传输类型。 UD传输不保证请求的交付。此外，UD仅提供双面动词。对于RC传输，RNIC使用确认（ACK）来保证请求的传递。此外，RC传输支持单侧和双侧动词。

C. RDMA execution path

根据动词和传输类型的选择，RDMA事务遵循通信主机之间特定的交互序列。不论什么事务，每次事务开始时，host通过PCIe的MMIO事务向本地RNIC发送请求，RNIC根据请求中的动词类型，决定处理请求的办法：
如下图：

RDMA operations execution sequence：

image-20201026101151798

  • READ： 本地RNIC通过网络结构发送请求。远程RNIC通过从主机的内存层次结构读取的DMA服务请求，并将数据发送回本地RNIC。接收到数据后，本地RNIC发出DMA写操作以将数据存储在本地内存中。之后，本地RNIC执行另一次DMA写操作以发出CQE。
  • WRITE：首先，本地RNIC通过DMA读取获取有效负载。接下来，通过网络结构发送请求。远程RNIC 执行一个DMA写的操作将数据存储在主机的内存中，然后发送一个ACK.

image-20201026102358284

  • SEND：首先，本地RNIC通过DMA读取获取有效负载。然后，该请求通过网络结构发送。远程RNIC收到请求后，会发回ACK（如果使用RC传输），并通过DMA写入将有效负载写入其主机的内存中。根据SEND请求使用的RDMA传输方式的不同，本地RNIC会在网络（fabric）发送请求后立即发出CQE（UD，图c），或者一旦从远程RNIC接收到ACK（RC，图d），则发出 。

IB

I. InfiniBand QoS support

为了提供按流的性能差异，IB提供了一组优先级，称为服务级（SL），可以将其分配给流。IB使用SL的抽象来隐藏其两个有助于实现QoS的体系结构组件:

  1. Virtual Lane (VL):
  2. Virtual Lane Arbitration (VLArb):

II. IB SWITCH LATENCY MEASUREMENT

IB网络可以达到10微秒内的延迟，导致测量需要很准确，但是如此低的延迟为准确的NIC至NIC延迟测量提出了一些挑战。主要挑战是将交换机的延迟与其他组件（尤其是软件和PCIe）隔离开。

解决办法：

  1. 理想的：直接通过交换机测量单向端口到端口的延迟。

    代价：需要使用昂贵的数据采集设备

  2. 另一种：端点上使用精确的亚微秒时钟同步。

    **不足和假设：**基于两个方向上的单向等待时间相同的假设，在拥塞情况下，尤其是在聚合交通模式下，情况并非如此。

  3. ping-pong style test: 获得软件中的往返时间（round-trip time:RTT）

    image-20201026195810000

    问题：

    1. 远程：远程端处理的偏差，而且是生成和传输ack所必须的，远程侧处理包括用于生成响应的软件开销以及用于向RNIC传输数据或从RNIC传输数据所需的PCIe事务。但是不会影响真正的网络延迟，所以需要排除在测量中。
    2. 本地：本地处理延迟，软件捕获到的是请求的发送时间而不是传输时间（transmiting time）。所以会造成测量偏差。

    相关工作：

    1. RDMA Bench
    2. Perftest
    3. QPerf

RPERF

​ 细节：RPerf测量本地主机和远程主机之间的RTT，并利用RDMA谓词来准确地测量延迟，而不包括端点延迟。接下来，我们描述RPerf设计的关键方面。

  1. Excluding remote-side processing：post-poll方法

    • 利用RC传输，远程RNIC在其中生成响应而不涉及目标主机，RPerf避免了远程端的软件处理开销。
    • 使用SEND verb ，排除远端PCIe的延迟，SEND使远程RNIC在收到请求后立即生成对源RNIC的响应，而无需等待PCIe事务在远程端完成。

  2. Excluding local-side processing：

    • local-side processing overhead：actions at the local host and the RNIC
    • 解决：发送lookback message，通过本地RNIC从主机发送到自身的消息（over-
      the-wire SEND）

  3. RTT calculation:同时发送两个消息，一个是over-the-write，一个是lookback message。

image-20200829090835329

$$
RTT = (T_W-T_P)-(T_L-T_P)=T_w-T_L
$$

额外的技巧：为了最小化由软件引起的性能差异，每个RPerf线程都固定到CPU内核，并且为所有必需的缓冲区分配了巨大的页面。为了准确捕获事件的时间戳，RPerf通过rdtsc x86汇编指令使用时间戳计数器，该指令在用户空间内提供高精度的时间戳测量。 RPerf遵循英特尔关于TSC校准和访问的建议。 RPerf的多个实例可以在不同的服务器上运行，并且用户可以指定流量模式（例如，一对一或多对一）来测量系统的特定方面，例如零负载延迟，峰值带宽或负载延迟。

实验

实验设置

  1. Hardware testbed
  2. Simulator
  3. Traffic pattern
  4. Metrics

性能表现

ONE-TO-ONE TRAFFIC

对照组：有无switch， Perftest and Qperf.

A. Latency and bandwidth without the switch AND B. Latency and bandwidth with the switch
  1. RTT

image-20201028203924233

  1. Bandwith

image-20201028204009514

C. Latency calculation by existing tools

image-20201028204412779

融合流量下的表现

在这种设置中，数量众多的BSG（从1到5）将带宽密集的流以4096B有效负载的大小发送到一台目标服务器，从而形成一种融合的流量模式。同时，LSG将对延迟敏感的流发送到同一目标服务器。

Latency of LSG:

image-20201028204658627

Bandwidth of BSGs:

image-20201028204706756

尝试保护延迟敏感的流程

A. BSGs with different message sizes

image-20201028205112105

image-20201028205133251

B. Packet scheduling policy at the switch

  1. FCFS policy:

  2. Round-Robin policy:使用RR策略，仲裁器可以在每个回合中选择一个端口，并在该端口的开头选择数据包。在这种情况下，每当LSG数据包到达时，它最多等待活动端口的数量。

image-20201028205219090

  1. Packet scheduling policies in a multi-hop topology

    我们将模拟设置扩展到两跳拓扑，其中一对交换机连接在一起。两个BSG和一个LSG连接到上游交换机，三个BSG连接到下游交换机。目标服务器也连接到下游交换机。所有BSG都将4096B消息发送到目标服务器。

image-20201028205655531

C. InfiniBand QoS

使用专有的SL

image-20201028210109093

区分流类型并为每种流类型分配优先级可以有效地保护对延迟敏感的流。

Gaming the dedicated SL/VL setup:

带宽密集的流假装成短消息