本文将介绍如何确定目标场景是否适合使用SMC加速，是否具备使用SMC加速的条件。
原理概述
随着传统数据中心应用大规模上云，云上网络的时延和吞吐面临新的挑战。传统虚拟网卡和TCP协议栈逐渐无法满足数据中心对网络高吞吐、低时延的诉求。同时，随着云计算场景DPU能力的进一步增强，云上开始提供RDMA网络，以充分利用硬件能力提升网络性能。在这样的趋势下，一种能充分发挥下层DPU硬件性能，同时支撑上层大规模云上应用，开发部署和运维友好的软硬件协同协议栈成为云上数据中心网络的重要选择。
共享内存通信SMC（Shared Memory Communication）在很大程度上满足了上述需求。SMC由IBM开源至Linux社区，并经Alibaba Cloud Linux 3增强和维护。SMC作为内核网络协议栈与TCP/IP协议栈平行，不同的是它更加轻量。SMC将网络协议的处理（如数据包的封装和解析）卸载到底层硬件设备，有效降低了时延和CPU开销。同时SMC通过直接对远程共享内存读写来完成数据传输，有效提高了网络吞吐。
根据所用的底层内存访问技术区分，SMC分为基于RDMA技术的SMC-R（SMC over RDMA）和基于ISM技术的SMC-D（SMC over DMA）。目前Alibaba Cloud Linux 3基于弹性RDMA（eRDMA）提供SMC-R加速能力，接下来的说明均针对SMC-R。
总体设计上，SMC协议栈兼容传统的网络socket接口，开发与使用方式和传统TCP应用无异。更进一步地，通过挟持socket()系统调用替换socket family和protocol参数，可以实现将已有TCP应用无感切换到SMC协议栈，无需修改或重新编译已有的应用程序。具体操作，请参见共享内存通信（SMC）使用说明。
建立通信连接时，SMC协议栈会首先和对端建立TCP连接，在TCP三次握手的SYN包中携带特殊的TCP选项（类型254，内容0xE2D4C3D9），用以表明将使用SMC协议通信，并同样以此判断对端是否支持SMC协议。若握手成功，两端将创建对应的RDMA资源并进一步握手，后续的数据流量将通过RDMA网络传输；若握手失败，两侧将安全回到已建立的TCP连接，后续的数据流量将通过TCP网络传输，确保网络不会因对端不支持SMC而无法通信。
连接建立后，SMC协议栈为首个SMC连接创建RDMA RC连接（SMC Link），流量通过SMC Link由RDMA网络传输。为尽可能高效利用RDMA链路并降低RDMA资源开销，后续建立的其他SMC连接将尝试复用此SMC Link，直到复用连接数量达到上限再创建新的SMC Link。同时为了容灾，SMC允许多个SMC Link组成SMC Link Group（LGR）提供RDMA传输能力。
使用依赖
弹性RDMA能力
在阿里云ECS上使用SMC-R需要配置弹性RDMA网卡（eRDMA）。目前支持eRDMA的机型以及配置eRDMA步骤请参见在企业级实例上使用eRDMA。
操作系统
阿里云Alibaba Cloud Linux 3操作系统自内核
5.10.134-16起支持SMC-R能力。关于内核查看、修改方式，请参见更换内核版本。
适用场景
SMC因其设计特点，适合在如下场景中发挥优势：
期望不修改用户态程序
SMC核心优势之一是不需要TCP应用程序修改即可使用RDMA技术，进而通过共享内存通信加速网络性能。但相对于通过IB verbs接口改造应用程序直接使用RDMA来说，SMC作为内核协议栈会多出系统调用和内核/用户态数据拷贝开销，性能不及原生RDMA应用。因此适用于期望对现有应用无侵入的场景。
追求时延或吞吐指标
SMC将网络协议的处理（如数据包的封装和解析）卸载到底层硬件设备，有效降低了时延和CPU开销。同时通过直接对远程共享内存读写来完成数据传输，有效提高了网络吞吐。因此适用于追求时延、吞吐指标的场景。
内部网络场景
SMC协商成功并使用共享内存通信需两侧均支持SMC协议，因此内部网络场景下更易满足服务侧、客户侧均开启SMC的条件。另一方面，内部网络场景网络链路短，使用SMC带来的网络优势更易凸显。
网络占比高
SMC带来的网络时延和吞吐优势在网络占比高的服务中更能凸显。
避免劣势场景
SMC因其设计特点，在下述情况下表现会劣于TCP或是无法达到预期效果，实际使用中需要避免这些场景。
场景 | 说明 | 解决方案 |
场景 | 说明 | 解决方案 |
短生命周期通信 | SMC连接的建立涉及TCP握手、SMC握手及RDMA资源创建（使用SMC-R时）等多个流程，故其建连性能较弱，在短生命周期通信中性能劣于TCP。 | 使用 |
大量突发连接 | 与短生命周期通信场景类似，由于SMC的建连性能较弱，大量突发连接将导致连接建立流程的排队等待，造成建连超时。 | |
跨网元通信 | SMC建连首先会和通信对端建立TCP连接。在TCP三次握手SYN/SYN-ACK包中通过特殊的TCP Experimental Option来表示支持SMC协议。
然而，某些网元在处理TCP Option时会错误地将含无法识别Option的SYN包丢弃，或在返回的SYN-ACK包中无条件重放此Option，这可能导致握手超时或错误判断对端支持SMC，从而引发连接建立超时或阻塞的情况，偶见于访问公网服务时。可通过自动化检查工具检查服务链路是否经过异常网元。具体操作，请参见自动化检查工具。 | |
公网通信 | 与跨网元通信场景类似，公网通信常常跨网元访问，易出现连接建立超时或是阻塞的情况。 此外，公网通信中一般较难达到通信两侧均使用SMC的条件，将会回退到使用TCP通信。 最后，SMC的设计初衷是为数据中心内部网络加速，未对网络安全做严格加固，不适用于非可信环境。 | |
内存资源紧张 | SMC基于共享内存通信，使用预申请的缓冲区作为共享内存，因此会产生一定的内存开销。 一条SMC连接在通信单侧占用缓冲区大小默认为 |
|
跨可用区通信 | 跨可用区场景下，网络的传输时延在百微秒到毫秒级，SMC带来的时延优势被稀释，无明显收益。另一方面，网络的带宽时延积增大，导致需要增大收发缓冲区才能跑满带宽，增加内存资源压力。 | 通过UEID避免跨可用区使用SMC通信，具体操作，请参见共享内存通信（SMC）使用说明。 |
自动化检查工具
Alibaba Cloud Linux 3提供aliyunsmc-check工具，用于自动化检查SMC相关基础环境配置、通信链路以及正常通信能力等。该aliyunsmc-check工具包含在aliyun-smc-extensions工具包中。
安装工具包
执行以下命令，安装
aliyun-smc-extensions工具包。sudo yum install -y aliyun-smc-extensions基础环境配置检查
基础环境配置检查用于检查环境基础配置是否正确，如操作系统内核版本，eRDMA设备的存在情况等。执行以下命令，检查基础环境配置。
aliyunsmc-check basic_check输出结果示例：
通信链路检查
通信链路检查用于检查链路上是否存在影响SMC通信的网元，以便提前预判链路是否适用SMC通信。执行以下命令，检查通信链路。其中，
<url>需替换为对应目标URL。aliyunsmc-check syn_check --url <url>输出结果示例：
在URL输入无误的前提下，任何一项失败都表示此链路不适用SMC通信，需要使用
smc-ebpf工具避免此链路访问使用SMC通信，具体操作，请参见共享内存通信（SMC）使用说明。SMC通信检查
通信检查用于检查当前机器与指定机器
hosts之间能否使用SMC正常通信。检查时会通过ssh登录到指定的hosts，因此需要在命令参数中指定ssh鉴权信息。通信检查允许如下
ssh鉴权方式：使用
keyfile进行SSH登录。<peer ip>需替换为远程主机的IP地址。<usr>需替换为远程主机的用户名。<keyfile>需替换为SSH私钥的文件路径。
aliyunsmc-check connect_check --hosts <peer ip> --user <usr> --key <keyfile>使用密码进行SSH登录。
<peer ip>需替换为远程主机的IP地址。<usr>需替换为远程主机的用户名。<passwd>需替换为远程主机的密码。
aliyunsmc-check connect_check --hosts <peer ip> --user <usr> --pwd <passwd>已配置SSH免密登录。
<peer ip>需替换为远程主机的IP地址。<usr>需替换为远程主机的用户名。
aliyunsmc-check connect_check --hosts <peer ip> --user <usr>
输出结果示例：
