Benefits, architecture, use scenarios, and instructions of SMC - Elastic Compute Service

This topic describes how to enable Shared Memory Communication (SMC), configure the SMC acceleration scope, and configure interfaces exposed by SMC to achieve the best acceleration effects.

Use SMC in Alibaba Cloud ECS

Alibaba Cloud Linux 3 provides and optimizes the SMC over RDMA (SMC-R) kernel protocol stack. You can use SMC-R by performing the following steps.

Preparations

Create an Elastic Compute Service (ECS) instance that supports the eRDMA Network Interface (ERI).
SMC-R relies on Remote Direct Memory Access (RDMA). To use SMC-R on Alibaba Cloud, you must create an ECS instance that supports the ERI feature to obtain the elastic RDMA (eRDMA) capability in the cloud. For more information, see Enable eRDMA on an enterprise-level instance.
Important
- Alibaba Cloud eRDMA devices and SMC do not support IPv6 addresses. If applications use IPv6, SMC falls back to TCP. For more information, see SMC falls back to TCP when IPv6 addresses are used.
- Starting from kernel version ANCK 5.10.134-17.3, SMC supports IPv4-mapped IPv6 addresses.

Run the following commands to load the smc and smc_diag kernel modules:

sudo modprobe smc
sudo modprobe smc_diag

Run the dmesg command to view kernel-related messages. If the kernel modules are loaded, the following information is displayed:

smc: smc: load SMC module with reserve_mode
NET: Registered protocol family 43
smc: netns <netns ID> reserved ports [65500 ~ 65515] for eRDMA OOB
smc: adding ib device erdma_0 with port count 1
smc:    ib device erdma_0 port 1 has pnetid

(Optional) If you no longer use SMC, run the following commands to uninstall the SMC modules:

sudo rmmod smc_diag
sudo rmmod smc

Run the following commands to install the smc-tools and aliyun-smc-extensions O&M toolsets:
```
sudo yum install -y smc-tools
sudo yum install -y aliyun-smc-extensions
```

Run TCP socket applications on the SMC stack

Alibaba Cloud Linux 3 SMC-R allows you to convert applications from TCP sockets to SMC sockets at the net namespace level and process level.

Net namespace-level socket conversion

Alibaba Cloud Linux 3 provides the net namespace-level transparent socket conversion feature that allows you to convert all TCP sockets that meet the following conditions in the net namespace to SMC sockets by running the sysctl net.smc.tcp2smc command.

The value of family is AF_INET.
The value of type is SOCK_STREAM.
The value of protocol is IPPROTO_IP(0) or IPPROTO_TCP(6).

The following figure shows the conversion process.

To perform net namespace-level transparent socket conversion, perform the following steps:

Run the following command to set net.smc.tcp2smc to 1 to enable transparent socket conversion for the current net namespace.
After transparent socket conversion is enabled for the net namespace, subsequent new TCP sockets in the net namespace are converted to SMC sockets and existing TCP sockets are not affected.
```
sudo sysctl net.smc.tcp2smc=1
```
By default, sysctl net.smc.tcp2smc is set to 0, which indicates that transparent socket conversion is disabled.
Run the following command to run TCP socket applications in the current net namespace.
In the following command, replace foo with an actual application name:
```
./<foo>
```
The TCP sockets created by the foo application are transparently replaced with SMC sockets, and the network behaviors of the application are handled by the SMC-R stack. As described in Overview, if the peer also supports SMC-R and the negotiation is successful, data is transmitted between the local and peer nodes over the RDMA network. Otherwise, the nodes securely fall back to TCP for data transmission.
(Optional) Run the following command to disable transparent socket conversion the current net namespace. After transparent socket conversion is disabled for the net namespace, subsequent new TCP sockets in the net namespace are no longer converted to SMC sockets, but existing converted SMC sockets are affected.
```
sudo sysctl net.smc.tcp2smc=0
```

Process-level socket conversion

Alibaba Cloud Linux 3 also provides the process-level transparent socket conversion feature based on the smc-tools toolset.

You can use the smc_run script in the smc-tools toolset to run applications. smc_run uses the LD_PRELOAD environment variable to define libsmc-preload.so in the smc-tools toolset as the dynamic library to be loaded first. libsmc-preload.so converts TCP sockets that meet the following conditions in applications and their child processes to SMC sockets.

The value of family is AF_INET.
The value of type is SOCK_STREAM.
The value of protocol is IPPROTO_IP(0) or IPPROTO_TCP(6).

Note

smc_run uses LD_PRELOAD to intercept the socket() system call in glibc, and cannot be used for applications that do not use glibc or are statically linked.

The following figure shows the conversion process.

To perform process-level transparent socket conversion, perform the following operations:

Run the following command to add the smc_run prefix before the executable of the foo application.

In the following command, replace foo with an actual process name:

smc_run ./<foo>

The TCP sockets created by the foo application are transparently replaced with SMC sockets, and the network behaviors of the application are handled by the SMC-R stack. As described in Overview, if the peer also supports SMC-R and the negotiation is successful, data is transmitted between the local and peer nodes over the RDMA network. Otherwise, the nodes securely fall back to TCP for data transmission.

SMC negotiation control based on BPF policies

In actual use, enabling SMC at the net namespace or process level sometimes remains too coarse-grained. For example, if a server has multiple network listening ports in a net namespace, you may want to use SMC only for connections on ports that require performance acceleration and safely fall back to TCP for connections on other ports, such as management ports.

For this purpose, Alibaba Cloud Linux 3 supports using Berkeley Packet Filter (BPF) technology to further control whether to use SMC negotiation for connections based on net namespace-level or process-level transparent socket conversion. The typical process is as follows:

Configure and enable BPF policies to set up fine-grained SMC negotiation control.
Enable SMC at the net namespace or process level. For more information, see Run TCP socket applications on the SMC stack.

As described in Overview, during the TCP connection handshake process, both communication parties use a special TCP option to indicate their support for SMC-R and check whether the peer also supports SMC-R. Once the negotiation is successful, subsequent network transmission between the two parties is completed over RDMA. Otherwise, the system safely falls back to TCP.

By default, SMC sockets always initiate and respond to the special TCP option. However, you can use BPF technology to further control whether to initiate or respond to the special TCP option based on port or IPv4 address policies, thereby achieving more fine-grained SMC enablement control.

For this purpose, Alibaba Cloud Linux 3 provides the smc-ebpf tool in smc-tools to configure and enable BPF policies.

Run the following command to check whether the smc-ebpf tool is installed:

smc-ebpf policy help

The following command output indicates that the smc-ebpf tool is installed:

smc-ebpf policy help
 Usage: smc-ebpf policy COMMAND [OPTIONS]
        smc-ebpf policy load [OPTIONS]    load policy
    --init                                load policy with pre-defination config
        smc-ebpf policy stop              stop policy
        smc-ebpf policy unload            unload policy
        smc-ebpf policy init              init policy with default config
        smc-ebpf policy clear             clear all policy config
        smc-ebpf policy dump              display all policy config
        smc-ebpf policy config [OPTIONS]  config policy
        smc-ebpf policy delete [OPTIONS]  delete policy
    --ip [IPv4]                           target IPv4 address
    --port                                target port
    --mode [auto|disable|enable]          target mode
 Examples:
    smc-ebpf policy load
    #disable port 80 to use smc
    smc-ebpf policy config --port 80 --mode disable
    #delete ip xxx.xxx.x.x/24 policy
    smc-ebpf policy delete --ip xxx.xxx.x.x --mask 24

Load the smc-ebpf tool

Run the following command to load the smc-ebpf tool:

sudo smc-ebpf policy load

Warning

The smc-ebpf tool must be loaded before the connection to be configured is created. The smc-ebpf tool does not take effect for connections created before it is loaded.
The policies configured by the smc-ebpf tool are global policies and cannot be configured independently for specific net namespaces (containers).
The smc-ebpf tool-related features are still being continuously standardized in the upstream community and may be subject to interface changes in the future. Currently, the features are only provided as experimental features.

The following command output indicates that the smc-ebpf tool is loaded:

# sudo smc-ebpf policy load
Registered smc_sock_negotiator_ops anolis_smc id xxx

A different command output indicates that the tool cannot be used in the current environment. Perform the following operations to troubleshoot the issue:
- Confirm that the operating system kernel version is ANCK 5.10.134-016 or later. You can view the kernel version by using the uname -r command.
- Confirm that you have permissions to load BPF programs. A common reason may be that the pod container you are use does not have the capability to load BPF programs, or your privilege level is insufficient. You can consult your environment provider for more information.

Default behaviors of port policies

After the smc-ebpf tool is loaded, if no port policy matches the target port, the target port is prohibited from using SMC negotiation.

Examples:

If the smc-ebpf tool is loaded without any port policy configured, all ports are prohibited from using SMC negotiation.
If the smc-ebpf tool is loaded with only one policy that allows port 80 to use SMC negotiation, any other port in use, such as port 8080, is prohibited from using SMC negotiation because no policy matches port 8080.

Specifically, you can run the following command to set --mode to enable for port 0 to change the default behavior to allowing the use of SMC negotiation when no port policy matches the port:

sudo smc-ebpf policy config --port 0 --mode enable

Similarly, you can run the following command to set --mode to disable for port 0 to change the default behavior back to prohibiting the use of SMC negotiation when no port policy matches the port:

sudo smc-ebpf policy config --port 0 --mode disable

Configure port policies

You can add policies for specific ports based on the default behavior.

Examples:

Example 1: Allow only port 80 to use SMC negotiation, and prohibit all other ports from using SMC negotiation.
Run the following command to add a policy that allows port 80 to use SMC negotiation:
```
sudo smc-ebpf policy config --port 80 --mode enable
```
Run the following command to check whether the port policy is added:
```
sudo smc-ebpf policy dump
```
Sample command output:
- "key": 80 indicates that the policy targets port 80.
- "mode": indicates whether the use of SMC negotiation is allowed. A value of 2 indicates that the use of SMC negotiation is allowed, and a value of 0 indicates that the use of SMC negotiation is prohibited.
```
# sudo smc-ebpf policy dump
[{
        "key": 80,
        "value": {
            "mode": 2,
            [Other fields that ordinary users do not need to pay attention to]
        }
    }
]
```
If you no longer require the policy, run the following command to delete the policy for port 80:
```
sudo smc-ebpf policy delete --port 80
```
Run the dump command again. The following command output indicates that the policy deleted:
```
# sudo smc-ebpf policy dump
[]
```
Example 2: Prohibit port 80 from using SMC negotiation, and allow all other ports to use SMC negotiation.
Run the following commands to change the default behavior to allowing the use of SMC negotiation when no port policy matches the target port and to add a policy that prohibits port 80 from using SMC negotiation:
```
sudo smc-ebpf policy config --port 0 --mode enable
sudo smc-ebpf policy config --port 80 --mode disable
```
After the preceding commands are run, only port 80 is prohibited from using SMC negotiation, and all other ports are allowed to use SMC negotiation when no port policies match the ports.

Default behavior of IPv4 address policies

Unlike port policies, IPv4 address policies take effect only for client sockets and are used to control whether the client uses SMC negotiation when connecting to the server based on the IPv4 address of the server.

Note

All configured port policies and IPv4 address policies are evaluated by using a logical AND. SMC negotiation is used only when all policies that match the connection allow the use of SMC negotiation. If any matching policies prohibit the use of SMC negotiation, SMC negotiation is not used.

After the smc-ebpf tool is loaded, if no IPv4 address policy matches the target server IP address, the client is allowed to use SMC negotiation for the target server IP address.

Examples:

If the smc-ebpf tool is loaded without any IPv4 address policy configured, client sockets are allowed to use SMC negotiation when connecting to all server IP addresses.
After the smc-ebpf tool is loaded, the tool configures only one policy that prohibits the use of SMC negotiation for access to 192.168.1.0/24. In this case, no policy matches 192.168.3.11, and SMC negotiation is allowed when 192.168.3.11 is accessed.

Specifically, you can run the following command to set --mode to disable for 0.0.0.0/32 to change the default behavior to prohibiting the use of SMC negotiation when no IPv4 address policy matches the server IP address:

sudo smc-ebpf policy config --ip 0.0.0.0 --mask 32 --mode disable

Similarly, you can run the following command to set --mode to enable for 0.0.0.0/32 to change the default behavior back to allowing the use of SMC negotiation when no IPv4 address policy matches the server IP address:

sudo smc-ebpf policy config --ip 0.0.0.0 --mask 32 --mode enable

Configure IPv4 address policies

You can configure IPv4 address policies based on the default behavior to control whether the client uses SMC negotiation when connecting to specific server IP addresses.

Note

The configured IPv4 address policies control only whether the client uses SMC negotiation when the client socket connects to the server IPv4 address. Whether the server socket uses SMC negotiation is not affected by the IPv4 address policies.

Examples:

Example 1: Allow the client to use SMC negotiation only when connecting to 192.168.2.0/24, and prohibit the client from using SMC negotiation when accessing other server IP addresses.
Run the following commands to set --mode to disable for 0.0.0.0/32 to change the default behavior to prohibiting the use of SMC negotiation when no IPv4 address policy matches the server IP address, and add a policy that allows the use of SMC negotiation for server IP addresses in 192.168.2.0/24:
```
sudo smc-ebpf policy config --ip 0.0.0.0 --mask 32 --mode disable
sudo smc-ebpf policy config --ip 192.168.2.0 --mask 24 --mode enable
```
Run the following command to view the IPv4 policy settings:
```
sudo smc-ebpf policy dump
```
Sample command output:
- key: indicates the IPv4 addresses targeted by the policy.
- value: indicates whether the use of SMC negotiation is allowed. A value of pass indicates that the use of SMC negotiation is allowed, and a value of denied indicates that the use of SMC negotiation is prohibited.
```
# sudo smc-ebpf policy dump
key:     0.0.0.0/32           value:   "denied"
key:     192.168.2.0/24       value:   "pass"
```
If you no longer require the preceding IPv4 address policies, run the following commands to delete the policies for 0.0.0.0/32 and 192.168.2.0/24:
```
sudo smc-ebpf policy delete --ip 192.168.2.0 --mask 24
sudo smc-ebpf policy delete --ip 0.0.0.0 --mask 32
```
Example 2: Prohibit the client from using SMC negotiation only when connecting to 192.168.2.0/24, and allow the client to use SMC negotiation when accessing other server IP addresses.
Run the following command to add a policy that prohibits the use of SMC negotiation for server IP addresses in 192.168.2.0/24:
```
sudo smc-ebpf policy config --ip 192.168.2.0 --mask 24 --mode disable
```
No other operations are required because after the smc-ebpf tool is loaded, if no IPv4 address policy matches the target server IP address, the client is allowed to use SMC negotiation for the target server IP address. The use of SMC negotiation is allowed for server IP addresses other than 192.168.2.0/24.

Clear policies

Run the following command to clear all configured policies:

sudo smc-ebpf policy clear

After you run the preceding command, all configured policies are deleted, and the default behavior is restored to prohibiting SMC negotiation. In this case, the use of SMC negotiation is prohibited for all ports and allowed for all IPv4 addresses. Port policies and IPv4 address policies are evaluated by using a logical AND. As a result, all connections are prohibited from using SMC negotiation.

Use SMC in Alibaba Cloud ACK

In Alibaba Cloud Container Service for Kubernetes (ACK), you can enable SMC by using the ACK eRDMA Controller component. eRDMA Controller is used to manage and schedule ERIs and provides network capabilities for pods. For more information, see Scenario 2: Use SMC-R to accelerate application networking.

Note

Similar to using SMC on Alibaba Cloud ECS, when you use SMC on Alibaba Cloud ACK, you can also configure BPF-based fine-grained policies for enabling SMC on nodes.

Parameters

The SMC stack provides various configuration interfaces by using sysfs and user-mode tools, such as smc-tools. The following describes the configurable features of SMC.

Configure the following parameters by using sysfs

Kernel parameter	Description	Supported kernel version	Configuration recommendation
net.smc.autocorking_size	SMC-R provides the autocork feature, which is similar to TCP autocork. The autocork feature aggregates multiple small packets into larger packets for transmission in one Send operation. This improves throughput in small packet scenarios without affecting ping-pong latency. The net.smc.autocorking_size parameter specifies the upper limit of the aggregated packet size. Default value: 65535. Valid values: 0 to 4294967295. A value of 0 indicates that the feature is disabled.	Kernel version: `5.10.112-11` and later.	In small packet scenarios where bandwidth matters, you can set this parameter to an appropriate value to achieve the best bandwidth effect. In `pipeline` transmission scenarios where latency is critical, you can set this configuration to 0 to prevent `autocork` from causing delays in pipeline processing.
net.smc.autosplit_size	SMC provides the autosplit feature, which splits a large packet into multiple small packets for batch transmission to improve latency. When the size of a packet exceeds 1.3 times the value of the net.smc.autosplit_size parameter, the packet is split. Default value: 131072. Valid values: 32768 to 536870912.	Kernel version: `5.10.134-18` and later. `5.10.134-17.3` and later in the 17 series. `5.10.134-16.5` and later in the 16 series.	In large packet scenarios where latency matters, you can appropriately adjust this parameter to achieve the best latency effect.
net.smc.experiment_vendor_options	The Alibaba Cloud experimental feature options. Default value: 4294967295 (0xFFFFFFFF).	Kernel version: `5.10.134-16` and later.	We recommend that you retain the default value.
net.smc.global_mem	The system-level memory usage threshold for SMC. When the size of the transmit and receive buffers maintained by the SMC stack is greater than or equal to the value of `global_mem[2]`, all new SMC connections fall back to TCP. Default value: [25% of the system-level memory, 50% of the system-level memory, 75% of the system-level memory].	Kernel version: `5.10.134-18` and later. `5.10.134-17.3` and later in the 17 series. `5.10.134-16.5` and later in the 16 series.	You can configure `global_mem[2]` based on the expected memory level.
net.smc.limit_smc_hs	Controls whether to fall back to TCP in case of high connection pressure. Default value: 1. Valid values: 0: does not fall back to TCP. 1: falls back to TCP.	Kernel version: `5.10.134-18` and later. `5.10.134-17.3` and later in the 17 series. `5.10.134-16.5` and later in the 16 series.	We recommend that you set this parameter to 1. In scenarios in which you do not want the SMC stack to fall back based on connection pressure, you can set this parameter to 0.
net.smc.mem	The memory usage threshold for SMC in the current `net namespace`. When the size of transmit and receive buffers used by all SMC connections in the `net namespace` is greater than or equal to the value of `mem[2]`, all new SMC connections in the `net namespace` fall back to TCP. Default value: [25% of the system-level memory, 50% of the system-level memory, 75% of the system-level memory].	Kernel version: `5.10.134-18` and later. `5.10.134-17.3` and later in the 17 series. `5.10.134-16.5` and later in the 16 series.	You can configure `mem[2]` based on the expected memory level.
net.smc.rmem	The default receive buffer size for SMC sockets. If `setsockopt()` is not used to set the receive buffer (`SO_RCVBUF`) size, the value of this parameter is used. Default value: 262144. Valid values: SMC-R: 16384 (16 KB) to 536870912 (512 MB) SMC-D: 16384 (16 KB) to 1048576 (1 MB)	Kernel version: `5.10.134-14` and later.	When the proportion of the `Rx/Buffer full` metric on the local end is high, we recommend that you appropriately increase the local receive buffer size. When the proportions of the `Tx/Buffer full(remote)` and `Tx/Buffer too small(remote)` metrics on the local end are high, we recommend that you appropriately increase the receive buffer size on the peer end. When memory resources are constrained and reducing the buffer size does not affect network performance, you can appropriately reduce the buffer size. For more information, see SMC monitoring.
net.smc.wmem	The default transmit buffer size for SMC sockets. If `setsockopt()` is not used to set the transmit buffer (`SO_SNDBUF`) size, the value of this parameter is used. Default value: 262144. Valid values: SMC-R: 16384 (16 KB) to 536870912 (512 MB) SMC-D: 16384 (16 KB) to 1048576 (1 MB)	Kernel version: `5.10.134-14` and later.	When the proportions of the `Tx/Buffer full` and `Tx/Buffer too small` metrics on the local end are high, we recommend that you appropriately increase the local transmit buffer size. When memory resources are constrained and reducing the buffer size does not affect network performance, you can appropriately reduce the buffer size. For more information, see SMC monitoring.
net.smc.smcr_buf_type	The memory type for SMC-R transmit and receive buffers. Using physically contiguous memory provides better performance, but physically contiguous memory is usually difficult to obtain and may result in smaller-than-expected buffers. Conversely, virtually contiguous memory is easier to obtain, but the performance is slightly inferior. After the value of this parameter is changed, it takes effect for SMC connections carried by new link groups, and existing link groups are not affected. Default value: 2. Valid values: 0: uses physically contiguous memory. 1: uses virtually contiguous memory. 2: preferentially uses physically contiguous memory. If physically contiguous memory cannot be obtained, use virtually contiguous memory.	Kernel version: `5.10.134-12` and later.	We recommend that you retain the default value.
net.smc.smcr_max_conns_per_lgr	The maximum number of SMC connections that an SMC-R link group. Default value: 32. Valid values: 1 to 255 (Supported kernel version: `5.10.134-18` and later, `5.10.134-17.3` and later in the 17 series, `5.10.134-16.5` and later in the 16 series). 16 to 255 (other kernel versions).	Kernel version: `5.10.134-16.1` and later.	Modify with caution. For high-throughput scenarios, you can appropriately reduce the number of SMC connections carried by each link group to ensure that each SMC connection can obtain more RDMA bandwidth. We recommend that you do not increase the value.
net.smc.smcr_max_links_per_lgr	The number of RDMA reliable connections (RCs) (SMC Links) contained in an SMC-R link group. Default value: 1. Valid values: 1 and 2.	Kernel version: `5.10.134-16.1` and later.	We recommend that you retain the default value.
net.smc.smcr_testlink_time	The heartbeat packet interval (in seconds) for RDMA RC connections (SMC Links) in SMC-R. When no data is transmitted on an SMC Link, 16 bytes of data are transmitted every `smcr_testlink_time` seconds to confirm that the link is available. Default value: 30. Valid values: 0 to 2147483647. A value of 0 indicates that heartbeat check is disabled.	Kernel version: `5.10.134-13` and later.	We recommend that you retain the default value.
net.smc.tcp2smc	Controls whether to enable transparent conversion from TCP to SMC in the current `net namespace`. After transparent conversion from TCP to SMC is enabled, new TCP sockets in the `net namespace` are intercepted in the kernel and converted into SMC sockets to run on the SMC stack after the `family` and `protocol` parameters are replaced. Default value: 0. Valid values: 0: disables transparent conversion from TCP to SMC in the current `net namespace`. 1: enables transparent conversion from TCP to SMC in the current `net namespace`.	Kernel version: `5.10.134-16` and later.	Set this parameter to 1 to enable transparent conversion from TCP to SMC in the `net namespace`. Set this parameter to 0 to disable transparent conversion from TCP to SMC in the `net namespace`.

Configure EIDs

Enterprise ID (EID) is a concept introduced in the SMCv2 protocol. Only systems configured with the same EID can communicate by using SMCv2. Otherwise, they fall back to TCP. A system can be configured with up to eight EIDs.

In Alibaba Cloud Linux 3, eRDMA devices can be used with only the SMCv2 protocol. Alibaba Cloud Linux 3 is initially configured with the EID SMCV2-DEFAULT-UEID. Therefore, all Alibaba Cloud Linux 3 nodes in the initial state can communicate with eRDMA devices by using SMCv2 without additional manual configuration.

If you want to control the communication scope by modifying EIDs in special cases, perform the following steps:

View existing EIDs.
```
smcr ueid show
```
Add a new EID.
An EID can be up to 32 characters in length and contain uppercase letters, digits, hyphens (-), and periods (.). An EID must start with a letter or digit and cannot contain consecutive periods (.).
```
sudo smcr ueid add <EID>
```
Delete an existing EID.
```
sudo smcr ueid del <EID>
```

Use case: Use EIDs to prevent cross-zone SMC-R communication

To better leverage SMC-R for performance acceleration, we recommend that you use SMC-R within the same zone and TCP communication across zones. By adding the zone ID as an EID, you can implement SMC-R within the same zone and automatic fallback to TCP across zones.

Method 1: Configure an EID step by step
1. Run the following command to obtain the zone ID from Alibaba Cloud ECS instance metadata:
```
ZONE_ID=$(curl -s -m 1 100.100.100.200/latest/meta-data/zone-id | tr "[:lower:]" "[:upper:]")
```
2. Run the following command to add the zone ID as an EID:
```
sudo smcr ueid add $ZONE_ID
```
3. Run the following command to delete the SMCV2-DEFAULT-UEID value:
```
smcr ueid | grep SMCV2-DEFAULT-UEID > /dev/null && sudo smcr ueid del SMCV2-DEFAULT-UEID
```
Method 2: Use the aliyunsmc-ueid service of the aliyun-smc-extensions tool to configure an EID with one click
1. Run the following command to start the aliyunsmc-ueid service. This service automatically adds the zone ID as an EID and deletes the default EID.
```
sudo systemctl start aliyunsmc-ueid
```
2. (Optional) Run the following command to configure the aliyunsmc-ueid service to start automatically at boot. This is because the EID configuration is not persistent and is restored to the default state when the operating system restarts.
```
sudo systemctl enable aliyunsmc-ueid
```

Configure physical-network identifiers (PNET IDs)

In TCP communication, network traffic enters and exits through Ethernet interfaces. When TCP communication is transparently converted to SMC-R communication, the SMC-R stack uses the ERIs associated with the Ethernet interfaces.

This association has the following two forms:

After you obtain an ERI by enabling eRDMA on the target Ethernet interface, the SMC-R stack automatically associates the Ethernet interface with the ERI.
- To check whether eRDMA is enabled on an Ethernet interface, see View ERIs.
- To enable eRDMA when you create an Ethernet interface, see Create an ERI.
- To enable eRDMA for an existing Ethernet interface, see Change the status of the ERI feature for an existing ENI.
In this case, the SMC-R stack can automatically identify and use the ERI associated with the Ethernet interface without additional operations.
After you obtain ERIs by enabling eRDMA on other Ethernet interfaces, you must use PNET IDs to associate the ERIs with the Ethernet interfaces.
Example:
A node has Ethernet interfaces named eth0 and eth1, and eth0 has eRDMA enabled and is associated with an ERI named erdma_0 .
If TCP traffic is sent and received through eth0 and a transparent TCP-to-SMC conversion occurs, the SMC-R stack can automatically detect the associated erdma_0 ERI and use the RDMA network for communication. This is the first case of automatic association mentioned above.
If TCP traffic is sent and received through eth1 and a transparent TCP-to-SMC conversion occurs, the SMC-R stack cannot automatically detect the erdma_0 ERI and falls back to TCP. In this case, you can use the same PNET ID to associate eth1 with erdma_0 to inform SMC-R that it can use erdma_0 to carry the traffic of eth1.
To associate an Ethernet interface and an ERI by using a PNET ID, perform the following steps:
- Configure the same PNET ID for an Ethernet interface and an ERI.
  - Run the following command to configure a PNET ID for an Ethernet interface:
```
sudo smc_pnet -a <PNET ID> -I <eth_interface>
```
  - Run the following command to configure the same PNET ID for an ERI:
```
sudo smc_pnet -a <PNET ID> -D <rdma_interface>
```
  A PNET ID can be up to 16 characters in length and contain uppercase letters and digits. Spaces are not allowed.
- Run the following command to view PNET IDs:
```
# sudo smc_pnet
```
  Sample command output:
```
# sudo smc_pnet
00163E0CD751 n/a erdma_0 1
00163E0CD751 eth1 n/a 255
```
  In the preceding example, the PNET ID 00163E0CD751 is attached to erdma_0 and eth1. This way, TCP stacks that originally send and receive data through eth1 can send and receive data through erdma_0 after SMC-R is enabled.

Use case: Use PNET IDs to associate Ethernet interfaces of pods with ERIs of hosts

In self-built container scenarios where multiple pods share one or more ERIs on a host, you can set the same PNET ID for the virtual Ethernet interfaces (vEths) of the pods and the ERIs of the host. This way, after SMC-R is enabled in containers, the kernel protocol stack can correctly detect the ERIs of the host and use the RDMA network to accelerate network traffic on the vEths in the containers.

Perform the following steps:

Configure the PNET ID for a vEth, such as eth0, in the container net namespace.
```
sudo ip netns exec <pod netns> smc_pnet -a <PNET ID> -I eth0
```
Configure the PNET ID for an ERI, such as erdma_0, in the host net namespace.
```
sudo smc_pnet -a <PNET ID> -D erdma_0
```

Use case: Use SMC in scenarios in which ECS is used with Redis

Create two ECS instances, one as the Redis client and the other as the Redis server. For information about how to create an ECS instance, see Create an instance on the Custom Launch tab.
Run the following commands to the smc and smc_diag kernel modules:
```
sudo modprobe smc
sudo modprobe smc_diag
```
Run the following command to install Redis on the ECS instances:
```
sudo yum install redis -y
```
Run the following command on the ECS instances to use EIDs to prevent cross-zone SMC-R communication:
```
sudo systemctl start aliyunsmc-ueid
```
On the ECS instances, configure port-based BPF policies that allow connections to use SMC negotiation only if the connections are associated with server IP addresses from within the CIDR block of the connected vSwitch and the server port 6379.
1. Load the smc-ebpf tool.
```
sudo smc-ebpf policy load
```
2. Add a port policy that allows only port 6379 to use SMC negotiation.
```
sudo smc-ebpf policy config --port 6379 --mode enable
```
3. Add an IPv4 address policy that allows the use of SMC negotiation for server IP addresses in the CIDR block of the vSwitch connected to the Redis server.
```
sudo smc-ebpf policy config --ip 0.0.0.0 --mask 32 --mode disable
cidr=$(curl -s -m 1 100.100.100.200/latest/meta-data/vswitch-cidr-block)
sudo smc-ebpf policy config --ip \
  $(echo ${cidr} | awk -F'/' '{print $1}') --mask \
  $(echo ${cidr} | awk -F'/' '{print $2}') --enable;
```
Run the following commands on the ECS instances to enable transparent socket conversion in the current net namespace:
```
sudo sysctl -w net.smc.tcp2smc=1
```
Run the following command on the Redis server to start the Redis service.
Replace <IP> with a private IP address of the primary elastic network interface (ENI) bound to the Redis server.
```
redis-server --bind <IP> --port 6379 --protected-mode no --save
```
Connect to or test the Redis server on the Redis client.
- Run the following command to connect to the Redis server:
```
redis-cli -h <IP> -p 6379
```
- Run the following command to perform a stress test by using redis-benchmark:
```
redis-benchmark -h <IP> -p 6379 -n 1000000 -t set -c 100
```