Soul Orbit I'll take a quiet life. A handshake of carbon monoxide. 2024-01-09T07:43:44.000Z http://r12f.com/ r12f Hexo Radxa Zero踩坑记录 http://r12f.com/posts/radxa-zero-getting-started/ 2024-01-08T23:43:44.000Z 2024-01-09T07:43:44.000Z

更新时间：2024/01

一年前，心血来潮买了几块Radxa Zero，觉得很有意思，可惜最近想升级到新的系统之后就出了问题，刷机挣扎了好几天，官方文档也已经各种过时了，于是决定记录一下踩坑的过程。

1. 系统安装

Radxa Zero有自带eMMC和不带eMMC两个版本，两个版本使用sd卡运行系统都是ok的，但是如果想将系统刷入eMMC并用eMMC进行引导，就很容易遇到u-boot无法引导的问题。网上有很多讨论，但是大多都已经过时了，官方提供的troubleshooting guide也非常的模糊，提供的u-boot更新依然有问题，即便是成功更新了u-boot，也有可能重启之后u-boot的patch就又失效了。在经过了一周的挣扎之后，以下是我找到的能用的方法。

1.1. 官方镜像

首先是Radxa Zero的官方镜像，最新的发布可以在这里找到：Github。但是在本文写成的时候，最新的版本已经很久都没有更新了，还是2022/08/01发布的，想尝试新系统的话，就无法使用了。

想要使用官方镜像的话，可以尝试使用最新的测试版本：Github（当前是test-build-4）。这些镜像都自带了修正之后的u-boot，所以可以直接使用最直接的方法刷机，不需要再额外的刷其他版本的u-boot了。我目前使用的就是这个版本的debian系统，暂时再也没有遇到任何和u-boot相关的问题了。

  1. 首先，我们先使用UART连接到zero的串口，并在电脑上使用Console打开它的串口，PuTTY，MobaXterm，tio都可以。
  2. 然后，进入Radxa Zero的maskrom模式。
  3. 然后，将eMMC擦除。擦除完成后，zero的eMMC会被当成一个USB磁盘加载起来。
  4. 最后，使用Etcher刷入镜像。方法和刷microSD卡一样，只是选择的磁盘是zero的eMMC。

重启之后就完成了！我们就可以在Console里面使用默认的账号（rock）和密码（rock）登录啦！

Radxa Zero Boot Official Image

感谢Yuntian给予的帮助！

1.2. Armbian

Armbian最新的版本可以在armbian的官网找到：armbian。但是很不幸，直接刷机的方法是不行的，因为最新Armbian的u-boot依然有问题，会导致无法引导，刷入官方提供的u-boot也无法完全解决这个问题，只能保证一次引导成功，重启后就又会出现问题。需要使用下面的方法才能解决：

  1. 首先，将armbian的镜像刷入一张sd卡中。
  2. 然后，我们使用上面刷官方镜像的方法，连接UART，并将eMMC擦除。
  3. 擦除完成后，我们不要直接去刷armbian的镜像，而是将刷好的sd卡插入zero，然后重启，利用sd卡进行引导，并进入armbian。

如果你能使用sd卡进行引导，进入armbian，那么恭喜你，你已经成功一大半了！接下来，我们需要连接Wifi（请参考“设置系统->连接到Wifi”一节），然后使用armbian-config来将u-boot和系统都刷入eMMC中：

注意：armbian初始设置时也会提示你连接wifi，但是这个连接成功可能会是一个虚假的成功，有IP但是除了本地127.0.0.1什么都连不上，所以最好使用nmcli重新连接一次。

1
sudo armbian-config
  1. 然后在界面里面选择：
    1. System -> Install -> Boot from eMMC - system on eMMC。
      armbian-config Install u-boot
    2. 文件系统选择默认：ext4。
  2. 然后等待u-boot和rootfs传输完成，直到显示关机。
    armbian-config Install u-boot done

关机之后，我们就可以将sd卡取出了。重启zero，就可以看到zero已经可以正常引导了！

如果依然出错，那么可以尝试在u-boot里面运行以下命令：

  • mmc dev 2
  • mmc part

之后再运行mmc info，如果发现可以正常返回mmc的信息，那么就可以运行boot命令，正常引导了。成功之后，再次重启貌似就不会再出现问题了。（我重启了5次，但是不知道有没有意外，如果还是不行，那么现在就只能暂时使用官方镜像了）。

感谢MicroLinux提供的解决方法！大家有兴趣也可以去给他的频道和原视频点赞加鸡腿！

2. 设置系统

2.1. 连接到WiFi

为了方便使用，首先，我们最好通过串口将zero连接到WiFi。这里，我们可以使用nmtui。

有时候nmtui会卡住，不响应键盘输入，这个时候也可以使用nmcli。复制粘贴如下命令运行，然后跟着提示选择就可以了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# Enable WIFI
sudo nmcli radio wifi on
nmcli dev status

# Connect to WIFI
nmcli dev wifi list
sudo nmcli --ask dev wifi connect

# Show WIFI connection
nmcli con show

# Wait for WIFI connection to be ready
echo "Sleep 3 seconds for WIFI connection to be ready ..."
sleep 3

# Test
ping -c 1 8.8.8.8

# Show IP address
ip a

Radxa Zero WiFi setup

如果成功了，就可以看到ping 8.8.8.8可以正常工作，并且最后可以看到自己的IP地址了。

Radxa Zero WiFi setup done

2.2. 创建用户

连接上wifi之后，我们就可以使用ssh登录上去，或者继续在串口终端中创建用户和设置机器名了，这里我写了一个小脚本来完成这个枯燥的工作：

1
bash <(curl -sSf https://raw.githubusercontent.com/r12f/config/master/bootstrap/linux/bootstrap.sh)

2.3. 重启系统

这个时候，基本设置就已经完成了，可以重启系统了：

1
sudo reboot now

2.4. 登录并删除默认账户

为了安全，不要忘记删除默认账户：

1
sudo userdel -r rock

这样基本的设置就完成啦！

3. 软件安装

现在，无论是官方镜像还是Armbian，我们可以运行apt upgrade了，所以安装和升级软件就相对简单了。先把系统和源都升级到最新：

1
2
sudo apt update
sudo apt upgrade

3.1. 常用小工具系列

不喜欢的可以自行删除：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
sudo apt install -y iptables \
    iotop \
    bash-completion \
    ca-certificates \
    wget \
    curl \
    vim \
    htop \
    zip \
    lsof \
    net-tools \
    bridge-utils \
    traceroute \
    iperf \
    tcpdump \
    minicom \
    fio \
    stress-ng \
    tshark \
    uuid \
    setserial \
    tio \

3.2. 基本的开发工具

git，c++，python，protobuf，cmake，等等：

1
2
3
4
5
6
7
8
9
10
11
12
sudo apt install -y build-essential \
    g++ \
    git \
    cmake \
    libboost-all-dev \
    libpcap-dev \
    python3 \
    python3-dev \
    python3-pip \
    python3-setuptools \
    pkg-config \
    protobuf-compiler \

3.3. Rust

1
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
原创文章，转载请标明出处：Soul Orbit
本文链接地址：Radxa Zero踩坑记录]]> <blockquote> <p>更新时间：2024/01</p> </blockquote> <p>一年前，心血来潮买了几块Radxa Zero，觉得很有意思，可惜最近想升级到新的系统之后就出了问题，刷机挣扎了好几天，官方文档也已经各种过时了，于是决定记录一下踩坑的过程。</p> <h2 id="系统安装">1. 系统安装</h2> <p>Radxa Zero有自带eMMC和不带eMMC两个版本，两个版本使用sd卡运行系统都是ok的，但是如果想将系统刷入eMMC并用eMMC进行引导，就很容易遇到u-boot无法引导的问题。网上有很多讨论，但是大多都已经过时了，官方提供的<a href="https://wiki.radxa.com/Zero/install/Boot_Troubleshooting">troubleshooting guide</a>也非常的模糊，提供的u-boot更新依然有问题，即便是成功更新了u-boot，也有可能重启之后u-boot的patch就又失效了。在经过了一周的挣扎之后，以下是我找到的能用的方法。</p> SONiC学习笔记（七）：BGP工作流（下）—— BGP路由变更下发 http://r12f.com/posts/sonic-7-bgp-workflow-part-2/ 2023-07-05T05:16:55.000Z 2023-07-05T05:16:55.000Z （以下内容已经整合进《SONiC入门指南》的 BGP路由变更下发 一节中。）

在上一篇中，我们介绍了BGP路由变更的工作流中从bgpd到fpmsync的部分，本篇我们将继续介绍剩下的BGP路由变更的下发流程。

1. SONiC路由变更工作流

当FRR变更内核路由配置后，SONiC便会收到来自Netlink和FPM的通知，然后进行一系列操作将其下发给ASIC，其主要流程如下：

sequenceDiagram    autonumber    participant K as Linux Kernel    box lightyellow bgp容器    participant Z as zebra    participant FPM as fpmsyncd    end    box pink database容器    participant R as Redis    end    box lightblue swss容器    participant OA as orchagent    end    box lightgreen syncd容器    participant SD as syncd    end    participant A as ASIC    K->>FPM: 内核路由变更时通过Netlink发送通知    Z->>FPM: 通过FPM接口和Netlink<br/>消息格式发送路由变更通知    FPM->>R: 通过ProducerStateTable<br/>将路由变更信息写入<br/>APPL_DB    R->>OA: 通过ConsumerStateTable<br/>接收路由变更信息        OA->>OA: 处理路由变更信息<br/>生成SAI路由对象    OA->>SD: 通过ProducerTable<br/>或者ZMQ将SAI路由对象<br/>发给syncd    SD->>R: 接收SAI路由对象，写入ASIC_DB    SD->>A: 通过SAI接口<br/>配置ASIC

1.1. fpmsyncd更新Redis中的路由配置

首先，我们从源头看起。fpmsyncd在启动的时候便会开始监听FPM和Netlink的事件，用于接收路由变更消息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
// File: src/sonic-swss/fpmsyncd/fpmsyncd.cpp
int main(int argc, char **argv)
{
    ...

    DBConnector db("APPL_DB", 0);
    RedisPipeline pipeline(&db);
    RouteSync sync(&pipeline);
    
    // Register netlink message handler
    NetLink netlink;
    netlink.registerGroup(RTNLGRP_LINK);

    NetDispatcher::getInstance().registerMessageHandler(RTM_NEWROUTE, &sync);
    NetDispatcher::getInstance().registerMessageHandler(RTM_DELROUTE, &sync);
    NetDispatcher::getInstance().registerMessageHandler(RTM_NEWLINK, &sync);
    NetDispatcher::getInstance().registerMessageHandler(RTM_DELLINK, &sync);

    rtnl_route_read_protocol_names(DefaultRtProtoPath);
    ...

    while (true) {
        try {
            // Launching FPM server and wait for zebra to connect.
            FpmLink fpm(&sync);
            ...

            fpm.accept();
            ...
        } catch (FpmLink::FpmConnectionClosedException &e) {
            // If connection is closed, keep retrying until it succeeds, before handling any other events.
            cout << "Connection lost, reconnecting..." << endl;
        }
        ...
    }
}

这样，所有的路由变更消息都会以Netlink的形式发送给RouteSync，其中[EVPN Type 5][EVPN]必须以原始消息的形式进行处理，所以会发送给onMsgRaw，其他的消息都会统一的发给处理Netlink的onMsg回调：（关于Netlink如何接收和处理消息，请移步之前总结的通信机制一篇）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// File: src/sonic-swss/fpmsyncd/fpmlink.cpp
// Called from: FpmLink::readData()
void FpmLink::processFpmMessage(fpm_msg_hdr_t* hdr)
{
    size_t msg_len = fpm_msg_len(hdr);
    nlmsghdr *nl_hdr = (nlmsghdr *)fpm_msg_data(hdr);
    ...

    /* Read all netlink messages inside FPM message */
    for (; NLMSG_OK (nl_hdr, msg_len); nl_hdr = NLMSG_NEXT(nl_hdr, msg_len))
    {
        /*
         * EVPN Type5 Add Routes need to be process in Raw mode as they contain
         * RMAC, VLAN and L3VNI information.
         * Where as all other route will be using rtnl api to extract information
         * from the netlink msg.
         */
        bool isRaw = isRawProcessing(nl_hdr);
        
        nl_msg *msg = nlmsg_convert(nl_hdr);
        ...
        nlmsg_set_proto(msg, NETLINK_ROUTE);

        if (isRaw) {
            /* EVPN Type5 Add route processing */
            /* This will call into onRawMsg() */
            processRawMsg(nl_hdr);
        } else {
            /* This will call into onMsg() */
            NetDispatcher::getInstance().onNetlinkMessage(msg);
        }

        nlmsg_free(msg);
    }
}

void FpmLink::processRawMsg(struct nlmsghdr *h)
{
    m_routesync->onMsgRaw(h);
};

接着，RouteSync收到路由变更的消息之后，会在onMsg和onMsgRaw中进行判断和分发：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// File: src/sonic-swss/fpmsyncd/routesync.cpp
void RouteSync::onMsgRaw(struct nlmsghdr *h)
{
    if ((h->nlmsg_type != RTM_NEWROUTE) && (h->nlmsg_type != RTM_DELROUTE))
        return;
    ...
    onEvpnRouteMsg(h, len);
}

void RouteSync::onMsg(int nlmsg_type, struct nl_object *obj)
{
    // Refill Netlink cache here
    ...

    struct rtnl_route *route_obj = (struct rtnl_route *)obj;
    auto family = rtnl_route_get_family(route_obj);
    if (family == AF_MPLS) {
        onLabelRouteMsg(nlmsg_type, obj);
        return;
    }
    ...

    unsigned int master_index = rtnl_route_get_table(route_obj);
    char master_name[IFNAMSIZ] = {0};
    if (master_index) {
        /* If the master device name starts with VNET_PREFIX, it is a VNET route.
        The VNET name is exactly the name of the associated master device. */
        getIfName(master_index, master_name, IFNAMSIZ);
        if (string(master_name).find(VNET_PREFIX) == 0) {
            onVnetRouteMsg(nlmsg_type, obj, string(master_name));
        }

        /* Otherwise, it is a regular route (include VRF route). */
        else {
            onRouteMsg(nlmsg_type, obj, master_name);
        }
    } else {
        onRouteMsg(nlmsg_type, obj, NULL);
    }
}

从上面的代码中，我们可以看到这里会有四种不同的路由处理入口，这些不同的路由会被最终通过各自的ProducerStateTable写入到APPL_DB中的不同的Table中：

路由类型处理函数Table
MPLSonLabelRouteMsgLABLE_ROUTE_TABLE
Vnet VxLan Tunnel RouteonVnetRouteMsgVNET_ROUTE_TUNNEL_TABLE
其他Vnet路由onVnetRouteMsgVNET_ROUTE_TABLE
EVPN Type 5onEvpnRouteMsgROUTE_TABLE
普通路由onRouteMsgROUTE_TABLE

这里以普通路由来举例子，其他的函数的实现虽然有所不同，但是主体的思路是一样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// File: src/sonic-swss/fpmsyncd/routesync.cpp
void RouteSync::onRouteMsg(int nlmsg_type, struct nl_object *obj, char *vrf)
{
    // Parse route info from nl_object here.
    ...
    
    // Get nexthop lists
    string gw_list;
    string intf_list;
    string mpls_list;
    getNextHopList(route_obj, gw_list, mpls_list, intf_list);
    ...

    // Build route info here, including protocol, interface, next hops, MPLS, weights etc.
    vector<FieldValueTuple> fvVector;
    FieldValueTuple proto("protocol", proto_str);
    FieldValueTuple gw("nexthop", gw_list);
    ...

    fvVector.push_back(proto);
    fvVector.push_back(gw);
    ...
    
    // Push to ROUTE_TABLE via ProducerStateTable.
    m_routeTable.set(destipprefix, fvVector);
    SWSS_LOG_DEBUG("RouteTable set msg: %s %s %s %s", destipprefix, gw_list.c_str(), intf_list.c_str(), mpls_list.c_str());
    ...
}

1.2. orchagent处理路由配置变化

接下来，这些路由信息会来到orchagent。在orchagent启动的时候，它会创建好VNetRouteOrch和RouteOrch对象，这两个对象分别用来监听和处理Vnet相关路由和EVPN/普通路由：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// File: src/sonic-swss/orchagent/orchdaemon.cpp
bool OrchDaemon::init()
{
    ...

    vector<string> vnet_tables = { APP_VNET_RT_TABLE_NAME, APP_VNET_RT_TUNNEL_TABLE_NAME };
    VNetRouteOrch *vnet_rt_orch = new VNetRouteOrch(m_applDb, vnet_tables, vnet_orch);
    ...

    const int routeorch_pri = 5;
    vector<table_name_with_pri_t> route_tables = {
        { APP_ROUTE_TABLE_NAME,        routeorch_pri },
        { APP_LABEL_ROUTE_TABLE_NAME,  routeorch_pri }
    };
    gRouteOrch = new RouteOrch(m_applDb, route_tables, gSwitchOrch, gNeighOrch, gIntfsOrch, vrf_orch, gFgNhgOrch, gSrv6Orch);
    ...
}

所有Orch对象的消息处理入口都是doTask，这里RouteOrch和VNetRouteOrch也不例外，这里我们以RouteOrch为例子，看看它是如何处理路由变化的。

note
1
从`RouteOrch`上，我们可以真切的感受到为什么这些类被命名为`Orch`。`RouteOrch`有2500多行，其中会有和很多其他Orch的交互，以及各种各样的细节…… 代码是相对难读，请大家读的时候一定保持耐心。

RouteOrch在处理路由消息的时候有几点需要注意：

  • 从上面init函数，我们可以看到RouteOrch不仅会管理普通路由，还会管理MPLS路由，这两种路由的处理逻辑是不一样的，所以在下面的代码中，为了简化，我们只展示普通路由的处理逻辑。
  • 因为ProducerStateTable在传递和接受消息的时候都是批量传输的，所以，RouteOrch在处理消息的时候，也是批量处理的。为了支持批量处理，RouteOrch会借用EntityBulker<sai_route_api_t> gRouteBulker将需要改动的SAI路由对象缓存起来，然后在doTask()函数的最后，一次性将这些路由对象的改动应用到SAI中。
  • 路由的操作会需要很多其他的信息，比如每个Port的状态，每个Neighbor的状态，每个VRF的状态等等。为了获取这些信息，RouteOrch会与其他的Orch对象进行交互，比如PortOrch，NeighOrch，VRFOrch等等。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
// File: src/sonic-swss/orchagent/routeorch.cpp
void RouteOrch::doTask(Consumer& consumer)
{
    // Calling PortOrch to make sure all ports are ready before processing route messages.
    if (!gPortsOrch->allPortsReady()) { return; }

    // Call doLabelTask() instead, if the incoming messages are from MPLS messages. Otherwise, move on as regular routes.
    ...

    /* Default handling is for ROUTE_TABLE (regular routes) */
    auto it = consumer.m_toSync.begin();
    while (it != consumer.m_toSync.end()) {
        // Add or remove routes with a route bulker
        while (it != consumer.m_toSync.end())
        {
            KeyOpFieldsValuesTuple t = it->second;

            // Parse route operation from the incoming message here.
            string key = kfvKey(t);
            string op = kfvOp(t);
            ...

            // resync application:
            // - When routeorch receives 'resync' message (key = "resync", op = "SET"), it marks all current routes as dirty
            //   and waits for 'resync complete' message. For all newly received routes, if they match current dirty routes,
            //   it unmarks them dirty.
            // - After receiving 'resync complete' (key = "resync", op != "SET") message, it creates all newly added routes
            //   and removes all dirty routes.
            ...

            // Parsing VRF and IP prefix from the incoming message here.
            ...

            // Process regular route operations.
            if (op == SET_COMMAND)
            {
                // Parse and validate route attributes from the incoming message here.
                string ips;
                string aliases;
                ...

                // If the nexthop_group is empty, create the next hop group key based on the IPs and aliases. 
                // Otherwise, get the key from the NhgOrch. The result will be stored in the "nhg" variable below.
                NextHopGroupKey& nhg = ctx.nhg;
                ...
                if (nhg_index.empty())
                {
                    // Here the nexthop_group is empty, so we create the next hop group key based on the IPs and aliases.
                    ...

                    string nhg_str = "";
                    if (blackhole) {
                        nhg = NextHopGroupKey();
                    } else if (srv6_nh == true) {
                        ...
                        nhg = NextHopGroupKey(nhg_str, overlay_nh, srv6_nh);
                    } else if (overlay_nh == false) {
                        ...
                        nhg = NextHopGroupKey(nhg_str, weights);
                    } else {
                        ...
                        nhg = NextHopGroupKey(nhg_str, overlay_nh, srv6_nh);
                    }
                }
                else
                {
                    // Here we have a nexthop_group, so we get the key from the NhgOrch.
                    const NhgBase& nh_group = getNhg(nhg_index);
                    nhg = nh_group.getNhgKey();
                    ...
                }
                ...

                // Now we start to create the SAI route entry.
                if (nhg.getSize() == 1 && nhg.hasIntfNextHop())
                {
                    // Skip certain routes, such as not valid, directly routes to tun0, linklocal or multicast routes, etc.
                    ...

                    // Create SAI route entry in addRoute function.
                    if (addRoute(ctx, nhg)) it = consumer.m_toSync.erase(it);
                    else it++;
                }

                /*
                 * Check if the route does not exist or needs to be updated or
                 * if the route is using a temporary next hop group owned by
                 * NhgOrch.
                 */
                else if (m_syncdRoutes.find(vrf_id) == m_syncdRoutes.end() ||
                    m_syncdRoutes.at(vrf_id).find(ip_prefix) == m_syncdRoutes.at(vrf_id).end() ||
                    m_syncdRoutes.at(vrf_id).at(ip_prefix) != RouteNhg(nhg, ctx.nhg_index) ||
                    gRouteBulker.bulk_entry_pending_removal(route_entry) ||
                    ctx.using_temp_nhg)
                {
                    if (addRoute(ctx, nhg)) it = consumer.m_toSync.erase(it);
                    else it++;
                }
                ...
            }
            // Handle other ops, like DEL_COMMAND for route deletion, etc.
            ...
        }

        // Flush the route bulker, so routes will be written to syncd and ASIC
        gRouteBulker.flush();

        // Go through the bulker results.
        // Handle SAI failures, update neighbors, counters, send notifications in add/removeRoutePost functions.
        ... 

        /* Remove next hop group if the reference count decreases to zero */
        ...
    }
}

解析完路由操作后，RouteOrch会调用addRoute或者removeRoute函数来创建或者删除路由。这里以添加路由addRoute为例子来继续分析。它的逻辑主要分为几个大部分：

  1. 从NeighOrch中获取下一跳信息，并检查下一跳是否真的可用。
  2. 如果是新路由，或者是重新添加正在等待删除的路由，那么就会创建一个新的SAI路由对象
  3. 如果是已有的路由，那么就更新已有的SAI路由对象
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
// File: src/sonic-swss/orchagent/routeorch.cpp
bool RouteOrch::addRoute(RouteBulkContext& ctx, const NextHopGroupKey &nextHops)
{
    // Get nexthop information from NeighOrch.
    // We also need to check PortOrch for inband port, IntfsOrch to ensure the related interface is created and etc.
    ...
    
    // Start to sync the SAI route entry.
    sai_route_entry_t route_entry;
    route_entry.vr_id = vrf_id;
    route_entry.switch_id = gSwitchId;
    copy(route_entry.destination, ipPrefix);

    sai_attribute_t route_attr;
    auto& object_statuses = ctx.object_statuses;
    
    // Create a new route entry in this case.
    //
    // In case the entry is already pending removal in the bulk, it would be removed from m_syncdRoutes during the bulk call.
    // Therefore, such entries need to be re-created rather than set attribute.
    if (it_route == m_syncdRoutes.at(vrf_id).end() || gRouteBulker.bulk_entry_pending_removal(route_entry)) {
        if (blackhole) {
            route_attr.id = SAI_ROUTE_ENTRY_ATTR_PACKET_ACTION;
            route_attr.value.s32 = SAI_PACKET_ACTION_DROP;
        } else {
            route_attr.id = SAI_ROUTE_ENTRY_ATTR_NEXT_HOP_ID;
            route_attr.value.oid = next_hop_id;
        }

        /* Default SAI_ROUTE_ATTR_PACKET_ACTION is SAI_PACKET_ACTION_FORWARD */
        object_statuses.emplace_back();
        sai_status_t status = gRouteBulker.create_entry(&object_statuses.back(), &route_entry, 1, &route_attr);
        if (status == SAI_STATUS_ITEM_ALREADY_EXISTS) {
            return false;
        }
    }
    
    // Update existing route entry in this case.
    else {
        // Set the packet action to forward when there was no next hop (dropped) and not pointing to blackhole.
        if (it_route->second.nhg_key.getSize() == 0 && !blackhole) {
            route_attr.id = SAI_ROUTE_ENTRY_ATTR_PACKET_ACTION;
            route_attr.value.s32 = SAI_PACKET_ACTION_FORWARD;

            object_statuses.emplace_back();
            gRouteBulker.set_entry_attribute(&object_statuses.back(), &route_entry, &route_attr);
        }

        // Only 1 case is listed here as an example. Other cases are handled with similar logic by calling set_entry_attributes as well.
        ...
    }
    ...
}

在创建和设置好所有的路由后，RouteOrch会调用gRouteBulker.flush()来将所有的路由写入到ASIC_DB中。flush()函数很简单，就是将所有的请求分批次进行处理，默认情况下每一批是1000个，这个定义在OrchDaemon中，并通过构造函数传入：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
// File: src/sonic-swss/orchagent/orchdaemon.cpp
#define DEFAULT_MAX_BULK_SIZE 1000
size_t gMaxBulkSize = DEFAULT_MAX_BULK_SIZE;

// File: src/sonic-swss/orchagent/bulker.h
template <typename T>
class EntityBulker
{
public:
    using Ts = SaiBulkerTraits<T>;
    using Te = typename Ts::entry_t;
    ...

    void flush()
    {
        // Bulk remove entries
        if (!removing_entries.empty()) {
            // Split into batches of max_bulk_size, then call flush. Similar to creating_entries, so details are omitted.
            std::vector<Te> rs;
            ...
            flush_removing_entries(rs);
            removing_entries.clear();
        }

        // Bulk create entries
        if (!creating_entries.empty()) {
            // Split into batches of max_bulk_size, then call flush_creating_entries to call SAI batch create API to create
            // the objects in batch.
            std::vector<Te> rs;
            std::vector<sai_attribute_t const*> tss;
            std::vector<uint32_t> cs;
            
            for (auto const& i: creating_entries) {
                sai_object_id_t *pid = std::get<0>(i);
                auto const& attrs = std::get<1>(i);
                if (*pid == SAI_NULL_OBJECT_ID) {
                    rs.push_back(pid);
                    tss.push_back(attrs.data());
                    cs.push_back((uint32_t)attrs.size());

                    // Batch create here.
                    if (rs.size() >= max_bulk_size) {
                        flush_creating_entries(rs, tss, cs);
                    }
                }
            }

            flush_creating_entries(rs, tss, cs);
            creating_entries.clear();
        }

        // Bulk update existing entries
        if (!setting_entries.empty()) {
            // Split into batches of max_bulk_size, then call flush. Similar to creating_entries, so details are omitted.
            std::vector<Te> rs;
            std::vector<sai_attribute_t> ts;
            std::vector<sai_status_t*> status_vector;
            ...
            flush_setting_entries(rs, ts, status_vector);
            setting_entries.clear();
        }
    }

    sai_status_t flush_creating_entries(
        _Inout_ std::vector<Te> &rs,
        _Inout_ std::vector<sai_attribute_t const*> &tss,
        _Inout_ std::vector<uint32_t> &cs)
    {
        ...

        // Call SAI bulk create API
        size_t count = rs.size();
        std::vector<sai_status_t> statuses(count);
        sai_status_t status = (*create_entries)((uint32_t)count, rs.data(), cs.data(), tss.data()
            , SAI_BULK_OP_ERROR_MODE_IGNORE_ERROR, statuses.data());

        // Set results back to input entries and clean up the batch below.
        for (size_t ir = 0; ir < count; ir++) {
            auto& entry = rs[ir];
            sai_status_t *object_status = creating_entries[entry].second;
            if (object_status) {
                *object_status = statuses[ir];
            }
        }

        rs.clear(); tss.clear(); cs.clear();
        return status;
    }

    // flush_removing_entries and flush_setting_entries are similar to flush_creating_entries, so we omit them here.
    ...
};

1.3. orchagent中的SAI对象转发

细心的小伙伴肯定已经发现了奇怪的地方，这里EntityBulker怎么看着像在直接调用SAI API呢？难道它们不应该是在syncd中调用的吗？如果我们对传入EntityBulker的SAI API对象进行跟踪，我们甚至会找到sai_route_api_t就是SAI的接口，而orchagent中还有SAI的初始化代码，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
// File: src/sonic-sairedis/debian/libsaivs-dev/usr/include/sai/sairoute.h
/**
 * @brief Router entry methods table retrieved with sai_api_query()
 */
typedef struct _sai_route_api_t
{
    sai_create_route_entry_fn                   create_route_entry;
    sai_remove_route_entry_fn                   remove_route_entry;
    sai_set_route_entry_attribute_fn            set_route_entry_attribute;
    sai_get_route_entry_attribute_fn            get_route_entry_attribute;

    sai_bulk_create_route_entry_fn              create_route_entries;
    sai_bulk_remove_route_entry_fn              remove_route_entries;
    sai_bulk_set_route_entry_attribute_fn       set_route_entries_attribute;
    sai_bulk_get_route_entry_attribute_fn       get_route_entries_attribute;
} sai_route_api_t;

// File: src/sonic-swss/orchagent/saihelper.cpp
void initSaiApi()
{
    SWSS_LOG_ENTER();

    if (ifstream(CONTEXT_CFG_FILE))
    {
        SWSS_LOG_NOTICE("Context config file %s exists", CONTEXT_CFG_FILE);
        gProfileMap[SAI_REDIS_KEY_CONTEXT_CONFIG] = CONTEXT_CFG_FILE;
    }

    sai_api_initialize(0, (const sai_service_method_table_t *)&test_services);
    sai_api_query(SAI_API_SWITCH,               (void **)&sai_switch_api);
    ...
    sai_api_query(SAI_API_NEIGHBOR,             (void **)&sai_neighbor_api);
    sai_api_query(SAI_API_NEXT_HOP,             (void **)&sai_next_hop_api);
    sai_api_query(SAI_API_NEXT_HOP_GROUP,       (void **)&sai_next_hop_group_api);
    sai_api_query(SAI_API_ROUTE,                (void **)&sai_route_api);
    ...

    sai_log_set(SAI_API_SWITCH,                 SAI_LOG_LEVEL_NOTICE);
    ...
    sai_log_set(SAI_API_NEIGHBOR,               SAI_LOG_LEVEL_NOTICE);
    sai_log_set(SAI_API_NEXT_HOP,               SAI_LOG_LEVEL_NOTICE);
    sai_log_set(SAI_API_NEXT_HOP_GROUP,         SAI_LOG_LEVEL_NOTICE);
    sai_log_set(SAI_API_ROUTE,                  SAI_LOG_LEVEL_NOTICE);
    ...
}

相信大家第一次看到这个代码会感觉到非常的困惑。不过别着急，这其实就是orchagent中SAI对象的转发机制。

熟悉RPC的小伙伴一定不会对proxy-stub模式感到陌生 —— 利用统一的接口来定义通信双方调用接口，在调用方实现序列化和发送，然后再接收方实现接收，反序列化与分发。这里SONiC的做法也是类似的：利用SAI API本身作为统一的接口，并实现好序列化和发送功能给orchagent来调用，然后再syncd中实现接收，反序列化与分发功能。

这里，发送端叫做ClientSai，实现在src/sonic-sairedis/lib/ClientSai.*中。而序列化与反序列化实现在SAI metadata中：src/sonic-sairedis/meta/sai_serialize.h：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// File: src/sonic-sairedis/lib/ClientSai.h
namespace sairedis
{
    class ClientSai:
        public sairedis::SaiInterface
    {
        ...
    };
}

// File: src/sonic-sairedis/meta/sai_serialize.h
// Serialize
std::string sai_serialize_route_entry(_In_ const sai_route_entry_t &route_entry);
...

// Deserialize
void sai_deserialize_route_entry(_In_ const std::string& s, _In_ sai_route_entry_t &route_entry);
...

orchagent在编译的时候，会去链接libsairedis，从而实现调用SAI API时，对SAI对象进行序列化和发送：

1
2
# File: src/sonic-swss/orchagent/Makefile.am
orchagent_LDADD = $(LDFLAGS_ASAN) -lnl-3 -lnl-route-3 -lpthread -lsairedis -lsaimeta -lsaimetadata -lswsscommon -lzmq

我们这里用Bulk Create作为例子，来看看ClientSai是如何实现序列化和发送的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
// File: src/sonic-sairedis/lib/ClientSai.cpp
sai_status_t ClientSai::bulkCreate(
        _In_ sai_object_type_t object_type,
        _In_ sai_object_id_t switch_id,
        _In_ uint32_t object_count,
        _In_ const uint32_t *attr_count,
        _In_ const sai_attribute_t **attr_list,
        _In_ sai_bulk_op_error_mode_t mode,
        _Out_ sai_object_id_t *object_id,
        _Out_ sai_status_t *object_statuses)
{
    MUTEX();
    REDIS_CHECK_API_INITIALIZED();

    std::vector<std::string> serialized_object_ids;

    // Server is responsible for generate new OID but for that we need switch ID
    // to be sent to server as well, so instead of sending empty oids we will
    // send switch IDs
    for (uint32_t idx = 0; idx < object_count; idx++) {
        serialized_object_ids.emplace_back(sai_serialize_object_id(switch_id));
    }
    auto status = bulkCreate(object_type, serialized_object_ids, attr_count, attr_list, mode, object_statuses);

    // Since user requested create, OID value was created remotely and it was returned in m_lastCreateOids
    for (uint32_t idx = 0; idx < object_count; idx++) {
        if (object_statuses[idx] == SAI_STATUS_SUCCESS) {
            object_id[idx] = m_lastCreateOids.at(idx);
        } else {
            object_id[idx] = SAI_NULL_OBJECT_ID;
        }
    }

    return status;
}

sai_status_t ClientSai::bulkCreate(
        _In_ sai_object_type_t object_type,
        _In_ const std::vector<std::string> &serialized_object_ids,
        _In_ const uint32_t *attr_count,
        _In_ const sai_attribute_t **attr_list,
        _In_ sai_bulk_op_error_mode_t mode,
        _Inout_ sai_status_t *object_statuses)
{
    ...

    // Calling SAI serialize APIs to serialize all objects
    std::string str_object_type = sai_serialize_object_type(object_type);
    std::vector<swss::FieldValueTuple> entries;
    for (size_t idx = 0; idx < serialized_object_ids.size(); ++idx) {
        auto entry = SaiAttributeList::serialize_attr_list(object_type, attr_count[idx], attr_list[idx], false);
        if (entry.empty()) {
            swss::FieldValueTuple null("NULL", "NULL");
            entry.push_back(null);
        }

        std::string str_attr = Globals::joinFieldValues(entry);
        swss::FieldValueTuple fvtNoStatus(serialized_object_ids[idx] , str_attr);
        entries.push_back(fvtNoStatus);
    }
    std::string key = str_object_type + ":" + std::to_string(entries.size());

    // Send to syncd via the communication channel.
    m_communicationChannel->set(key, entries, REDIS_ASIC_STATE_COMMAND_BULK_CREATE);

    // Wait for response from syncd.
    return waitForBulkResponse(SAI_COMMON_API_BULK_CREATE, (uint32_t)serialized_object_ids.size(), object_statuses);
}

最终，ClientSai会调用m_communicationChannel->set()，将序列化后的SAI对象发送给syncd。而这个Channel，在202106版本之前，就是基于Redis的ProducerTable了。可能是基于效率的考虑，从202111版本开始，这个Channel已经更改为ZMQ了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// File: https://github.com/sonic-net/sonic-sairedis/blob/202106/lib/inc/RedisChannel.h
class RedisChannel: public Channel
{
    ...

    /**
      * @brief Asic state channel.
      *
      * Used to sent commands like create/remove/set/get to syncd.
      */
    std::shared_ptr<swss::ProducerTable>  m_asicState;

    ...
};

// File: src/sonic-sairedis/lib/ClientSai.cpp
sai_status_t ClientSai::initialize(
        _In_ uint64_t flags,
        _In_ const sai_service_method_table_t *service_method_table)
{
    ...
    
    m_communicationChannel = std::make_shared<ZeroMQChannel>(
            cc->m_zmqEndpoint,
            cc->m_zmqNtfEndpoint,
            std::bind(&ClientSai::handleNotification, this, _1, _2, _3));

    m_apiInitialized = true;

    return SAI_STATUS_SUCCESS;
}

关于进程通信的方法，这里就不再赘述了，大家可以参考第四章描述的进程间的通信机制。

1.4. syncd更新ASIC

最后，当SAI对象生成好并发送给syncd后，syncd会接收，处理，更新ASIC_DB，最后更新ASIC。这一段的工作流，我们已经在Syncd-SAI工作流中详细介绍过了，这里就不再赘述了，大家可以移步去查看。

2. 参考资料

  1. SONiC Architecture
  2. Github repo: sonic-swss
  3. Github repo: sonic-swss-common
  4. Github repo: sonic-sairedis
同系列文章：
原创文章，转载请标明出处：Soul Orbit
本文链接地址：SONiC学习笔记（七）：BGP工作流（下）—— BGP路由变更下发]]> <p><em>（以下内容已经整合进《SONiC入门指南》的 <a href="https://r12f.com/sonic-book/5-2-2-bgp-route-update-workflow.html">BGP路由变更下发</a> 一节中。）</em></p> <p>在上一篇中，我们介绍了BGP路由变更的工作流中从<code>bgpd</code>到<code>fpmsync</code>的部分，本篇我们将继续介绍剩下的BGP路由变更的下发流程。</p> <h2 id="SONiC路由变更工作流">1. SONiC路由变更工作流</h2> <p>当FRR变更内核路由配置后，SONiC便会收到来自Netlink和FPM的通知，然后进行一系列操作将其下发给ASIC，其主要流程如下：</p> <pre><code class="highlight mermaid">sequenceDiagram autonumber participant K as Linux Kernel box lightyellow bgp容器 participant Z as zebra participant FPM as fpmsyncd end box pink database容器 participant R as Redis end box lightblue swss容器 participant OA as orchagent end box lightgreen syncd容器 participant SD as syncd end participant A as ASIC K-&gt;&gt;FPM: 内核路由变更时通过Netlink发送通知 Z-&gt;&gt;FPM: 通过FPM接口和Netlink&lt;br/&gt;消息格式发送路由变更通知 FPM-&gt;&gt;R: 通过ProducerStateTable&lt;br/&gt;将路由变更信息写入&lt;br/&gt;APPL_DB R-&gt;&gt;OA: 通过ConsumerStateTable&lt;br/&gt;接收路由变更信息 OA-&gt;&gt;OA: 处理路由变更信息&lt;br/&gt;生成SAI路由对象 OA-&gt;&gt;SD: 通过ProducerTable&lt;br/&gt;或者ZMQ将SAI路由对象&lt;br/&gt;发给syncd SD-&gt;&gt;R: 接收SAI路由对象，写入ASIC_DB SD-&gt;&gt;A: 通过SAI接口&lt;br/&gt;配置ASIC</code></pre> SONiC学习笔记（六）：BGP工作流（上）—— 命令实现与FRR http://r12f.com/posts/sonic-6-bgp-workflow-part-1/ 2023-07-02T17:48:21.000Z 2023-07-02T17:48:21.000Z （以下内容已经整合进《SONiC入门指南》的 BGP工作流 ，BGP命令实现和BGP路由变更下发 三节中。）

BGP可能是交换机里面最常用，最重要，或者线上使用的最多的功能了。这一篇，我们就来深入的看一下BGP相关的工作流。

1. BGP相关进程

SONiC使用FRRouting作为BGP的实现，用于负责BGP的协议处理。FRRouting是一个开源的路由软件，支持多种路由协议，包括BGP，OSPF，IS-IS，RIP，PIM，LDP等等。当FRR发布新版本后，SONiC会将其同步到SONiC的FRR实现仓库：sonic-frr中，每一个版本都对应这一个分支，比如frr/8.2。

FRR主要由两个大部分组成，第一个部分是各个协议的实现，这些进程的名字都叫做*d，而当它们收到路由更新的通知的时候，就会告诉第二个部分，也就是zebra进程，然后zebra进程会进行选路，并将最优的路由信息同步到kernel中，其主体结构如下图所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
+----+  +----+  +-----+  +----+  +----+  +----+  +-----+
|bgpd|  |ripd|  |ospfd|  |ldpd|  |pbrd|  |pimd|  |.....|
+----+  +----+  +-----+  +----+  +----+  +----+  +-----+
     |       |        |       |       |       |        |
+----v-------v--------v-------v-------v-------v--------v
|                                                      |
|                         Zebra                        |
|                                                      |
+------------------------------------------------------+
       |                    |                   |
       |                    |                   |
+------v------+   +---------v--------+   +------v------+
|             |   |                  |   |             |
| *NIX Kernel |   | Remote dataplane |   | ........... |
|             |   |                  |   |             |
+-------------+   +------------------+   +-------------+

在SONiC中，这些FRR的进程都跑在bgp的容器中。另外，为了将FRR和Redis连接起来，SONiC在bgp容器中还会运行一个叫做fpgsyncd的进程（Forwarding Plane Manager syncd），它的主要功能是监听kernel的路由更新，然后将其同步到APP_DB中。但是因为这个进程不是FRR的一部分，所以它的实现被放在了sonic-swss仓库中。

2. BGP命令实现

由于BGP是使用FRR来实现的，所以自然而然的，show命令会将直接请求转发给FRR的vtysh，核心代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
## file: src/sonic-utilities/show/bgp_frr_v4.py
## 'summary' subcommand ("show ip bgp summary")
@bgp.command()
@multi_asic_util.multi_asic_click_options
def summary(namespace, display):
    bgp_summary = bgp_util.get_bgp_summary_from_all_bgp_instances(
        constants.IPV4, namespace, display)
    bgp_util.display_bgp_summary(bgp_summary=bgp_summary, af=constants.IPV4)

## file: src/sonic-utilities/utilities_common/bgp_util.py
def get_bgp_summary_from_all_bgp_instances(af, namespace, display):
    # IPv6 case is emitted here for simplicity
    vtysh_cmd = "show ip bgp summary json"
    
    for ns in device.get_ns_list_based_on_options():
        cmd_output = run_bgp_show_command(vtysh_cmd, ns)

def run_bgp_command(vtysh_cmd, bgp_namespace=multi_asic.DEFAULT_NAMESPACE, vtysh_shell_cmd=constants.VTYSH_COMMAND):
    cmd = ['sudo', vtysh_shell_cmd] + bgp_instance_id + ['-c', vtysh_cmd]
    output, ret = clicommon.run_command(cmd, return_cmd=True)

这里，我们也可以通过直接运行vtysh来进行验证：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
root@7260cx3:/etc/sonic/frr# which vtysh
/usr/bin/vtysh

root@7260cx3:/etc/sonic/frr# vtysh

Hello, this is FRRouting (version 7.5.1-sonic).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

7260cx3# show ip bgp summary

IPv4 Unicast Summary:
BGP router identifier 10.1.0.32, local AS number 65100 vrf-id 0
BGP table version 6410
RIB entries 12809, using 2402 KiB of memory
Peers 4, using 85 KiB of memory
Peer groups 4, using 256 bytes of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
10.0.0.57       4      64600      3702      3704        0    0    0 08:15:03         6401     6406
10.0.0.59       4      64600      3702      3704        0    0    0 08:15:03         6401     6406
10.0.0.61       4      64600      3705      3702        0    0    0 08:15:03         6401     6406
10.0.0.63       4      64600      3702      3702        0    0    0 08:15:03         6401     6406

Total number of neighbors 4

而config命令则是通过直接操作CONFIG_DB来实现的，核心代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
## file: src/sonic-utilities/config/main.py

@bgp.group(cls=clicommon.AbbreviationGroup)
def remove():
    "Remove BGP neighbor configuration from the device"
    pass

@remove.command('neighbor')
@click.argument('neighbor_ip_or_hostname', metavar='<neighbor_ip_or_hostname>', required=True)
def remove_neighbor(neighbor_ip_or_hostname):
    """Deletes BGP neighbor configuration of given hostname or ip from devices
       User can specify either internal or external BGP neighbor to remove
    """
    namespaces = [DEFAULT_NAMESPACE]
    removed_neighbor = False
    ...

    # Connect to CONFIG_DB in linux host (in case of single ASIC) or CONFIG_DB in all the
    # namespaces (in case of multi ASIC) and do the sepcified "action" on the BGP neighbor(s)
    for namespace in namespaces:
        config_db = ConfigDBConnector(use_unix_socket_path=True, namespace=namespace)
        config_db.connect()
        if _remove_bgp_neighbor_config(config_db, neighbor_ip_or_hostname):
            removed_neighbor = True
    ...

3. BGP路由变更下发

路由变更几乎是SONiC中最重要的工作流，它的整个流程从bgpd进程开始，到最终通过SAI到达ASIC芯片，中间参与的进程较多，流程也较为复杂，但是弄清楚之后，我们就可以很好的理解SONiC的设计思想，并且举一反三的理解其他配置下发的工作流了。所以这一节，我们就一起来深入的分析一下它的整体流程。

为了方便我们理解和从代码层面来展示，我们把这个流程分成两个大块来介绍，分别是FRR是如何处理路由变化的，和SONiC的路由变更工作流以及它是如何与FRR进行整合的。

3.1. FRR处理路由变更

sequenceDiagram    autonumber    participant N as 邻居节点    box lightblue bgp容器    participant B as bgpd    participant ZH as zebra<br/>（请求处理线程）    participant ZF as zebra<br/>（路由处理线程）    participant ZD as zebra<br/>（数据平面处理线程）    participant ZFPM as zebra<br/>（FPM转发线程）    participant FPM as fpmsyncd    end    participant K as Linux Kernel    N->>B: 建立BGP会话，<br/>发送路由变更    B->>B: 选路，变更本地路由表（RIB）    alt 如果路由发生变化    B->>N: 通知其他邻居节点路由变化    end    B->>ZH: 通过zlient本地Socket<br/>通知Zebra更新路由表    ZH->>ZH: 接受bgpd发送的请求    ZH->>ZF: 将路由请求放入<br/>路由处理线程的队列中    ZF->>ZF: 更新本地路由表（RIB）    ZF->>ZD: 将路由表更新请求放入<br/>数据平面处理线程<br/>的消息队列中    ZF->>ZFPM: 请求FPM处理线程转发路由变更    ZFPM->>FPM: 通过FPM协议通知<br/>fpmsyncd下发<br/>路由变更    ZD->>K: 发送Netlink消息更新内核路由表

关于FRR的实现，这里更多的是从代码的角度来阐述其工作流的过程，而不是其对BGP的实现细节，如果想要了解FRR的BGP实现细节，可以参考官方文档。

3.1.1. bgpd处理路由变更

bgpd是FRR中专门用来处理BGP会话的进程，它会开放TCP 179端口与邻居节点建立BGP连接，并处理路由表的更新请求。当路由发生变化后，FRR也会通过它来通知其他邻居节点。

请求来到bgpd之后，它会首先来到它的io线程：bgp_io。顾名思义，bgpd中的网络读写工作都是在这个线程上完成的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// File: src/sonic-frr/frr/bgpd/bgp_io.c
static int bgp_process_reads(struct thread *thread)
{
    ...

    while (more) {
        // Read packets here
        ...
  
        // If we have more than 1 complete packet, mark it and process it later.
        if (ringbuf_remain(ibw) >= pktsize) {
            ...
            added_pkt = true;
        } else break;
    }
    ...

    if (added_pkt)
        thread_add_event(bm->master, bgp_process_packet, peer, 0, &peer->t_process_packet);

    return 0;
}

当数据包读完后，bgpd会将其发送到主线程进行路由处理。在这里，bgpd会根据数据包的类型进行分发，其中路由更新的请求会交给bpg_update_receive来进行解析：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
// File: src/sonic-frr/frr/bgpd/bgp_packet.c
int bgp_process_packet(struct thread *thread)
{
    ...
    unsigned int processed = 0;
    while (processed < rpkt_quanta_old) {
        uint8_t type = 0;
        bgp_size_t size;
        ...

        /* read in the packet length and type */
        size = stream_getw(peer->curr);
        type = stream_getc(peer->curr);
        size -= BGP_HEADER_SIZE;

        switch (type) {
        case BGP_MSG_OPEN:
            ...
            break;
        case BGP_MSG_UPDATE:
            ...
            mprc = bgp_update_receive(peer, size);
            ...
            break;
        ...
}

// Process BGP UPDATE message for peer.
static int bgp_update_receive(struct peer *peer, bgp_size_t size)
{
    struct stream *s;
    struct attr attr;
    struct bgp_nlri nlris[NLRI_TYPE_MAX];
    ...

    // Parse attributes and NLRI
    memset(&attr, 0, sizeof(struct attr));
    attr.label_index = BGP_INVALID_LABEL_INDEX;
    attr.label = MPLS_INVALID_LABEL;
    ...

    memset(&nlris, 0, sizeof(nlris));
    ...

    if ((!update_len && !withdraw_len && nlris[NLRI_MP_UPDATE].length == 0)
        || (attr_parse_ret == BGP_ATTR_PARSE_EOR)) {
        // More parsing here
        ...

        if (afi && peer->afc[afi][safi]) {
            struct vrf *vrf = vrf_lookup_by_id(peer->bgp->vrf_id);

            /* End-of-RIB received */
            if (!CHECK_FLAG(peer->af_sflags[afi][safi], PEER_STATUS_EOR_RECEIVED)) {
                ...
                if (gr_info->eor_required == gr_info->eor_received) {
                    ...
                    /* Best path selection */
                    if (bgp_best_path_select_defer( peer->bgp, afi, safi) < 0)
                        return BGP_Stop;
                }
            }
            ...
        }
    }
    ...

    return Receive_UPDATE_message;
}

然后，bgpd会开始检查是否出现更优的路径，并更新自己的本地路由表（RIB，Routing Information Base）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
// File: src/sonic-frr/frr/bgpd/bgp_route.c
/* Process the routes with the flag BGP_NODE_SELECT_DEFER set */
int bgp_best_path_select_defer(struct bgp *bgp, afi_t afi, safi_t safi)
{
    struct bgp_dest *dest;
    int cnt = 0;
    struct afi_safi_info *thread_info;
    ...

    /* Process the route list */
    for (dest = bgp_table_top(bgp->rib[afi][safi]);
         dest && bgp->gr_info[afi][safi].gr_deferred != 0;
         dest = bgp_route_next(dest))
    {
        ...
        bgp_process_main_one(bgp, dest, afi, safi);
        ...
    }
    ...

    return 0;
}

static void bgp_process_main_one(struct bgp *bgp, struct bgp_dest *dest, afi_t afi, safi_t safi)
{
    struct bgp_path_info *new_select;
    struct bgp_path_info *old_select;
    struct bgp_path_info_pair old_and_new;
    ...

    const struct prefix *p = bgp_dest_get_prefix(dest);
    ...

    /* Best path selection. */
    bgp_best_selection(bgp, dest, &bgp->maxpaths[afi][safi], &old_and_new, afi, safi);
    old_select = old_and_new.old;
    new_select = old_and_new.new;
    ...

    /* FIB update. */
    if (bgp_fibupd_safi(safi) && (bgp->inst_type != BGP_INSTANCE_TYPE_VIEW)
        && !bgp_option_check(BGP_OPT_NO_FIB)) {

        if (new_select && new_select->type == ZEBRA_ROUTE_BGP
            && (new_select->sub_type == BGP_ROUTE_NORMAL
            || new_select->sub_type == BGP_ROUTE_AGGREGATE
            || new_select->sub_type == BGP_ROUTE_IMPORTED)) {
            ...

            if (old_select && is_route_parent_evpn(old_select))
                bgp_zebra_withdraw(p, old_select, bgp, safi);

            bgp_zebra_announce(dest, p, new_select, bgp, afi, safi);
        } else {
            /* Withdraw the route from the kernel. */
            ...
        }
    }

    /* EVPN route injection and clean up */
    ...

    UNSET_FLAG(dest->flags, BGP_NODE_PROCESS_SCHEDULED);
    return;
}

最后，bgp_zebra_announce会通过zclient通知zebra更新内核路由表。

1
2
3
4
5
6
// File: src/sonic-frr/frr/bgpd/bgp_zebra.c
void bgp_zebra_announce(struct bgp_node *rn, struct prefix *p, struct bgp_path_info *info, struct bgp *bgp, afi_t afi, safi_t safi)
{
    ...
    zclient_route_send(valid_nh_count ? ZEBRA_ROUTE_ADD : ZEBRA_ROUTE_DELETE, zclient, &api);
}

zclient使用本地socket与zebra通信，并且提供一系列的回调函数用于接收zebra的通知，核心代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// File: src/sonic-frr/frr/bgpd/bgp_zebra.c
void bgp_zebra_init(struct thread_master *master, unsigned short instance)
{
    zclient_num_connects = 0;

    /* Set default values. */
    zclient = zclient_new(master, &zclient_options_default);
    zclient_init(zclient, ZEBRA_ROUTE_BGP, 0, &bgpd_privs);
    zclient->zebra_connected = bgp_zebra_connected;
    zclient->router_id_update = bgp_router_id_update;
    zclient->interface_add = bgp_interface_add;
    zclient->interface_delete = bgp_interface_delete;
    zclient->interface_address_add = bgp_interface_address_add;
    ...
}

int zclient_socket_connect(struct zclient *zclient)
{
    int sock;
    int ret;

    sock = socket(zclient_addr.ss_family, SOCK_STREAM, 0);
    ...

    /* Connect to zebra. */
    ret = connect(sock, (struct sockaddr *)&zclient_addr, zclient_addr_len);
    ...

    zclient->sock = sock;
    return sock;
}

在bgpd容器中，我们可以在/run/frr目录下找到zebra通信使用的socket文件来进行简单的验证：

1
2
3
4
root@7260cx3:/run/frr# ls -l
total 12
...
srwx------ 1 frr frr    0 Jun 16 09:16 zserv.api

3.1.2. zebra更新路由表

由于FRR支持的路由协议很多，如果每个路由协议处理进程都单独的对内核进行操作则必然会产生冲突，很难协调合作，所以FRR使用一个单独的进程用于和所有的路由协议处理进程进行沟通，整合好信息之后统一的进行内核的路由表更新，这个进程就是zebra。

在zebra中，内核的更新发生在一个独立的数据面处理线程中：dplane_thread。所有的请求都会通过zclient发送给zebra，经过处理之后，最后转发给dplane_thread来处理，这样路由的处理就是有序的了，也就不会产生冲突了。

zebra启动时，会将所有的请求处理函数进行注册，当请求到来时，就可以根据请求的类型调用相应的处理函数了，核心代码如下：

1
2
3
4
5
6
7
8
9
10
11
// File: src/sonic-frr/frr/zebra/zapi_msg.c
void (*zserv_handlers[])(ZAPI_HANDLER_ARGS) = {
    [ZEBRA_ROUTER_ID_ADD] = zread_router_id_add,
    [ZEBRA_ROUTER_ID_DELETE] = zread_router_id_delete,
    [ZEBRA_INTERFACE_ADD] = zread_interface_add,
    [ZEBRA_INTERFACE_DELETE] = zread_interface_delete,
    [ZEBRA_ROUTE_ADD] = zread_route_add,
    [ZEBRA_ROUTE_DELETE] = zread_route_del,
    [ZEBRA_REDISTRIBUTE_ADD] = zebra_redistribute_add,
    [ZEBRA_REDISTRIBUTE_DELETE] = zebra_redistribute_delete,
    ...

我们这里拿添加路由zread_route_add作为例子，来继续分析后续的流程。从以下代码我们可以看到，当新的路由到来后，zebra会开始查看并更新自己内部的路由表：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
// File: src/sonic-frr/frr/zebra/zapi_msg.c
static void zread_route_add(ZAPI_HANDLER_ARGS)
{
    struct stream *s;
    struct route_entry *re;
    struct nexthop_group *ng = NULL;
    struct nhg_hash_entry nhe;
    ...

    // Decode zclient request
    s = msg;
    if (zapi_route_decode(s, &api) < 0) {
        return;
    }
    ...

    // Allocate new route entry.
    re = XCALLOC(MTYPE_RE, sizeof(struct route_entry));
    re->type = api.type;
    re->instance = api.instance;
    ...
 
    // Init nexthop entry, if we have an id, then add route.
    if (!re->nhe_id) {
        zebra_nhe_init(&nhe, afi, ng->nexthop);
        nhe.nhg.nexthop = ng->nexthop;
        nhe.backup_info = bnhg;
    }
    ret = rib_add_multipath_nhe(afi, api.safi, &api.prefix, src_p, re, &nhe);

    // Update stats. IPv6 is emitted here for simplicity.
    if (ret > 0) client->v4_route_add_cnt++;
    else if (ret < 0) client->v4_route_upd8_cnt++;
}

// File: src/sonic-frr/frr/zebra/zebra_rib.c
int rib_add_multipath_nhe(afi_t afi, safi_t safi, struct prefix *p,
              struct prefix_ipv6 *src_p, struct route_entry *re,
              struct nhg_hash_entry *re_nhe)
{
    struct nhg_hash_entry *nhe = NULL;
    struct route_table *table;
    struct route_node *rn;
    int ret = 0;
    ...

    /* Find table and nexthop entry */
    table = zebra_vrf_get_table_with_table_id(afi, safi, re->vrf_id, re->table);
    if (re->nhe_id > 0) nhe = zebra_nhg_lookup_id(re->nhe_id);
    else nhe = zebra_nhg_rib_find_nhe(re_nhe, afi);

    /* Attach the re to the nhe's nexthop group. */
    route_entry_update_nhe(re, nhe);

    /* Make it sure prefixlen is applied to the prefix. */
    /* Set default distance by route type. */
    ...

    /* Lookup route node.*/
    rn = srcdest_rnode_get(table, p, src_p);
    ...

    /* If this route is kernel/connected route, notify the dataplane to update kernel route table. */
    if (RIB_SYSTEM_ROUTE(re)) {
        dplane_sys_route_add(rn, re);
    }

    /* Link new re to node. */
    SET_FLAG(re->status, ROUTE_ENTRY_CHANGED);
    rib_addnode(rn, re, 1);

    /* Clean up */
    ...
    return ret;
}

rib_addnode会将这个路由添加请求转发给rib的处理线程，并由它顺序的进行处理：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
static void rib_addnode(struct route_node *rn, struct route_entry *re, int process)
{
    ...
    rib_link(rn, re, process);
}
static void rib_link(struct route_node *rn, struct route_entry *re, int process)
{
    rib_dest_t *dest = rib_dest_from_rnode(rn);
    if (!dest) dest = zebra_rib_create_dest(rn);
    re_list_add_head(&dest->routes, re);
    ...

    if (process) rib_queue_add(rn);
}

请求会来到RIB的处理线程：rib_process，并由它来进行进一步的选路，然后将最优的路由添加到zebra的内部路由表（RIB）中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
/* Core function for processing routing information base. */
static void rib_process(struct route_node *rn)
{
    struct route_entry *re;
    struct route_entry *next;
    struct route_entry *old_selected = NULL;
    struct route_entry *new_selected = NULL;
    struct route_entry *old_fib = NULL;
    struct route_entry *new_fib = NULL;
    struct route_entry *best = NULL;
    rib_dest_t *dest;
    ...

    dest = rib_dest_from_rnode(rn);
    old_fib = dest->selected_fib;
    ...

    /* Check every route entry and select the best route. */
    RNODE_FOREACH_RE_SAFE (rn, re, next) {
        ...

        if (CHECK_FLAG(re->flags, ZEBRA_FLAG_FIB_OVERRIDE)) {
            best = rib_choose_best(new_fib, re);
            if (new_fib && best != new_fib)
                UNSET_FLAG(new_fib->status, ROUTE_ENTRY_CHANGED);
            new_fib = best;
        } else {
            best = rib_choose_best(new_selected, re);
            if (new_selected && best != new_selected)
                UNSET_FLAG(new_selected->status, ROUTE_ENTRY_CHANGED);
            new_selected = best;
        }

        if (best != re)
            UNSET_FLAG(re->status, ROUTE_ENTRY_CHANGED);
    } /* RNODE_FOREACH_RE */
    ...

    /* Update fib according to selection results */
    if (new_fib && old_fib)
        rib_process_update_fib(zvrf, rn, old_fib, new_fib);
    else if (new_fib)
        rib_process_add_fib(zvrf, rn, new_fib);
    else if (old_fib)
        rib_process_del_fib(zvrf, rn, old_fib);

    /* Remove all RE entries queued for removal */
    /* Check if the dest can be deleted now.  */
    ...
}

对于新的路由，会调用rib_process_add_fib来将其添加到zebra的内部路由表中，然后通知dplane进行内核路由表的更新：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
static void rib_process_add_fib(struct zebra_vrf *zvrf, struct route_node *rn, struct route_entry *new)
{
    hook_call(rib_update, rn, "new route selected");
    ...

    /* If labeled-unicast route, install transit LSP. */
    if (zebra_rib_labeled_unicast(new))
        zebra_mpls_lsp_install(zvrf, rn, new);

    rib_install_kernel(rn, new, NULL);
    UNSET_FLAG(new->status, ROUTE_ENTRY_CHANGED);
}

void rib_install_kernel(struct route_node *rn, struct route_entry *re,
            struct route_entry *old)
{
    struct rib_table_info *info = srcdest_rnode_table_info(rn);
    enum zebra_dplane_result ret;
    rib_dest_t *dest = rib_dest_from_rnode(rn);
    ...

    /* Install the resolved nexthop object first. */
    zebra_nhg_install_kernel(re->nhe);

    /* If this is a replace to a new RE let the originator of the RE know that they've lost */
    if (old && (old != re) && (old->type != re->type))
        zsend_route_notify_owner(rn, old, ZAPI_ROUTE_BETTER_ADMIN_WON, info->afi, info->safi);

    /* Update fib selection */
    dest->selected_fib = re;

    /* Make sure we update the FPM any time we send new information to the kernel. */
    hook_call(rib_update, rn, "installing in kernel");

    /* Send add or update */
    if (old) ret = dplane_route_update(rn, re, old);
    else ret = dplane_route_add(rn, re);
    ...
}

这里有两个重要的操作，一个自然是调用dplane_route_*函数来进行内核的路由表更新，另一个则是出现了两次的hook_call，fpm的钩子函数就是挂在这个地方，用来接收并转发路由表的更新通知。这里我们一个一个来看：

3.1.2.1. dplane更新内核路由表

首先是dplane的dplane_route_*函数，它们的做的事情都一样：把请求打包，然后放入dplane_thread的消息队列中，并不会做任何实质的操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// File: src/sonic-frr/frr/zebra/zebra_dplane.c
enum zebra_dplane_result dplane_route_add(struct route_node *rn, struct route_entry *re) {
    return dplane_route_update_internal(rn, re, NULL, DPLANE_OP_ROUTE_INSTALL);
}

enum zebra_dplane_result dplane_route_update(struct route_node *rn, struct route_entry *re, struct route_entry *old_re) {
    return dplane_route_update_internal(rn, re, old_re, DPLANE_OP_ROUTE_UPDATE);
}

enum zebra_dplane_result dplane_sys_route_add(struct route_node *rn, struct route_entry *re) {
    return dplane_route_update_internal(rn, re, NULL, DPLANE_OP_SYS_ROUTE_ADD);
}

static enum zebra_dplane_result
dplane_route_update_internal(struct route_node *rn, struct route_entry *re, struct route_entry *old_re, enum dplane_op_e op)
{
    enum zebra_dplane_result result = ZEBRA_DPLANE_REQUEST_FAILURE;
    int ret = EINVAL;

    /* Create and init context */
    struct zebra_dplane_ctx *ctx = ...;

    /* Enqueue context for processing */
    ret = dplane_route_enqueue(ctx);

    /* Update counter */
    atomic_fetch_add_explicit(&zdplane_info.dg_routes_in, 1, memory_order_relaxed);

    if (ret == AOK)
        result = ZEBRA_DPLANE_REQUEST_QUEUED;

    return result;
}

然后，我们就来到了数据面处理线程dplane_thread，其消息循环很简单，就是从队列中一个个取出消息，然后通过调用其处理函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// File: src/sonic-frr/frr/zebra/zebra_dplane.c
static int dplane_thread_loop(struct thread *event)
{
    ...

    while (prov) {
        ...

        /* Process work here */
        (*prov->dp_fp)(prov);

        /* Check for zebra shutdown */
        /* Dequeue completed work from the provider */
        ...

        /* Locate next provider */
        DPLANE_LOCK();
        prov = TAILQ_NEXT(prov, dp_prov_link);
        DPLANE_UNLOCK();
    }
}

默认情况下，dplane_thread会使用kernel_dplane_process_func来进行消息的处理，内部会根据请求的类型对内核的操作进行分发：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
static int kernel_dplane_process_func(struct zebra_dplane_provider *prov)
{
    enum zebra_dplane_result res;
    struct zebra_dplane_ctx *ctx;
    int counter, limit;
    limit = dplane_provider_get_work_limit(prov);

    for (counter = 0; counter < limit; counter++) {
        ctx = dplane_provider_dequeue_in_ctx(prov);
        if (ctx == NULL) break;

        /* A previous provider plugin may have asked to skip the kernel update.  */
        if (dplane_ctx_is_skip_kernel(ctx)) {
            res = ZEBRA_DPLANE_REQUEST_SUCCESS;
            goto skip_one;
        }

        /* Dispatch to appropriate kernel-facing apis */
        switch (dplane_ctx_get_op(ctx)) {
        case DPLANE_OP_ROUTE_INSTALL:
        case DPLANE_OP_ROUTE_UPDATE:
        case DPLANE_OP_ROUTE_DELETE:
            res = kernel_dplane_route_update(ctx);
            break;
        ...
        }
        ...
    }
    ...
}

static enum zebra_dplane_result
kernel_dplane_route_update(struct zebra_dplane_ctx *ctx)
{
    enum zebra_dplane_result res;
    /* Call into the synchronous kernel-facing code here */
    res = kernel_route_update(ctx);
    return res;
}

而kernel_route_update则是真正的内核操作了，它会通过netlink来通知内核路由更新：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// File: src/sonic-frr/frr/zebra/rt_netlink.c
// Update or delete a prefix from the kernel, using info from a dataplane context.
enum zebra_dplane_result kernel_route_update(struct zebra_dplane_ctx *ctx)
{
    int cmd, ret;
    const struct prefix *p = dplane_ctx_get_dest(ctx);
    struct nexthop *nexthop;

    if (dplane_ctx_get_op(ctx) == DPLANE_OP_ROUTE_DELETE) {
        cmd = RTM_DELROUTE;
    } else if (dplane_ctx_get_op(ctx) == DPLANE_OP_ROUTE_INSTALL) {
        cmd = RTM_NEWROUTE;
    } else if (dplane_ctx_get_op(ctx) == DPLANE_OP_ROUTE_UPDATE) {
        cmd = RTM_NEWROUTE;
    }

    if (!RSYSTEM_ROUTE(dplane_ctx_get_type(ctx)))
        ret = netlink_route_multipath(cmd, ctx);
    ...

    return (ret == 0 ? ZEBRA_DPLANE_REQUEST_SUCCESS : ZEBRA_DPLANE_REQUEST_FAILURE);
}

// Routing table change via netlink interface, using a dataplane context object
static int netlink_route_multipath(int cmd, struct zebra_dplane_ctx *ctx)
{
    // Build netlink request.
    struct {
        struct nlmsghdr n;
        struct rtmsg r;
        char buf[NL_PKT_BUF_SIZE];
    } req;

    req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct rtmsg));
    req.n.nlmsg_flags = NLM_F_CREATE | NLM_F_REQUEST;
    ...

    /* Talk to netlink socket. */
    return netlink_talk_info(netlink_talk_filter, &req.n, dplane_ctx_get_ns(ctx), 0);
}
3.1.2.2. FPM路由更新转发

FPM（Forwarding Plane Manager）是FRR中用于通知其他进程路由变更的协议，其主要逻辑代码在src/sonic-frr/frr/zebra/zebra_fpm.c中。它默认有两套协议实现：protobuf和netlink，SONiC就是使用的是netlink协议。

上面我们已经提到，它通过钩子函数实现，监听RIB中的路由变化，并通过本地Socket转发给其他的进程。这个钩子会在启动的时候就注册好，其中和我们现在看的最相关的就是rib_update钩子了，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
static int zebra_fpm_module_init(void)
{
    hook_register(rib_update, zfpm_trigger_update);
    hook_register(zebra_rmac_update, zfpm_trigger_rmac_update);
    hook_register(frr_late_init, zfpm_init);
    hook_register(frr_early_fini, zfpm_fini);
    return 0;
}

FRR_MODULE_SETUP(.name = "zebra_fpm", .version = FRR_VERSION,
         .description = "zebra FPM (Forwarding Plane Manager) module",
         .init = zebra_fpm_module_init,
);

当rib_update钩子被调用时，zfpm_trigger_update函数会被调用，它会将路由变更信息再次放入fpm的转发队列中，并触发写操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
static int zfpm_trigger_update(struct route_node *rn, const char *reason)
{
    rib_dest_t *dest;
    ...

    // Queue the update request
    dest = rib_dest_from_rnode(rn);
    SET_FLAG(dest->flags, RIB_DEST_UPDATE_FPM);
    TAILQ_INSERT_TAIL(&zfpm_g->dest_q, dest, fpm_q_entries);
    ...

    zfpm_write_on();
    return 0;
}

static inline void zfpm_write_on(void) {
    thread_add_write(zfpm_g->master, zfpm_write_cb, 0, zfpm_g->sock, &zfpm_g->t_write);
}

这个写操作的回调就会将其从队列中取出，并转换成FPM的消息格式，然后通过本地Socket转发给其他进程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
static int zfpm_write_cb(struct thread *thread)
{
    struct stream *s;

    do {
        int bytes_to_write, bytes_written;
        s = zfpm_g->obuf;

        // Convert route info to buffer here.
        if (stream_empty(s)) zfpm_build_updates();

        // Write to socket until we don' have anything to write or cannot write anymore (partial write).
        bytes_to_write = stream_get_endp(s) - stream_get_getp(s);
        bytes_written = write(zfpm_g->sock, stream_pnt(s), bytes_to_write);
        ...
    } while (1);

    if (zfpm_writes_pending()) zfpm_write_on();
    return 0;
}

static void zfpm_build_updates(void)
{
    struct stream *s = zfpm_g->obuf;
    do {
        /* Stop processing the queues if zfpm_g->obuf is full or we do not have more updates to process */
        if (zfpm_build_mac_updates() == FPM_WRITE_STOP) break;
        if (zfpm_build_route_updates() == FPM_WRITE_STOP) break;
    } while (zfpm_updates_pending());
}

到此，FRR的工作就完成了。

4. 小结

我们这一篇大概总结了SONiC和BGP相关的进程，BGP命令的实现思路，和它是如何通过FRR实现BGP路由的。下次，我们会继续介绍SONiC中FRR之后的BGP变更工作流。

5. 参考资料

  1. SONiC Architecture
  2. Github repo: sonic-swss
  3. Github repo: sonic-swss-common
  4. Github repo: sonic-frr
  5. Github repo: sonic-utilities
  6. RFC 4271: A Border Gateway Protocol 4 (BGP-4)
  7. FRRouting
同系列文章：
原创文章，转载请标明出处：Soul Orbit
本文链接地址：SONiC学习笔记（六）：BGP工作流（上）—— 命令实现与FRR]]> <p><em>（以下内容已经整合进《SONiC入门指南》的 <a href="https://r12f.com/sonic-book/5-2-bgp-workflow.html">BGP工作流</a> ，<a href="https://r12f.com/sonic-book/5-2-1-bgp-command-impl.html">BGP命令实现</a>和<a href="https://r12f.com/sonic-book/5-2-2-bgp-route-update-workflow.html">BGP路由变更下发</a> 三节中。）</em></p> <p><a href="https://datatracker.ietf.org/doc/html/rfc4271">BGP</a>可能是交换机里面最常用，最重要，或者线上使用的最多的功能了。这一篇，我们就来深入的看一下BGP相关的工作流。</p> <h2 id="BGP相关进程">1. BGP相关进程</h2> <p>SONiC使用<a href="https://frrouting.org/">FRRouting</a>作为BGP的实现，用于负责BGP的协议处理。FRRouting是一个开源的路由软件，支持多种路由协议，包括BGP，OSPF，IS-IS，RIP，PIM，LDP等等。当FRR发布新版本后，SONiC会将其同步到<a href="https://github.com/sonic-net/sonic-frr">SONiC的FRR实现仓库：sonic-frr</a>中，每一个版本都对应这一个分支，比如<code>frr/8.2</code>。</p> <p>FRR主要由两个大部分组成，第一个部分是各个协议的实现，这些进程的名字都叫做<code>*d</code>，而当它们收到路由更新的通知的时候，就会告诉第二个部分，也就是<code>zebra</code>进程，然后<code>zebra</code>进程会进行选路，并将最优的路由信息同步到kernel中，其主体结构如下图所示：</p> <figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br></pre></td><td class="code"><pre><span class="line">+----+ +----+ +-----+ +----+ +----+ +----+ +-----+</span><br><span class="line">|bgpd| |ripd| |ospfd| |ldpd| |pbrd| |pimd| |.....|</span><br><span class="line">+----+ +----+ +-----+ +----+ +----+ +----+ +-----+</span><br><span class="line"> | | | | | | |</span><br><span class="line">+----v-------v--------v-------v-------v-------v--------v</span><br><span class="line">| |</span><br><span class="line">| Zebra |</span><br><span class="line">| |</span><br><span class="line">+------------------------------------------------------+</span><br><span class="line"> | | |</span><br><span class="line"> | | |</span><br><span class="line">+------v------+ +---------v--------+ +------v------+</span><br><span class="line">| | | | | |</span><br><span class="line">| *NIX Kernel | | Remote dataplane | | ........... |</span><br><span class="line">| | | | | |</span><br><span class="line">+-------------+ +------------------+ +-------------+</span><br></pre></td></tr></table></figure> SONiC学习笔记（五）：Syncd-SAI工作流 http://r12f.com/posts/sonic-5-syncd-sai-workflow/ 2023-06-25T20:39:48.000Z 2023-06-25T20:39:48.000Z （以下内容已经整合进《SONiC入门指南》的 SAI介绍 和 Syncd-SAI工作流 两节中。）

Syncd容器是SONiC中专门负责管理ASIC的容器，其中核心进程syncd负责与Redis数据库沟通，加载SAI并与其交互，以完成ASIC的初始化，配置和状态上报的处理等等。

由于SONiC中大量的工作流最后都需要通过Syncd和SAI来和ASIC进行交互，所以这一部分也就成为了这些工作流的公共部分，所以，在展开其他工作流之前，我们先来看一下Syncd和SAI是如何工作的。

1. Syncd启动流程

syncd进程的入口在syncd_main.cpp中的syncd_main函数，其启动的整体流程大致分为两部分。

第一部分是创建各个对象，并进行初始化：

sequenceDiagram    autonumber    participant SDM as syncd_main    participant SD as Syncd    participant SAI as VendorSai    SDM->>+SD: 调用构造函数    SD->>SD: 加载和解析命令行参数和配置文件    SD->>SD: 创建数据库相关对象，如：<br/>ASIC_DB Connector和FlexCounterManager    SD->>SD: 创建MDIO IPC服务器    SD->>SD: 创建SAI上报处理逻辑    SD->>SD: 创建RedisSelectableChannel用于接收Redis通知    SD->>-SAI: 初始化SAI

第二个部分是启动主循环，并且处理初始化事件：

sequenceDiagram    autonumber    participant SDM as syncd_main    participant SD as Syncd    participant SAI as VendorSai    participant NP as NotificationProcessor    participant MIS as MdioIpcServer    SDM->>+SD: 启动主线程循环    SD->>NP: 启动SAI上报处理线程    NP->>NP: 开始通知处理循环    SD->>MIS: 启动MDIO IPC服务器线程    MIS->>MIS: 开始MDIO IPC服务器事件循环    SD->>SD: 初始化并启动事件分发机制，开始主循环    loop 处理事件        alt 如果是创建Switch的事件或者是WarmBoot            SD->>SAI: 创建Switch对象，设置通知回调        else 如果是其他事件            SD->>SD: 处理事件        end    end    SD->>-SDM: 退出主循环返回

然后我们再从代码的角度来更加仔细的看一下这个流程。

1.1. syncd_main函数

syncd_main函数本身非常简单，主要逻辑就是创建Syncd对象，然后调用其run方法：

1
2
3
4
5
6
7
8
// File: src/sonic-sairedis/syncd/syncd_main.cpp
int syncd_main(int argc, char **argv)
{
    auto vendorSai = std::make_shared<VendorSai>();
    auto syncd = std::make_shared<Syncd>(vendorSai, commandLineOptions, isWarmStart);
    syncd->run();
    return EXIT_SUCCESS;
}

其中，Syncd对象的构造函数负责初始化Syncd中的各个功能，而run方法则负责启动Syncd的主循环。

1.2. Syncd构造函数

Syncd对象的构造函数负责创建或初始化Syncd中的各个功能，比如用于连接数据库的对象，统计管理，和ASIC通知的处理逻辑等等，其主要代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// File: src/sonic-sairedis/syncd/Syncd.cpp
Syncd::Syncd(
        _In_ std::shared_ptr<sairedis::SaiInterface> vendorSai,
        _In_ std::shared_ptr<CommandLineOptions> cmd,
        _In_ bool isWarmStart):
    m_vendorSai(vendorSai),
    ...
{
    ...

    // Load context config
    auto ccc = sairedis::ContextConfigContainer::loadFromFile(m_commandLineOptions->m_contextConfig.c_str());
    m_contextConfig = ccc->get(m_commandLineOptions->m_globalContext);
    ...

    // Create FlexCounter manager
    m_manager = std::make_shared<FlexCounterManager>(m_vendorSai, m_contextConfig->m_dbCounters);

    // Create DB related objects
    m_dbAsic = std::make_shared<swss::DBConnector>(m_contextConfig->m_dbAsic, 0);
    m_mdioIpcServer = std::make_shared<MdioIpcServer>(m_vendorSai, m_commandLineOptions->m_globalContext);
    m_selectableChannel = std::make_shared<sairedis::RedisSelectableChannel>(m_dbAsic, ASIC_STATE_TABLE, REDIS_TABLE_GETRESPONSE, TEMP_PREFIX, modifyRedis);

    // Create notification processor and handler
    m_notifications = std::make_shared<RedisNotificationProducer>(m_contextConfig->m_dbAsic);
    m_client = std::make_shared<RedisClient>(m_dbAsic);
    m_processor = std::make_shared<NotificationProcessor>(m_notifications, m_client, std::bind(&Syncd::syncProcessNotification, this, _1));

    m_handler = std::make_shared<NotificationHandler>(m_processor);
    m_sn.onFdbEvent = std::bind(&NotificationHandler::onFdbEvent, m_handler.get(), _1, _2);
    m_sn.onNatEvent = std::bind(&NotificationHandler::onNatEvent, m_handler.get(), _1, _2);
    // Init many other event handlers here
    m_handler->setSwitchNotifications(m_sn.getSwitchNotifications());
    ...

    // Initialize SAI
    sai_status_t status = vendorSai->initialize(0, &m_test_services);
    ...
}

1.3. SAI的初始化与VendorSai

为了有一个更加直观的理解，我们拿一小部分代码来展示一下SAI的接口定义和初始化的方法，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// File: meta/saimetadata.h
typedef struct _sai_apis_t {
    sai_switch_api_t* switch_api;
    sai_port_api_t* port_api;
    ...
} sai_apis_t;

// File: inc/saiswitch.h
typedef struct _sai_switch_api_t
{
    sai_create_switch_fn                   create_switch;
    sai_remove_switch_fn                   remove_switch;
    sai_set_switch_attribute_fn            set_switch_attribute;
    sai_get_switch_attribute_fn            get_switch_attribute;
    ...
} sai_switch_api_t;

// File: inc/saiport.h
typedef struct _sai_port_api_t
{
    sai_create_port_fn                     create_port;
    sai_remove_port_fn                     remove_port;
    sai_set_port_attribute_fn              set_port_attribute;
    sai_get_port_attribute_fn              get_port_attribute;
    ...
} sai_port_api_t;

其中，sai_apis_t结构体是SAI所有模块的接口的集合，其中每个成员都是一个特定模块的接口列表的指针。我们用sai_switch_api_t来举例，它定义了SAI Switch模块的所有接口，我们在inc/saiswitch.h中可以看到它的定义。同样的，我们在inc/saiport.h中可以看到SAI Port模块的接口定义。

SAI的初始化其实就是想办法获取上面这些函数指针，这样我们就可以通过SAI的接口来操作ASIC了。

参与SAI初始化的主要函数有两个，他们都定义在inc/sai.h中：

  • sai_api_initialize：初始化SAI
  • sai_api_query：传入SAI的API的类型，获取对应的接口列表

虽然大部分厂商的SAI实现是闭源的，但是mellanox却开源了自己的SAI实现，所以这里我们可以借助其更加深入的理解SAI是如何工作的。

比如，sai_api_initialize函数其实就是简单的设置设置两个全局变量，然后返回SAI_STATUS_SUCCESS：

1
2
3
4
5
6
7
8
9
10
11
12
// File: platform/mellanox/mlnx-sai/SAI-Implementation/mlnx_sai/src/mlnx_sai_interfacequery.c
sai_status_t sai_api_initialize(_In_ uint64_t flags, _In_ const sai_service_method_table_t* services)
{
    if (g_initialized) {
        return SAI_STATUS_FAILURE;
    }
    // Validate parameters here (code emitted)

    memcpy(&g_mlnx_services, services, sizeof(g_mlnx_services));
    g_initialized = true;
    return SAI_STATUS_SUCCESS;
}

初始化完成后，我们就可以使用sai_api_query函数，通过传入API的类型来查询对应的接口列表，而每一个接口列表其实都是一个全局变量：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// File: platform/mellanox/mlnx-sai/SAI-Implementation/mlnx_sai/src/mlnx_sai_interfacequery.c
sai_status_t sai_api_query(_In_ sai_api_t sai_api_id, _Out_ void** api_method_table)
{
    if (!g_initialized) {
        return SAI_STATUS_UNINITIALIZED;
    }
    ...

    return sai_api_query_eth(sai_api_id, api_method_table);
}

// File: platform/mellanox/mlnx-sai/SAI-Implementation/mlnx_sai/src/mlnx_sai_interfacequery_eth.c
sai_status_t sai_api_query_eth(_In_ sai_api_t sai_api_id, _Out_ void** api_method_table)
{
    switch (sai_api_id) {
    case SAI_API_BRIDGE:
        *(const sai_bridge_api_t**)api_method_table = &mlnx_bridge_api;
        return SAI_STATUS_SUCCESS;
    case SAI_API_SWITCH:
        *(const sai_switch_api_t**)api_method_table = &mlnx_switch_api;
        return SAI_STATUS_SUCCESS;
    ...
    default:
        if (sai_api_id >= (sai_api_t)SAI_API_EXTENSIONS_RANGE_END) {
            return SAI_STATUS_INVALID_PARAMETER;
        } else {
            return SAI_STATUS_NOT_IMPLEMENTED;
        }
    }
}

// File: platform/mellanox/mlnx-sai/SAI-Implementation/mlnx_sai/src/mlnx_sai_bridge.c
const sai_bridge_api_t mlnx_bridge_api = {
    mlnx_create_bridge,
    mlnx_remove_bridge,
    mlnx_set_bridge_attribute,
    mlnx_get_bridge_attribute,
    ...
};


// File: platform/mellanox/mlnx-sai/SAI-Implementation/mlnx_sai/src/mlnx_sai_switch.c
const sai_switch_api_t mlnx_switch_api = {
    mlnx_create_switch,
    mlnx_remove_switch,
    mlnx_set_switch_attribute,
    mlnx_get_switch_attribute,
    ...
};

Syncd使用VendorSai来对SAI的所有API进行封装，方便上层调用。其初始化过程也非常直接，基本就是对上面两个函数的直接调用和错误处理，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// File: src/sonic-sairedis/syncd/VendorSai.cpp
sai_status_t VendorSai::initialize(
        _In_ uint64_t flags,
        _In_ const sai_service_method_table_t *service_method_table)
{
    ...
    
    // Initialize SAI
    memcpy(&m_service_method_table, service_method_table, sizeof(m_service_method_table));
    auto status = sai_api_initialize(flags, service_method_table);

    // If SAI is initialized successfully, query all SAI API methods.
    // sai_metadata_api_query will also update all extern global sai_*_api variables, so we can also use
    // sai_metadata_get_object_type_info to get methods for a specific SAI object type.
    if (status == SAI_STATUS_SUCCESS) {
        memset(&m_apis, 0, sizeof(m_apis));
        int failed = sai_metadata_apis_query(sai_api_query, &m_apis);
        ...
    }
    ...

    return status;
}

当获取好所有的SAI API之后，我们就可以通过VendorSai对象来调用SAI的API了。当前调用SAI的API方式主要有两种。

第一种是通过sai_object_type_into_t来调用，它类似于为所有的SAI Object实现了一个虚表，如下：

1
2
3
4
5
6
7
8
9
10
11
12
// File: src/sonic-sairedis/syncd/VendorSai.cpp
sai_status_t VendorSai::set(
        _In_ sai_object_type_t objectType,
        _In_ sai_object_id_t objectId,
        _In_ const sai_attribute_t *attr)
{
    ...

    auto info = sai_metadata_get_object_type_info(objectType);
    sai_object_meta_key_t mk = { .objecttype = objectType, .objectkey = { .key = { .object_id = objectId } } };
    return info->set(&mk, attr);
}

另外一种是通过保存在VendorSai对象中的m_apis来调用，这种方式更加直接，但是调用前需要先根据SAI Object的类型来调用不同的API。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
sai_status_t VendorSai::getStatsExt(
        _In_ sai_object_type_t object_type,
        _In_ sai_object_id_t object_id,
        _In_ uint32_t number_of_counters,
        _In_ const sai_stat_id_t *counter_ids,
        _In_ sai_stats_mode_t mode,
        _Out_ uint64_t *counters)
{
    sai_status_t (*ptr)(
            _In_ sai_object_id_t port_id,
            _In_ uint32_t number_of_counters,
            _In_ const sai_stat_id_t *counter_ids,
            _In_ sai_stats_mode_t mode,
            _Out_ uint64_t *counters);

    switch ((int)object_type)
    {
        case SAI_OBJECT_TYPE_PORT:
            ptr = m_apis.port_api->get_port_stats_ext;
            break;
        case SAI_OBJECT_TYPE_ROUTER_INTERFACE:
            ptr = m_apis.router_interface_api->get_router_interface_stats_ext;
            break;
        case SAI_OBJECT_TYPE_POLICER:
            ptr = m_apis.policer_api->get_policer_stats_ext;
            break;
        ...

        default:
            SWSS_LOG_ERROR("not implemented, FIXME");
            return SAI_STATUS_FAILURE;
    }

    return ptr(object_id, number_of_counters, counter_ids, mode, counters);
}

可以明显看出，第一种调用方式代码要精炼和直观许多。

1.4. Syncd主循环

Syncd的主循环也是使用的SONiC中标准的事件分发机制：在启动时，Syncd会将所有用于事件处理的Selectable对象注册到用于获取事件的Select对象中，然后在主循环中调用Select的select方法，等待事件的发生。核心代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// File: src/sonic-sairedis/syncd/Syncd.cpp
void Syncd::run()
{
    volatile bool runMainLoop = true;
    std::shared_ptr<swss::Select> s = std::make_shared<swss::Select>();
    onSyncdStart(m_commandLineOptions->m_startType == SAI_START_TYPE_WARM_BOOT);

    // Start notification processing thread
    m_processor->startNotificationsProcessingThread();

    // Start MDIO threads
    for (auto& sw: m_switches) { m_mdioIpcServer->setSwitchId(sw.second->getRid()); }
    m_mdioIpcServer->startMdioThread();

    // Registering selectable for event polling
    s->addSelectable(m_selectableChannel.get());
    s->addSelectable(m_restartQuery.get());
    s->addSelectable(m_flexCounter.get());
    s->addSelectable(m_flexCounterGroup.get());

    // Main event loop
    while (runMainLoop)
    {
        swss::Selectable *sel = NULL;
        int result = s->select(&sel);

        ...
        if (sel == m_restartQuery.get()) {
            // Handling switch restart event and restart switch here.
        } else if (sel == m_flexCounter.get()) {
            processFlexCounterEvent(*(swss::ConsumerTable*)sel);
        } else if (sel == m_flexCounterGroup.get()) {
            processFlexCounterGroupEvent(*(swss::ConsumerTable*)sel);
        } else if (sel == m_selectableChannel.get()) {
            // Handle redis updates here.
            processEvent(*m_selectableChannel.get());
        } else {
            SWSS_LOG_ERROR("select failed: %d", result);
        }
        ...
    }
    ...
}

其中，m_selectableChannel就是主要负责处理Redis数据库中的事件的对象。它使用ProducerTable / ConsumerTable的方式与Redis数据库进行交互，所以，所有orchagent发送过来的操作都会以三元组的形式保存在Redis中的list中，等待Syncd的处理。其核心定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// File: src/sonic-sairedis/meta/RedisSelectableChannel.h
class RedisSelectableChannel: public SelectableChannel
{
    public:
        RedisSelectableChannel(
                _In_ std::shared_ptr<swss::DBConnector> dbAsic,
                _In_ const std::string& asicStateTable,
                _In_ const std::string& getResponseTable,
                _In_ const std::string& tempPrefix,
                _In_ bool modifyRedis);

    public: // SelectableChannel overrides
        virtual bool empty() override;
        ...

    public: // Selectable overrides
        virtual int getFd() override;
        virtual uint64_t readData() override;
        ...

    private:
        std::shared_ptr<swss::DBConnector> m_dbAsic;
        std::shared_ptr<swss::ConsumerTable> m_asicState;
        std::shared_ptr<swss::ProducerTable> m_getResponse;
        ...
};

另外，在主循环启动时，Syncd还会额外启动两个线程：

  • 用于接收ASIC上报通知的通知处理线程：m_processor->startNotificationsProcessingThread();
  • 用于处理MDIO通信的MDIO IPC处理线程：m_mdioIpcServer->startMdioThread();

它们的细节我们在初始化的部分不做过多展开，等后面介绍相关工作流时再来详细介绍。

1.5. 创建Switch对象，初始化通知机制

在主循环启动后，Syncd就会开始调用SAI的API来创建Switch对象，这里的入口有两个，一个是ASIC_DB收到创建Switch的通知，另外一个是Warm Boot时，Syncd来主动调用，但是创建Switch这一步的内部流程都类似。

在这一步中间，有一个很重要的步骤，就是初始化SAI内部实现中的通知回调，将我们之前已经创建好的通知处理逻辑传递给SAI的实现，比如FDB的事件等等。这些回调函数会被当做Switch的属性（Attributes）通过参数的形式传给SAI的create_switch方法，SAI的实现会将其保存起来，这样就可以在事件发生时调用回调函数，来通知Syncd了。这里的核心代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
// File: src/sonic-sairedis/syncd/Syncd.cpp
sai_status_t Syncd::processQuadEvent(
        _In_ sai_common_api_t api,
        _In_ const swss::KeyOpFieldsValuesTuple &kco)
{
    // Parse event into SAI object
    sai_object_meta_key_t metaKey;
    ...

    SaiAttributeList list(metaKey.objecttype, values, false);
    sai_attribute_t *attr_list = list.get_attr_list();
    uint32_t attr_count = list.get_attr_count();

    // Update notifications pointers in attribute list
    if (metaKey.objecttype == SAI_OBJECT_TYPE_SWITCH && (api == SAI_COMMON_API_CREATE || api == SAI_COMMON_API_SET))
    {
        m_handler->updateNotificationsPointers(attr_count, attr_list);
    }

    if (isInitViewMode())
    {
        // ProcessQuadEventInInitViewMode will eventually call into VendorSai, which calls create_swtich function in SAI.
        sai_status_t status = processQuadEventInInitViewMode(metaKey.objecttype, strObjectId, api, attr_count, attr_list);
        syncUpdateRedisQuadEvent(status, api, kco);
        return status;
    }
    ...
}

// File: src/sonic-sairedis/syncd/NotificationHandler.cpp
void NotificationHandler::updateNotificationsPointers(_In_ uint32_t attr_count, _In_ sai_attribute_t *attr_list) const
{
    for (uint32_t index = 0; index < attr_count; ++index) {
        ...

        sai_attribute_t &attr = attr_list[index];
        switch (attr.id) {
            ...

            case SAI_SWITCH_ATTR_SHUTDOWN_REQUEST_NOTIFY:
                attr.value.ptr = (void*)m_switchNotifications.on_switch_shutdown_request;
                break;

            case SAI_SWITCH_ATTR_FDB_EVENT_NOTIFY:
                attr.value.ptr = (void*)m_switchNotifications.on_fdb_event;
                break;
            ...
        }
        ...
    }
}

// File: src/sonic-sairedis/syncd/Syncd.cpp
// Call stack: processQuadEvent
//          -> processQuadEventInInitViewMode
//          -> processQuadInInitViewModeCreate
//          -> onSwitchCreateInInitViewMode
void Syncd::onSwitchCreateInInitViewMode(_In_ sai_object_id_t switchVid, _In_ uint32_t attr_count, _In_ const sai_attribute_t *attr_list)
{
    if (m_switches.find(switchVid) == m_switches.end()) {
        sai_object_id_t switchRid;
        sai_status_t status;
        status = m_vendorSai->create(SAI_OBJECT_TYPE_SWITCH, &switchRid, 0, attr_count, attr_list);
        ...

        m_switches[switchVid] = std::make_shared<SaiSwitch>(switchVid, switchRid, m_client, m_translator, m_vendorSai);
        m_mdioIpcServer->setSwitchId(switchRid);
        ...
    }
    ...
}

从Mellanox的SAI实现，我们可以看到其具体的保存的方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
static sai_status_t mlnx_create_switch(_Out_ sai_object_id_t     * switch_id,
                                       _In_ uint32_t               attr_count,
                                       _In_ const sai_attribute_t *attr_list)
{
    ...

    status = find_attrib_in_list(attr_count, attr_list, SAI_SWITCH_ATTR_SWITCH_STATE_CHANGE_NOTIFY, &attr_val, &attr_idx);
    if (!SAI_ERR(status)) {
        g_notification_callbacks.on_switch_state_change = (sai_switch_state_change_notification_fn)attr_val->ptr;
    }

    status = find_attrib_in_list(attr_count, attr_list, SAI_SWITCH_ATTR_SHUTDOWN_REQUEST_NOTIFY, &attr_val, &attr_idx);
    if (!SAI_ERR(status)) {
        g_notification_callbacks.on_switch_shutdown_request =
            (sai_switch_shutdown_request_notification_fn)attr_val->ptr;
    }

    status = find_attrib_in_list(attr_count, attr_list, SAI_SWITCH_ATTR_FDB_EVENT_NOTIFY, &attr_val, &attr_idx);
    if (!SAI_ERR(status)) {
        g_notification_callbacks.on_fdb_event = (sai_fdb_event_notification_fn)attr_val->ptr;
    }

    status = find_attrib_in_list(attr_count, attr_list, SAI_SWITCH_ATTR_PORT_STATE_CHANGE_NOTIFY, &attr_val, &attr_idx);
    if (!SAI_ERR(status)) {
        g_notification_callbacks.on_port_state_change = (sai_port_state_change_notification_fn)attr_val->ptr;
    }

    status = find_attrib_in_list(attr_count, attr_list, SAI_SWITCH_ATTR_PACKET_EVENT_NOTIFY, &attr_val, &attr_idx);
    if (!SAI_ERR(status)) {
        g_notification_callbacks.on_packet_event = (sai_packet_event_notification_fn)attr_val->ptr;
    }
    ...
}

2. ASIC状态更新

ASIC状态更新是Syncd中最重要的工作流之一，当orchagent发现任何变化并开始修改ASIC_DB时，就会触发该工作流，通过SAI来对ASIC进行更新。在了解了Syncd的主循环之后，理解ASIC状态更新的工作流就很简单了。

所有的步骤都发生在主线程一个线程中，顺序执行，总结成时序图如下：

sequenceDiagram    autonumber    participant SD as Syncd    participant RSC as RedisSelectableChannel    participant SAI as VendorSai    participant R as Redis    loop 主线程循环        SD->>RSC: 收到epoll通知，通知获取所有到来的消息        RSC->>R: 通过ConsumerTable获取所有到来的消息        critical 给Syncd加锁            loop 所有收到的消息                SD->>RSC: 获取一个消息                SD->>SD: 解析消息，获取操作类型和操作对象                SD->>SAI: 调用对应的SAI API，更新ASIC                SD->>RSC: 发送调用结果给Redis                RSC->>R: 将调用结果写入Redis            end        end    end

首先，orchagent通过Redis发送过来的操作会被RedisSelectableChannel对象接收，然后在主循环中被处理。当Syncd处理到m_selectableChannel时，就会调用processEvent方法来处理该操作。这几步的核心代码我们上面介绍主循环时已经介绍过了，这里就不再赘述。

然后，processEvent会根据其中的操作类型，调用对应的SAI的API来对ASIC进行更新。其逻辑是一个巨大的switch-case语句，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
// File: src/sonic-sairedis/syncd/Syncd.cpp
void Syncd::processEvent(_In_ sairedis::SelectableChannel& consumer)
{
    // Loop all operations in the queue
    std::lock_guard<std::mutex> lock(m_mutex);
    do {
        swss::KeyOpFieldsValuesTuple kco;
        consumer.pop(kco, isInitViewMode());
        processSingleEvent(kco);
    } while (!consumer.empty());
}

sai_status_t Syncd::processSingleEvent(_In_ const swss::KeyOpFieldsValuesTuple &kco)
{
    auto& op = kfvOp(kco);
    ...

    if (op == REDIS_ASIC_STATE_COMMAND_CREATE)
        return processQuadEvent(SAI_COMMON_API_CREATE, kco);

    if (op == REDIS_ASIC_STATE_COMMAND_REMOVE)
        return processQuadEvent(SAI_COMMON_API_REMOVE, kco);
    
    ...
}

sai_status_t Syncd::processQuadEvent(
        _In_ sai_common_api_t api,
        _In_ const swss::KeyOpFieldsValuesTuple &kco)
{
    // Parse operation
    const std::string& key = kfvKey(kco);
    const std::string& strObjectId = key.substr(key.find(":") + 1);

    sai_object_meta_key_t metaKey;
    sai_deserialize_object_meta_key(key, metaKey);

    auto& values = kfvFieldsValues(kco);
    SaiAttributeList list(metaKey.objecttype, values, false);
    sai_attribute_t *attr_list = list.get_attr_list();
    uint32_t attr_count = list.get_attr_count();
    ...

    auto info = sai_metadata_get_object_type_info(metaKey.objecttype);

    // Process the operation
    sai_status_t status;
    if (info->isnonobjectid) {
        status = processEntry(metaKey, api, attr_count, attr_list);
    } else {
        status = processOid(metaKey.objecttype, strObjectId, api, attr_count, attr_list);
    }

    // Send response
    if (api == SAI_COMMON_API_GET) {
        sai_object_id_t switchVid = VidManager::switchIdQuery(metaKey.objectkey.key.object_id);
        sendGetResponse(metaKey.objecttype, strObjectId, switchVid, status, attr_count, attr_list);
        ...
    } else {
        sendApiResponse(api, status);
    }

    syncUpdateRedisQuadEvent(status, api, kco);
    return status;
}

sai_status_t Syncd::processEntry(_In_ sai_object_meta_key_t metaKey, _In_ sai_common_api_t api,
                                 _In_ uint32_t attr_count, _In_ sai_attribute_t *attr_list)
{
    ...

    switch (api)
    {
        case SAI_COMMON_API_CREATE:
            return m_vendorSai->create(metaKey, SAI_NULL_OBJECT_ID, attr_count, attr_list);

        case SAI_COMMON_API_REMOVE:
            return m_vendorSai->remove(metaKey);
        ...

        default:
            SWSS_LOG_THROW("api %s not supported", sai_serialize_common_api(api).c_str());
    }
}

3. ASIC状态变更上报

反过来，当ASIC状态发生任何变化，或者需要上报数据，它也会通过SAI来通知我们，此时Syncd会监听这些通知，然后通过ASIC_DB上报给orchagent。其主要工作流如下：

sequenceDiagram    participant SAI as SAI Impl    participant NP as NotificationProcessor    participant SD as Syncd    participant RNP as RedisNotificationProducer    participant R as Redis    loop SAI实现事件处理线程        SAI->>SAI: 通过ASIC SDK获取事件        SAI->>SAI: 解析事件，并转换成SAI通知对象        SAI->>NP: 将通知对象序列化，<br/>并发送给通知处理线程的队列中    end    loop 通知处理线程消息循环        NP->>NP: 从队列中获取通知        NP->>SD: 获取Syncd锁        critical 给Syncd加锁            NP->>NP: 反序列化通知对象，并做一些处理            NP->>RNP: 重新序列化通知对象，并请求发送            RNP->>R: 将通知以NotificationProducer<br/>的形式写入ASIC_DB        end    end

这里我们也来看一下具体的实现。为了更加深入的理解，我们还是借助开源的Mellanox的SAI实现来进行分析。

最开始，SAI的实现需要接受到ASIC的通知，这一步是通过ASIC的SDK来实现的，Mellanox的SAI会创建一个事件处理线程（event_thread），然后使用select函数来获取并处理ASIC发送过来的通知，核心代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
// File: platform/mellanox/mlnx-sai/SAI-Implementation/mlnx_sai/src/mlnx_sai_switch.c
static void event_thread_func(void *context)
{
#define MAX_PACKET_SIZE MAX(g_resource_limits.port_mtu_max, SX_HOST_EVENT_BUFFER_SIZE_MAX)

    sx_status_t                         status;
    sx_api_handle_t                     api_handle;
    sx_user_channel_t                   port_channel, callback_channel;
    fd_set                              descr_set;
    int                                 ret_val;
    sai_object_id_t                     switch_id = (sai_object_id_t)context;
    sai_port_oper_status_notification_t port_data;
    sai_fdb_event_notification_data_t  *fdb_events = NULL;
    sai_attribute_t                    *attr_list = NULL;
    ...

    // Init SDK API
    if (SX_STATUS_SUCCESS != (status = sx_api_open(sai_log_cb, &api_handle))) {
        if (g_notification_callbacks.on_switch_shutdown_request) {
            g_notification_callbacks.on_switch_shutdown_request(switch_id);
        }
        return;
    }

    if (SX_STATUS_SUCCESS != (status = sx_api_host_ifc_open(api_handle, &port_channel.channel.fd))) {
        goto out;
    }
    ...

    // Register for port and channel notifications
    port_channel.type = SX_USER_CHANNEL_TYPE_FD;
    if (SX_STATUS_SUCCESS != (status = sx_api_host_ifc_trap_id_register_set(api_handle, SX_ACCESS_CMD_REGISTER, DEFAULT_ETH_SWID, SX_TRAP_ID_PUDE, &port_channel))) {
        goto out;
    }
    ...
    for (uint32_t ii = 0; ii < (sizeof(mlnx_trap_ids) / sizeof(*mlnx_trap_ids)); ii++) {
        status = sx_api_host_ifc_trap_id_register_set(api_handle, SX_ACCESS_CMD_REGISTER, DEFAULT_ETH_SWID, mlnx_trap_ids[ii], &callback_channel);
    }

    while (!event_thread_asked_to_stop) {
        FD_ZERO(&descr_set);
        FD_SET(port_channel.channel.fd.fd, &descr_set);
        FD_SET(callback_channel.channel.fd.fd, &descr_set);
        ...

        ret_val = select(FD_SETSIZE, &descr_set, NULL, NULL, &timeout);
        if (ret_val > 0) {
            // Port state change event
            if (FD_ISSET(port_channel.channel.fd.fd, &descr_set)) {
                // Parse port state event here ...
                if (g_notification_callbacks.on_port_state_change) {
                    g_notification_callbacks.on_port_state_change(1, &port_data);
                }
            }

            if (FD_ISSET(callback_channel.channel.fd.fd, &descr_set)) {
                // Receive notification event.
                packet_size = MAX_PACKET_SIZE;
                if (SX_STATUS_SUCCESS != (status = sx_lib_host_ifc_recv(&callback_channel.channel.fd, p_packet, &packet_size, receive_info))) {
                    goto out;
                }

                // BFD packet event
                if (SX_TRAP_ID_BFD_PACKET_EVENT == receive_info->trap_id) {
                    const struct bfd_packet_event *event = (const struct bfd_packet_event*)p_packet;
                    // Parse and check event valid here ...
                    status = mlnx_switch_bfd_packet_handle(event);
                    continue;
                }

                // Same way to handle BFD timeout event, Bulk counter ready event. Emiited.

                // FDB event and packet event handling
                if (receive_info->trap_id == SX_TRAP_ID_FDB_EVENT) {
                    trap_name = "FDB event";
                } else if (SAI_STATUS_SUCCESS != (status = mlnx_translate_sdk_trap_to_sai(receive_info->trap_id, &trap_name, &trap_oid))) {
                    continue;
                }

                if (SX_TRAP_ID_FDB_EVENT == receive_info->trap_id) {
                    // Parse FDB events here ...

                    if (g_notification_callbacks.on_fdb_event) {
                        g_notification_callbacks.on_fdb_event(event_count, fdb_events);
                    }

                    continue;
                }

                // Packet event handling
                status = mlnx_get_hostif_packet_data(receive_info, &attrs_num, callback_data);
                if (g_notification_callbacks.on_packet_event) {
                    g_notification_callbacks.on_packet_event(switch_id, packet_size, p_packet, attrs_num, callback_data);
                }
            }
        }
    }

out:
    ...
}

接下来，我们用FDB事件来举例，当ASIC收到FDB事件，就会被上面的事件处理循环获取到，并调用g_notification_callbacks.on_fdb_event函数来处理。这个函数接下来就会调用到Syncd初始化时设置好的NotificationHandler::onFdbEvent函数，这个函数会将该事件序列化后，通过消息队列转发给通知处理线程来进行处理：

1
2
3
4
5
6
// File: src/sonic-sairedis/syncd/NotificationHandler.cpp
void NotificationHandler::onFdbEvent(_In_ uint32_t count, _In_ const sai_fdb_event_notification_data_t *data)
{
    std::string s = sai_serialize_fdb_event_ntf(count, data);
    enqueueNotification(SAI_SWITCH_NOTIFICATION_NAME_FDB_EVENT, s);
}

而此时通知处理线程会被唤醒，从消息队列中取出该事件，然后通过Syncd获取到Syncd的锁，再开始处理该通知：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// File: src/sonic-sairedis/syncd/NotificationProcessor.cpp
void NotificationProcessor::ntf_process_function()
{
    std::mutex ntf_mutex;
    std::unique_lock<std::mutex> ulock(ntf_mutex);

    while (m_runThread) {
        // When notification arrives, it will signal this condition variable.
        m_cv.wait(ulock);

        // Process notifications in the queue.
        swss::KeyOpFieldsValuesTuple item;
        while (m_notificationQueue->tryDequeue(item)) {
            processNotification(item);
        }
    }
}

// File: src/sonic-sairedis/syncd/Syncd.cpp
// Call from NotificationProcessor::processNotification
void Syncd::syncProcessNotification(_In_ const swss::KeyOpFieldsValuesTuple& item)
{
    std::lock_guard<std::mutex> lock(m_mutex);
    m_processor->syncProcessNotification(item);
}

接下来就是事件的分发和处理了，syncProcessNotification函数是一系列的if-else语句，根据事件的类型，调用不同的处理函数来处理该事件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// File: src/sonic-sairedis/syncd/NotificationProcessor.cpp
void NotificationProcessor::syncProcessNotification( _In_ const swss::KeyOpFieldsValuesTuple& item)
{
    std::string notification = kfvKey(item);
    std::string data = kfvOp(item);

    if (notification == SAI_SWITCH_NOTIFICATION_NAME_SWITCH_STATE_CHANGE) {
        handle_switch_state_change(data);
    } else if (notification == SAI_SWITCH_NOTIFICATION_NAME_FDB_EVENT) {
        handle_fdb_event(data);
    } else if ...
    } else {
        SWSS_LOG_ERROR("unknown notification: %s", notification.c_str());
    }
}

而每个事件处理函数都类似，他们会对发送过来的事件进行反序列化，然后调用真正的处理逻辑发送通知，比如，fdb事件对应的handle_fdb_event函数和process_on_fdb_event：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// File: src/sonic-sairedis/syncd/NotificationProcessor.cpp
void NotificationProcessor::handle_fdb_event(_In_ const std::string &data)
{
    uint32_t count;
    sai_fdb_event_notification_data_t *fdbevent = NULL;
    sai_deserialize_fdb_event_ntf(data, count, &fdbevent);

    process_on_fdb_event(count, fdbevent);

    sai_deserialize_free_fdb_event_ntf(count, fdbevent);
}

void NotificationProcessor::process_on_fdb_event( _In_ uint32_t count, _In_ sai_fdb_event_notification_data_t *data)
{
    for (uint32_t i = 0; i < count; i++) {
        sai_fdb_event_notification_data_t *fdb = &data[i];
        // Check FDB event notification data here

        fdb->fdb_entry.switch_id = m_translator->translateRidToVid(fdb->fdb_entry.switch_id, SAI_NULL_OBJECT_ID);
        fdb->fdb_entry.bv_id = m_translator->translateRidToVid(fdb->fdb_entry.bv_id, fdb->fdb_entry.switch_id, true);
        m_translator->translateRidToVid(SAI_OBJECT_TYPE_FDB_ENTRY, fdb->fdb_entry.switch_id, fdb->attr_count, fdb->attr, true);

        ...
    }

    // Send notification
    std::string s = sai_serialize_fdb_event_ntf(count, data);
    sendNotification(SAI_SWITCH_NOTIFICATION_NAME_FDB_EVENT, s);
}

具体发送事件的逻辑就非常直接了，最终就是通过NotificationProducer来发送通知到ASIC_DB中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// File: src/sonic-sairedis/syncd/NotificationProcessor.cpp
void NotificationProcessor::sendNotification(_In_ const std::string& op, _In_ const std::string& data)
{
    std::vector<swss::FieldValueTuple> entry;
    sendNotification(op, data, entry);
}

void NotificationProcessor::sendNotification(_In_ const std::string& op, _In_ const std::string& data, _In_ std::vector<swss::FieldValueTuple> entry)
{
    m_notifications->send(op, data, entry);
}

// File: src/sonic-sairedis/syncd/RedisNotificationProducer.cpp
void RedisNotificationProducer::send(_In_ const std::string& op, _In_ const std::string& data, _In_ const std::vector<swss::FieldValueTuple>& values)
{
    std::vector<swss::FieldValueTuple> vals = values;

    // The m_notificationProducer is created in the ctor of RedisNotificationProducer as below:
    // m_notificationProducer = std::make_shared<swss::NotificationProducer>(m_db.get(), REDIS_TABLE_NOTIFICATIONS_PER_DB(dbName));
    m_notificationProducer->send(op, data, vals);
}

到此，Syncd中的通知上报的流程就结束了。

4. 参考资料

  1. SONiC Architecture
  2. Github repo: sonic-sairedis
  3. Github repo: Nvidia (Mellanox) SAI implementation
同系列文章：
原创文章，转载请标明出处：Soul Orbit
本文链接地址：SONiC学习笔记（五）：Syncd-SAI工作流]]> <p><em>（以下内容已经整合进《SONiC入门指南》的 <a href="https://r12f.com/sonic-book/2-4-sai-intro.html">SAI介绍</a> 和 <a href="https://r12f.com/sonic-book/5-1-syncd-sai-workflow.html">Syncd-SAI工作流</a> 两节中。）</em></p> <p><a href="/posts/sonic-2-key-components/#ASIC%E7%AE%A1%E7%90%86%E5%AE%B9%E5%99%A8%EF%BC%9Asyncd">Syncd容器</a>是SONiC中专门负责管理ASIC的容器，其中核心进程<code>syncd</code>负责与Redis数据库沟通，加载SAI并与其交互，以完成ASIC的初始化，配置和状态上报的处理等等。</p> <p>由于SONiC中大量的工作流最后都需要通过Syncd和SAI来和ASIC进行交互，所以这一部分也就成为了这些工作流的公共部分，所以，在展开其他工作流之前，我们先来看一下Syncd和SAI是如何工作的。</p> PCIe（四）—— 物理层 http://r12f.com/posts/pcie-4-phy/ 2023-05-30T06:27:24.000Z 2023-05-30T13:27:24.000Z 在看完事务层和数据链路层之后，我们来继续我们的协议栈之旅吧！这一篇中，我们会来看看PCIe物理层（Physical Layer）是如何工作的，从而帮助我们更加深入的了解PCIe的数据传输。

1. 物理层（Physical Layer）

当数据链路层将上层数据封装好后，就会将其交给物理层进行传输。而物理层的主要目的将数据转换为易于介质传输的电信号，并发送出去，或者将接收到的转换后的信号，转变为上层能处理的数据包。其主要结构如下：

物理层主要分为两个子块：

  • 逻辑子块（Logical Sub-Block）：逻辑子块负责编码和解码数据，以及处理时钟恢复和同步。它将数据链路层发送过来的数据进行编码后发送到电气子块。在接收方向，逻辑子块将电气子块接收的编码数据进行解码，恢复原始的数据，并送入数据链路层进行后续处理。此外，逻辑子块还处理与时钟恢复和数据流的对齐和同步相关的任务。
  • 电气子块（Electrical Sub-Block）：电气子块负责实际的数据传输。它将逻辑子块编码的数据转换为电信号，并通过物理链路发送出去。在接收方向，电气子块将接收到的电信号转换回编码数据，并发送给逻辑子块。电气子块还负责处理物理链路的一些特性，如电平调整，差分信号传输，以及其他与物理链路的电气特性相关的任务。

我们这里可以看到，物理层做的事情其实非常的多。如果你和我一样，以前主要做软件的小伙伴，也许会感觉到有些惊讶。不过没有关系，要理解物理层做的事情，关键是理解它们的目的。PCIe的信号特点是：高频和短距，而这些事情都是为了帮助我们稳定的传输这样的信号而设计的，其设计目标主要有：

  • DC均衡（DC-Balanced）：DC均衡是指在传输的数据中，0和1的数量是相等的。这样做的目的是为了保证信号的稳定传输，因为如果0和1的数量不相等，那么信号的电平就会有一个偏移，这样会导致信号的稳定性变差。
  • 稳定的高频传输：避免常见的高频信号传输问题，比如电平上行下行的速度过慢导致信号变形，传输线路问题导致的信号速率抖动（Jitter），连续的相同的bit导致电信号无法正常的通过滤波器，等等。
  • 最小化EMI（Electromagnetic Interference）：尽量避免高频信号中重复的数据模式产生EMI干扰其他的线路，也要避免其他电磁辐射源对自己的传输线路的干扰，导致信号失真。

这里，我们就来逐个的看看物理层的设计吧！

物理层还会负责一些其他的工作，比如：链路（Link）初始化，传输速率协商（Data Rate Negotiation）等等等等。这些内容由于和我们的主线 —— 数据传输的关系不大，所以我们就不在这里展开了，有兴趣的小伙伴可以自行查阅相关资料。

2. 链路（Link）和通道（Lane）

在了解物理层的具体内容之前，我们先来看看PCIe物理上到底长什么样子，还有它链路（Link）和通道（Lane）的概念。

PCIe的插槽想必大家都不陌生，在主板上都见过，最短的是PCIe x1，很少用到，最长的是PCIe x16，可以用来插显卡，另外其实还有x32的插槽，但是仅仅在大型服务器上才会使用。如下图： [7]

对于一个多通道（Lane）的PCIe设备而言，比如16通道（x16），虽然通道是多个，但是这些通道是连向同一个设备的，所以链路（Link）只有一个。在传输数据时，PCIe会将数据分配给所有通道并行传输，但是每个通道内部的数据传输是串行的，而接收方会将所有通道的数据最后重新汇总在一起，这样就利用了并行的多通道（Lane）建立起了一个串行的通信链路（Link）。

另外，我们知道短的PCIe设备还可以插在长的PCIe插槽中使用，这个扩展的魔法也是来源于PCIe中通道（Lane）的设计。PCIe接口的Pin分为两个部分：公共部分和数据传输通道。前着和后者会有一个小挡板隔开，这个叫做Mechanical Key，一般就简单叫做Key。我们在PCIe接口的Pinout中可以看到它具体的实现： [6]

其中，key之前的是公共部分，不管是x1还是x16，都一样。它包括很多功能，比如：大量的12v和3.3v的电压输入和接地，用于避免一根金手指电流过载，JTAG调试接口，SMBus用于设备信息上报，比如传感器，以及WAKE#用于唤醒设备和PREST#用于重置设备等等。

而key之后就是数据通道了，其中包括了接地，时钟，发送通道，接收通道，和热插拔检测引脚。而每个功能引脚两侧都是接地，这样可以帮助我们保持信号干净，减少EMI。而我们x1到x16可以扩展的魔法其实非常简单：x1和x16的区别仅仅在于，x16会把x1的所有的引脚重复16次，仅此而已。这样，物理层通过对通道的检测，就可以用x16的插槽适配比它小的任何设备了。

好了，了解了PCIe的物理接口，我们就可以来看PCIe物理层的具体设计了。

3. 逻辑子块（Logical Sub-Block）

我们还是跟随着数据发送的脚步，来看看物理层的设计。当数据链路层将打包好的数据传下来之后，首先到达的就是逻辑子块（Logical Sub-Block）了，在这里，我们会对数据进行一些处理，比如：打乱（Scrambling），编码（Encoding），以及插入控制字符（Control Character）等等。

首先，由于一个链路（Link）中可能存在多个通道（Lane），所以我们需要将一个Link中的数据预先分配到多个通道中去。这里，物理层会将数据根据链路（Link）上通道的数量，将数据按字节分配给各个通道，然后再将其转化为串行的Bits，交给之后的逻辑进行处理和发送。

自然的，接收方则相反，当所有的数据处理完成之后，需要将每个通道（Lane）中的数据合并成一个链路（Link）上去，再交给数据链路层进行处理。

3.2. 数据加扰（Data Scrambling）

首先，物理层会将接收到的数据进行加扰（Scrambling），让原本规整的数据流看上去像是随机数一样（所以有时候又把这个称为伪随机数生成：pseudo-random number generator）。

这样做的目的是为了避免信号的能量聚集在某些特殊的频段上，从而减少EMI。原理是这样：我们传输的数据其实是大量高频的0和1，而由于传输的数据可能是类似的，所以会形成特定高频的01变化的模式。了解傅里叶变换的小伙伴知道，任何周期信号都可以表示为一系列成谐波关系的正弦信号的叠加。这样分解之后，这种特定形状的高频信号，就会在特定的频率上产生能量集中的电磁波，导致干扰。而加扰（Scrambling）就是为了避免这种特定形状的信号出现，从而避免这种情况的发生。

而PCIe使用了一种非常聪明的方法进行数据加扰 —— 利用XOR运算！也就是线性反馈移位寄存器（LFSR，Linear-feedback shift register） [8]。其结构如下：

PCIe使用的是伽罗瓦（Galois）式LFSR，其中PCIe 1.0和2.0使用的是16位的LFSR的多项式表达为：

$$ G(X) = X^{16} + X^5 + X^4 + X^3 + 1 $$

而3.0开始之后，使用的是更长的23位LFSR，表达为：

$$ G(X) = X^{23} + X^{21} + X^{16} + X^8 + X^5 + X^2 + 1 $$

其计算方法用动画表示如下：

这样，每一次时钟，LFSR就会产生一个伪随机的bit，然后我们用这个bit和数据再进行一次XOR运算，就可以达到数据加扰的目的了。

另外，PCIe1.0和2.0中，数据加扰用的LFSR的初始值（Seed）都是0xFFFF，但是在PCIe3.0之后，为了避免不同的Lane上出现相似的数据，每条Lane上的LFSR的初始值（Seed）都不一样（大于等于8的Lane ID需要对8取模）：

LaneSeed
01DBFBCh
10607BBh
21EC760h
318C0DBh
4010F12h
519CFC9h
60277CEh
71BB807h

这个方法聪明的地方在于，通过XOR产生的伪随机数是可以恢复的！因为只要操作数一样，两次XOR操作的效果会被抵消，所以只要发送方和接收方的Seed一样，那么接收方就可以通过执行完全一样的LFSR操作，来恢复出原始的数据。

最后，为了方便我们用示波器调试，数据加扰是可以被关闭的。

3.3. Encoding

在打乱数据之后，接下来就是对数据进行编码（Encoding）了。编码的目的是保证传输的0和1的数量尽可能的一致，从而保持DC平衡（DC Balance），让数据的传输更加可靠，也能帮助PCIe从数据信号中恢复时钟（Clock Recovery）。

PCIe使用的编码方式有三种：8b/10b编码，128b/130b编码和242B/256B FLIT编码。而一旦知道了编码方式和PCIe的总线时钟频率，我们就可以算出来每条Lane的传输速率了。用PCIe 1.0 8b/10b来举例子，这个代表8bit的数据会被编码为10b的数据进行传输，所以，最后每条Lane的传输速率就是：

$$ Throughput = \frac{TransferRate \times EffectivePayloadPercentage}{8bits} = \frac{2.5GT/s \times \frac{8bits}{10bits}}{8bits} = 250MB/s $$

以下是PCIe各个版本的编码方式和传输速率：

PCIe VersionLine codeTransfer rate per laneThroughput x1Throughput x16
1.08b/10b2.5 GT/s250 MB/s4 GB/s
2.08b/10b5 GT/s500 MB/s8 GB/s
3.0128b/130b8 GT/s984.6 MB/s15.75 GB/s
4.0128b/130b16 GT/s1.969 GB/s31.51 GB/s
5.0128b/130b32 GT/s3.938 GB/s63.02 GB/s
6.01b/1b 242B/256B FLIT64 GT/s7.564 GB/s121.00 GB/s

注意：242B/256B是大写的B，不再是bit而是Byte了。

3.3.1. 8b/10b编码

8b/10b编码主要用在PCIe 1.0和2.0中，为2.5GT/s和5GT/s的传输频率提供数据编码 [4]。它的核心思想是，将一个8bits的数据拆分成一个5bits的数据和一个3bits的数据，然后分别通过一个固定的关系映射到6bits和4bits的中空间中去，从而避免连续的0或者1的出现。如下：ABCDEFGH被拆分成ABCDE和FGH，然后转换为小端，再分别映射到abcdei和fghj中去。

转换后的8b/10b编码有两种类型的值：控制码（K）和数据码（D），根据数据ABCDE和FGH的分组，被记为D.<ABCDE>.<FGH>或者K.<ABCDE>.<FGH>。其具体的映射方式如下：[4]

这里**RD（Running Disparity）**代表着当前字节开始前，前面的数据流中1的数量减去0的数量的差值。为了保证精确的01数量一致，8b/10b编码会使用这个值对当前字节的编码进行调整。这样它就能保证在传输每个字节之前，RD的值不会超过$\pm1$，在传输数据过程中，RD的值不会超过$\pm2$。

由于硬编码的原因，8b/10b编码可以精确的01数量一致，从而达到稳定的保持DC平衡，但是它的问题在于编码设计复杂，而且编码的效率有高达20%的浪费！这也是为什么PCIe 3.0之后，就不再使用8b/10b编码的原因。

3.3.2. 128b/130b编码

PCIe 3.0之后，为了提高编码效率从而提升有效带宽，PCIe开始使用128b/130b编码。可以看到由于每130个bits中间，只有2个bits是浪费的，所以它的效率高达98.46%！

128b/130b编码是64b/66b编码的变形 [5]，唯一的区别是将其payload的部分扩大了一倍（64b -> 128b）。它和8b/10b最大的不同在于它不再使用硬编码表进行转换了，而是依赖于上面我们提到的3.0之后的LFSR算法来进行转换，从而生成一个统计意义上的DC平衡的数据流。

除了使用LFSR算法进行数据处理以外，在编码的时候，128b/130b编码会做两件事情：Framing和Encoding。

3.3.2.1. Framing

首先，128b/130b编码会将整个上层的包（不是一个block）的之前和之后加上特定的标识用的Token，用来表示这个包的开始：

  • 对于TLP而言，它会在前面增加一个2字节的头，并且复写数据链路层的前4个bits，将其修改为FCRC，从而和已有的数据链路层的Seq一起组成一个4字节的token —— STP（Start of TLP）。

  • 对于DLLP而言，它会用一个2字节的Token - SDP（Start of DLLP）表示开始。

这两个Token会被永远从Lane 0开始，并作为一个数据包的开头（Byte 0）。另外，除此以外，还有用来标记空闲的IDL（Logical Idle），Nullify之前TLP的EDB（EnD Bad），和标记数据流结束的EDS（End of Data Stream）。

3.3.2.2. Encoding

然后，128b/130b编码会将整个数据包分为大小为128bit的block，然后在每个128bits的payload之前，加上一个2bits的同步头（SyncHeader），用来表示这个payload的类型并且做多通道同步。这个同步头的值有两种：

  • 01b：表示这个payload是数据块（Data Block），长度为128bits
  • 10b：表示这个payload是Ordered Set Block，长度也为128bits

比如，我们假设需要在一个通道上传输一个数据块，总共16个字节，S0-S15，其中最低位的bit我们记作.0，最高位记作.7，那么传输序列如下（注意同步头也会被转位小端发送，所以01b会变成10b）：

当有多条通道的时候，发送的时候数据将被分配到多个通道上同时发送，并且时钟对齐的：

这里有一个8通道上传输TLP和DLLP的例子，最后的传输效果如下：

3.3.3. 242B/256B FLIT编码

虽然128b/130b的编码很好，但是随着对速率的要求变得更高，PCIe6.0更换了从PCIe1.0一致沿用下来的NRZ（Non-Return-To-Zero）信号调制方式，而是转而使用了PAM4（Pulse Amplitude Modulation 4）信号调制方式。这种调制方式可以在同样的信号频率下，提供双倍的传输速率（下面会详细说）。然而这样的调制方式，也让错误率变得更高，所以PCIe6.0开始，PCIe使用了242B/256B FLIT编码，加入更多的校验机制，来提高信号的可靠性。

242B/256B FLIT编码的传输单位是一个FLIT，大小为256个字节（不是bits）。结构如下：

其中没有包头，从报文开始，前236个字节是TLP数据，然后是6个字节的DLLP（Data Link Layer Packet），8个字节的CRC，最后是6个字节的FEC（Forward Error Correction）。由于FLIT中已经带有CRC了，所以DLLP和TLP中是没有CRC的。传输后如果发现问题，就会尝试使用FEC进行修正（单字节），如果不行，就会对整个FLIT进行重传。

另外，一旦开启了FLIT模式，PCIe就会一直使用FLIT模式，即使速率降低到NRZ的速率（比如2.5 GT/s，5.0 GT/s，8.0 GT/s，16.0 GT/s，32.0 GT/s）也不会转换回NRZ模式了。

4. 电气子块（Electrical Sub-block）

到这里，我们的数据就可以发给下一个模块，进行真正的电信号传输准备了，这个模块就是电气子块（Electrical Sub-block）。

4.1. 并行转串行（P2S，Parallel to Serial）

首先，由于我们最后的信号是串行的，而逻辑子块上传下来的数据是是一个一个的字节（单通道），所以需要将按字节的并行信号转变为最后的串行信号（Parallel to Serial），再进行发送。

自然的，接收方则相反，最后当所有的数据处理完成之后，需要将串行的数据重新转化为并行的数据，交给数据链路层进行处理。

4.2. 调制（Modulation）

接下来转换为串行的数据需要经过调制，将其变为易于传输的电信号，而接收方则需要将电信号重新解调，转换会数字信号。

4.2.1. NRZ编码（Non-Return-to-Zero）

在PCIe1.0到5.0中，PCIe一直使用的调制方法叫做不归零码（NRZ，Non-Return-to-Zero） [10]。这种调制方式特点是与归零码（RZ，Return-to-Zero）相比，它的每个比特1会占满整个时钟周期，不会在后半个周期归零。PCIe使用的是中的两极不归零码（Bipolar NRZ level），它的编码方法很简单，就是将0变为负电平$-V$，1变为正电平$+V$，其电平图和眼图如下：

由于不归零码本身没有稳定的机制传递时钟，所以需要上面提到的编码（Encoding），加扰（Scrambling）和其他方式来进行辅助时钟恢复，这个我们下面会提到。

4.2.2. PAM4编码

为了支持更高的传输速率，PCIe6.0开始使用PAM4（Pulse Amplitude Modulation 4）调制方式，即脉冲幅度调制，将00变为$-V$，10变为$+V$，01变为$-V/3$，11变为$+V/3$，其眼图与每个电平表示的信号如下：

这样在同样的电压下，容纳的状态就变成了之前的两倍，所以在同样的时钟下，传输速率也就变成了之前的两倍！但是这样也就导致了更高概率的误码。

4.3. 预加重（Pre-emphasis）

接着，为了对抗传输介质导致的信号问题，为了能更清晰的传递高频的信号，经过调制的信号，将会经过预加重（Pre-emphasis）处理。即在发送端，对高频信号中的产生变化的第一个信号进行加强，从而让信号能更快的产生变化，保证高频信号的稳定。具体的操作很直观，如下图：[11]

当然，为了避免预加重导致的信号变形，在接收方也要进行去加重（De-emphasis）。

4.4. 差分信号（Differential Signal）

再接下来，再最后发送给真正的电路前，为了对抗电磁辐射等等原因导致的干扰，PCIe使用了差分信号（Differential Signaling）的方式进行传输。即将信号分为正负两个信号，然后在接收端，将两个信号相减，重新得到原始信号（这就是在Pinout中，我们看到的Differential Pair）。

我们假设原始信号中的电压为$V_{Tx}$，经过差分处理的两路信号为$+\frac{V_{Tx}}{2}$和$-\frac{V_{Tx}}{2}$，干扰导致的电压变化为$\Delta{V_{noise}}$，那么忽略传输的损耗，在接收端收到的电压就是：

$$ V_{Rx} = (+\frac{V_{Tx}}{2} + \Delta{V_{noise}}) - (-\frac{V_{Tx}}{2} + \Delta{V_{noise}}) = V_{Tx} $$

这样，通过差分信号，我们就抵消了信道上的干扰。

4.5. 时钟和信号恢复

除了上面的功能之外，在接收方，想获得干净的信号，我们还需要做两件事情：

  • 时钟恢复（Clock Recovery）：虽然PCIe的数据通道Pinout中是可以看到时钟信号REFCLK的，但是这个时钟信号传递的时钟仅仅是一个基础频率，一般在100MHz，而数据发送的频率从PCIe 1.0就已经达到了2.5GHz了，所以PCIe的接收方需要将REFCLK的时钟和数据中的01变化结合，将真正的时钟信号恢复出来。这也是为什么PCIe的数据需要进行编码的另一个原因之一 —— 用稳定的01变化帮助我们恢复稳定的时钟。

  • Retimer：由于PCIe的信号传输可能会有很多的干扰，导致信号的抖动（Jitter），所以在接收方，为了避免抖动的产生，我们还需要加入Retimer，对信号进行重新整形，保证信号的稳定。[13]

5. 物理层小结

好的，到这里，物理层里面和数据传输相关的内容就基本总结完了。我们可以看到，当数据链路层发过来一个包，物理层需要经过相当多的步骤才会将其真正发到外部电路中去，以保证其信号的稳定。

当然，物理层里面还有一些其他的功能，比如启动时对链路的初始化，使用Ordered Set对速率的自适应，Lane-to-Lane deskew等等，但是这些功能和我们的数据传输不是直接相关的，我们这里就跳过了，有兴趣的小伙伴可以去查阅PCIe的规范文档，里面有很详细的描述。[1]

这里，我们也把PCIe各个版本的主要参数再次总结一下，方便大家查阅：

PCIe VersionModulationLine codeTransfer rate per laneThroughput x1Throughput x16
1.0NRZ8b/10b2.5 GT/s250 MB/s4 GB/s
2.0NRZ8b/10b5 GT/s500 MB/s8 GB/s
3.0NRZ128b/130b8 GT/s984.6 MB/s15.75 GB/s
4.0NRZ128b/130b16 GT/s1.969 GB/s31.51 GB/s
5.0NRZ128b/130b32 GT/s3.938 GB/s63.02 GB/s
6.0PAM-41b/1b 242B/256B FLIT64 GT/s / 32 GBd7.564 GB/s121.00 GB/s

最后，我们依然用Intel Cyclone 10的物理层架构图作为最后的总结，大家可以对照着上面我们提到的各个子模块的内容来服用，如下：[9]

6. 小结

好的，到这里我们已经看完了整个PCIe的协议栈，相信大家已经对其有了一定的了解。最后，我们来举一个栗子，将整个协议栈串起来，看看一个PCIe的请求到底是怎么被发送的吧！

我们这里依然使用一个内存事务（Memory Transaction）来举例子：

  • 首先，CPU发起一个内存读请求，需要读取4字节内存
  • 内存控制器收到该请求后发现其不在DRAM空间中，于是转交给PCIe Root Complex
  • Root Complex检查其主桥（Host Bridge）配置空间的信息，确认地址在其连接的设备的内存空间内，开始创建数据包
  • Root Complex使用其地址构造读内存的内存事务的TLP，长度3DW，设置好各个字段：Fmt = 0，Type = 0，RequesterID = 0（表示Root Complex），和Length = 1（单位为DW），另外，根据规则设置好TC用于流控，我们这里使用默认值0
  • TLP构造完毕后会将TC（Traffic Class）映射到VC（Virtual Channel），从根据数据链路层中上报上来的每个VC中每种TLP的信用额度，进行流控，如果没有问题，则会将事务层发送给数据链路层
  • 数据链路层收到TLP后，会为其分配一个唯一的12bits的序列号，然后加上一个2字节的包含该序列号的报头，然后计算包括新报头和TLP报文的4字节CRC，将其放在包尾，交给物理层处理
  • 现在进入物理层的逻辑子块（Logical Sub-block），如果需要，物理层会其进行再次封包（framing），在报文前加上两字节STP token，并再次计算FCRC，将其写入数据链路层发来的包的第一个字节的高四位
  • 然后，物理层根据链路的通道数量进行链路序列化，假设我们这里的链路使用8通道进行传输，那么这个请求将会平均分配给这8个通道。到这里我们的包一共20个字节，所以前4个通道会分配3字节，后4个通道会被分配2字节
  • 接着，物理层会开始使用LFSR进行数据加扰，让数据看上去像是一堆随机数，用于保证最后链路中的DC平衡
  • 然后，物理层会对每个通道上的数据进行编码（Encoding），这里根据PCIe版本的不同，会使用不同的编码，比如：8b/10b，128b/130b和242B/256B编码，对于空闲的区域，需要补齐的话，也会使用IDL token进行补齐
  • 现在，我们来到了物理层的电气子块（Electrical Sub-block），首先，电气子块会讲每个通道发来的字节流转换为比特流，这一步叫做并行转串行（P2S）
  • 然后，电子子块会对每个bit进行调制，根据PCIe版本的不同，可以选择NRZ或者PAM4的调制方法
  • 然后，电气子块会对信号进行预加重（Pre-emphasis），以保证高频信号能很好的被传输线路传输
  • 最后，发送给传输线路之前，PCIe还会将其变换为差分信号，以避免外部线路中的干扰

这样，我们的PCIe请求就被转化为最后的电信号啦！接收方的处理流程也非常类似，将所有步骤反过来即可，不过在最开始物理层将查分信号合并之后，PCIe会有两步额外的操作：

  • 恢复时钟：PCIe根据REFCLK的基础时钟和数据中的01变换对数据的时钟进行恢复，以保证数据的正确读取
  • Retimer：如果传输线路导致了电信号发生时间上的jitter，retimer可以帮助去除这些jitter，以恢复干净的信号

这样，整个roundtrip我们就都跑通啦！所以到这里，协议栈就算是基本结束啦。下次有时间，我们再来继续看看PCIe所支持的各个事务都长什么样子，如何工作，以及它们是如何进行路由的吧！

7. 感谢

8. 参考资料

同系列文章：
原创文章，转载请标明出处：Soul Orbit
本文链接地址：PCIe（四）—— 物理层]]> <p>在<a href="/posts/pcie-3-tl-dll/">看完事务层和数据链路层</a>之后，我们来继续我们的协议栈之旅吧！这一篇中，我们会来看看PCIe物理层（Physical Layer）是如何工作的，从而帮助我们更加深入的了解PCIe的数据传输。</p> <h2 id="物理层（Physical-Layer）">1. 物理层（Physical Layer）</h2> <p>当数据链路层将上层数据封装好后，就会将其交给物理层进行传输。而物理层的主要目的将数据转换为易于介质传输的电信号，并发送出去，或者将接收到的转换后的信号，转变为上层能处理的数据包。其主要结构如下：</p> <p><img src="http://r12f-cdn.azureedge.net/r12f-assets/post_assets/2023-05-30-pcie-4-phy/pcie-phy-blocks.png" alt></p> PCIe（三）—— PCIe协议栈，事务层和数据链路层 http://r12f.com/posts/pcie-3-tl-dll/ 2023-05-27T21:27:24.000Z 2023-05-28T04:27:24.000Z 在上一篇中，我们介绍了PCIe设备的配置空间，及其设计的目的，最后我们说到了消息路由的设计。所以，这一篇我们就继续这个话题，来看看PCIe设备之间的通信方式吧。

1. PCIe协议栈

PCIe是以包（Packet）为单位传输数据的。和计算机网络类似，其协议也是分层的。其协议栈主要分为三层：物理层（Physical Layer），数据链路层（Data Link Layer）和事务层（Transaction Layer），如下图所示：

2. 事务层（Transaction Layer）

PCIe的协议栈最上层叫做事务层，这一层定义了所有和用户相关的PCIe的操作，所以这也会时大家最感兴趣的一层。

2.1. 事务（Transaction）

PCIe的所有操作都被称为一个事务（Transaction），这些事务分为四种类型：

  • 内存事务（Memory Transaction）
  • IO事务（IO Transaction）
  • 配置事务（Configuration Transaction）
  • 消息事务（Message Transaction）

一个事务根据其请求的处理方式又被分为两种：

  • Non-Posted：每个事务的请求消息发送出去后，会需要一个完成消息（Completion）来完成事务。比如，读内存。
  • Posted：请求发送后不需要完成消息，属于Fire and forget。比如，写内存和所有的消息事务（这也是唯二的两类请求）

所以，事务层的消息有三类：Non-Posted（NP），Posted（P）和Completion（Cpl）。

2.2. TLP（Transaction Layer Packet）

PCIe的事务请求和完成消息都是以TLP（Transaction Layer Packet）为单位传输的。其结构如下：

  • TLP Prefix：用来实现一些高级特性，比如精确时间测量（Precision Time Measurement），因为它不是必须的，所以我们先跳过。
  • TLP Digest：4个字节，可以存放诸如CRC的校验码，不过一般不需要开启，因为后面说的数据链路层已经自带了校验了，这里相当于是双保险。
  • TLP Header：这个是TLP中最重要的部分，我们后面马上会详细介绍。
  • TLP Payload：这个是TLP中的数据部分，根据不同的事务类型，其大小也不同。比如，读事务就不需要Payload。另外Payload的大小也是有限制的，它不能超过Max_Payload_Size，最大为4096字节。

2.2.1. TLP头

TLP的头部根据处理地址长度的不同，会有12字节（称为3DW）或者16字节（称为4DW）宽。其前4个字节（第一个DW）是公共的头部，包含了绝大部分的用于描述该事务本身的信息和行为的字段，其后的8个字节（第二个和第三个DW）会根据事务种类的不同而产生变化。其前四个字节如下：

  • Fmt: TLP头的格式
    • Bit 7：如果是1，则Fmt必须是100，表示这个头是TLP Prefix
    • Bit 6：1 = 读事务（TLP头之后没有Payload），0 = 写事务（TLP头之后有Payload）
    • Bit 5：1 = 使用32位地址，头部长度12字节（3DW Header），0 = 使用64位地址，头部长度16字节（4DW Header）
  • Type：事务类型，表示这个事务是什么类型的事务，比如内存事务、IO事务、配置事务、消息事务等
  • LN（Lightweight Notification）：用于标识当前这个内存请求或者完成消息是不是一个轻量级通知
  • TH（TLP Hints）：用于表示TPH（TLP Processing Hint）是否启用和TPH TLP Prefix是否存在
  • TD（TLP Digest）：1 = 有TLP Digest，0 = 没有TLP Digest
  • EP（Error Poisoning）：1 = 有错误，0 = 没有错误
  • AT（Address Translation）：虚拟化相关的字段，00 = 无地址转换，01 = 需要地址转换，10 = 地址转换已完成，11 = 保留
  • Length：Payload的长度，单位为DW（Double Word），1DW = 4字节

这里由两个字段TC和Attr我们没有介绍，因为它们是事务描述符的一部分，我们马上就会介绍。

2.2.2. 事务描述符（Transaction Descriptor）

为了帮助通信的双方知道对方的信息和对消息的处理方式进行描述，在TLP的头中有几个公共的字段，合在一起被称为事务描述符：事务ID（Requester ID和Tag两个字段），消息的属性（Attr字段），流量分类（TC字段）。虽然TLP头中第二个DW开始的部分会随着请求类型的不同而发生变化，但是这四个字段几乎会在所有的消息中存在（某些情况下Tag会被忽略），所以这里我们用一个内存请求的消息来做例子，展示它们在TLP中的位置：

2.2.2.1. 事务ID（Transaction ID）

事务ID由Requester ID和Tag两个字段组成，用于标识一个事务。其中，

  • Requester ID：一共16个bit，用于标识发起这个事务的设备，是请求发起者的BDF
  • Tag：一共10个bit，每个发出的TLP都会被赋予一个唯一的标签，帮助PCIe进行数据传输的跟踪和管理，比如并行处理，流控或乱序处理。这里注意T8和T9两个bits，它们和其他的tag的bits不在一起（绿色高亮），且需要修改10-Bit Tag Requester Enable配置寄存器启用
2.2.2.2. 消息属性（Attributes）

消息属性一共有三个bits：高两位 Attr[2:1]（Byte 1 - Bit 2，Byte 2 - Bit 5）用于控制消息处理的顺序，而最低位 Attr[0]（Byte 2 - Bit 4）用于控制Coherency。

2.2.2.2.1. 消息处理顺序（Ordering）

Attr[2:1]这两个Bits用于控制消息处理的顺序，一共有四种情况：

Attr[2]Attr[1]顺序类型说明
00强制顺序默认值，不允许乱序处理
01Relaxed Ordering允许接收者在当前请求没有完成的时候，同时处理任何后续的请求
10ID-based Ordering允许接收者在当前请求没有完成的时候，同时处理来自其他设备的请求
11无序相当于是Relaxed Ordering和ID-based Ordering的并集，允许接收者在当前请求没有完成的时候，同时处理任何的请求
2.2.2.2.2. No Snoop

NoSnoop（Attr[0]）使用来控制缓存一致性的。默认的情况下（值为0），PCIe会对请求进行缓存一致性的处理，比如一个内存的读请求，它会保证先去读Cache，如果没有读到再去读主内存。但是如果这个值为1，PCIe就会直接跳过Cache，去操作主内存。这样就有可能导致一致性的问题，因为有可能Cache中的内容还没有被写入主内存中，这样就读到了错误的值。

但是，这并不代表这个flag没有用，如果我们非常确定我们不需要考虑缓存，那么我们可以启用这个flag，直接去操作主内存，从而提高性能。

当然，也正因为有一致性的问题，所以这个功能被很多事务禁止使用了：比如配置事务、IO事务、大部分的消息事务和MSI（跳过缓存发起中断会导致DMA等功能出错，读到脏数据）等。

2.2.2.3. 流量分类（Traffic Class）

Traffic Class总共有3个bit，用于把所有的事务分成8个不同的类别，用于流控。

基于TC的流控是通过和VC（Virtual Channel）合作来实现的：

  1. PCIe中的所有物理链路（Link）都可以创建多个VC（Virtual Channel），而每个VC都独立工作，并有着流量控制机制。
  2. 一个或者多个TC可以被映射到一个VC上，这样就可以通过操作TLP的TC来控制TLP走的VC了。
  3. VC通过信用机制来控制发包速度，每个VC都有着自己的Credit Pool，如果一个VC的Credit不为0，那么它就可以发送TLP，并且消耗特定的Credit。每个VC的Credit也会在特定的时候补充，保证通信不会中断。
  4. TC的默认值是0，也是所有设备必须实现的。它被Hardcoded到了VC0上，所以如果没有设置TC，那么所有的TLP都会走VC0。
  5. 最后，如果两个包有了不同的VC，或者不同的TC，那么它们之间将没有顺序的保证。

这里我们主要了解TC到VC的映射就好，关于VC的具体机制，我们会在后面数据链路层介绍。以下是一个TC和VC相互合作的配置的例子。通过这种方法，我们就可以对PCIe进行流量控制啦！

2.3. TLP事务路由

有了事务ID，我们可以很容易的了解当前事务的源是谁，然而为了能让通信双方通信，我们还需要知道事务的目的地是哪里，这样我们才能把事务发送到正确的地方。

在PCIe中，不同类型的事务中会使用不同的字段和方法来指定目的地，但是总结起来只有两种：

  1. 通过具体的地址来指定目的地：这种路由方式叫做基于地址的路由（Address-Based Routing）。这种方式主要用于内存事务（Memory Transaction）和IO事务（IO Transaction），通过需要访问的地址，我们就可以通过我们上一篇中介绍的路由机制来进行路由了。

  2. 通过BDF来指定目的地：这种路由方式叫做基于ID的路由（ID Based Routing）。这种方式主要用于非内存访问型的事务，比如：配置事务（Configuration Transaction），消息事务（Message Transaction）和事务完成的消息通知（Completion）。

    另外，我们上一篇还提到了一种特殊的ID分配方式ARI（Alternative Routing ID），它的唯一区别就是把Device Number的5个Bit给了Function Number，用以支持更多的Function，如下：

2.4. TLP小结

好了，到此我们已经把最核心的TLP的公用字段都介绍完毕了，包括TLP主题格式，事务如何分类，如何路由，如何进行流控等等。这里，为了再来整体的来看一下事务层的处理，我们可以参照Intel Cyclone 10的总体框图，如下：

当然在TLP的头中，我们仍然有很多字段没有涉足，这些字段都和具体的事务类型相关，所以我们在这一篇中就不会过多的深入了。毕竟，我们这一篇主要是想聚焦在PCIe的通信协议本身上，来展示PCIe是如何进行通信的，关于每个具体的事务及其格式，我们会放在后面单独的说。

3. 数据链路层（Transaction Layer）

当事务层将事务消息准备好之后，就会向下传递给数据链路层（Data Link Layer）。对于我们发送的事务消息来说，数据链路层主要负责一件事情：保证事务消息能正确的传输到目的地。

数据链路层传输的包主要包括两种，一种用于传输TLP事务消息，一种用于传输数据链路层的控制消息，比如功能（Feature）控制，流量控制，电源管理等等。这两种类型的包通过物理层的Token来进行区分：STP（Start of TLP）表示TLP消息，SDP（Start of DLLP）表示控制消息（DLLP，Data Link Layer Packet）。我们这里一个一个来看。

3.1. TLP事务消息的传输

3.1.1. 数据包格式和数据发送

为了达到这个目的，数据链路层会对数据包再进行一层封装：

  1. 在包的前方添加一个序列号（Sequence Number），占用2个字节，用于保证包发送的顺序。这个序列号是每个Link独立的，只有上下游两端保存的序列号（NEXT_RCV_SEQ）一致，才会被对端接收。
  2. 在包的后方添加一个CRC校验码，叫做LCRC（Link CRC），占用4个字节，用于保证包中数据的正确性。注意，计算CRC的时候，刚刚添加的序列号也会被纳入计算范围中。

封装完成后，为了保证成功的发送，数据链路层会先将包保存在Retry Buffer中，再转交给物理层（Physical Layer）进行发送。在每条消息发送完毕之后，发送方会等待接收方发送ACK消息，如果接收到的返回消息是失败消息，比如Seq错误，CRC校验错误，或者任何物理层的错误，发送方就会把Retry Buffer中的消息拿出来重新发送。[1]（3.6 Data Integrity Mechansisms） 。

3.1.2. 数据接收

对于数据的接收方，操作流程则相反。接收方会检查接收到的数据包的序列号和CRC是否正确，如果不正确，就会发送一个Nak消息，要求发送方进行重传。如果正确，就会回发一个Ack消息，表示接收成功，而此时发送方在收到了ACK消息后也可以将其从Retry Buffer中移除。这样，数据链路层就保证了TLP的正确传输。 [1]（3.6 Data Integrity Mechansisms） 。

更加具体的数据接收处理流程如下：

除了传输TLP数据包之外，数据链路层还需要很多专门用于控制的数据包，比如上面提到的Ack和Nak，这些数据包叫做DLLP（Data Link Layer Packet）。其格式如下：

DLLP中DLLP Type用来指定包的类型，而最后16位的CRC用来做校验，其主要分为以下几种类型：

名称Type描述
Ack00000000b用于确认接收到的TLP数据包
Nak00010000用于拒绝接收到的TLP数据包
<InitFC1/InitFC2/UpdateFC>-<P/NP/Cpl>（Type较多，后面来说）用于流量控制，P/NP/Cpl表示流控类型
MRInitFC1/MRInitFC2/MRUpdateFC<0111/1111/1011>0xxxb用于流量控制，P/NP/Cpl表示流控类型
PM_*00100xxxb用于电源管理，告知对端当前的电源状态
NOP00110001b用于保持链路活跃，防止链路被关闭
Data_Link_Feature00000010b用于告知对端当前链路的特性，如支持Scaled Flow Control
Vendor-specific00110000b用于支持厂商自定义的DLLP，实现厂商特有功能

3.2.1. Ack/Nak

我们在TLP事务消息传输的里就提到过Ack和Nak消息，它们可以说是DLLP中最常用的消息了。功能顾名思义，Ack表示接收成功，Nak表示接收失败，需要重传。这两个包的格式如下：

其中，AckNak_Seq_Num表示当前已经收到的最新的消息序号，所以和TCP类似，PCIe的Ack和Nak可以进行批量操作：无论是Ack还是Nak，当发送方收到这个消息之后，就可以将Retry Buffer中比这个序号老的消息全部移除了，所以Ack/Nak时只需要将最新的序号带上即可。Ack/Nak的差别在于：如果是Nak，那么发送方在移除之后，需要对Retry Buffer中这个序号之后的消息全部进行重传。

最后，DDLP的重传是由次数限制的，默认阈值是4次。如果超过四次，就出触发物理层开始重建（retrain）链路。如果依然失败，就会将该链路关闭。

3.2.2. VC（Virtual Channel）与流量控制

在说TLP的时候，我们提到了PCIe的流量控制是通过将TC（Traffic Class）映射到VC（Virtual Channel），并且利用VC的信用机制来实现的。这里我们就一起来看看这个信用机制吧！

数据链路层中的信用额度管理有两个重要的特点：

  1. 不同处理方式是的TLP消息有着单独的信用额度管理：Posted（P），Non-Posted（NP）和Completion（Cpl）。这三种消息的信用额度是独立的，互不影响。
  2. 每个VC都有着自己的独立的信用额度管理，而不是Link。也就是说，如果一个Link上有多个VC，那么每个VC都需要单独的初始化和更新。

参与流量控制的消息有很多，主要有三类，每一类有三个变种（N/NP/Cpl），我们的流量控制也主要分三步，其细节和统一的消息格式如下：

  • InitFC1-P/NP/Cpl：接收端设备使用此消息向发送端发起初始化流量控制的流程，并初始化信用额度，这是第一步。这个消息有接收端发起的原因是因为，不同的接收端能力不同，所以应该由接收端根据自己的能力，比如缓存的大小，来决定信用额度的大小。
  • InitFC2-P/NP/Cpl：用于发送端向接收端确认InitFC1的消息，这是第二步。这个消息中会带有从第一步接收到的信用信息，但是它会被接收端忽略，并没有什么用。另外，这个消息发送之后，发送端将不会再理会任何后续的InitFC1消息了。
  • UpdateFC-P/NP/Cpl：用于在信用额度初始化完成之后，接收端向发送端对信用额度进行更新。

这个消息中各个字段含义如下：

  • Type：消息ID，映射如下：

    TypeId
    InitFC1-P0100b
    InitFC1-NP0101b
    InitFC1-Cpl0110b
    InitFC2-P1100b
    InitFC2-NP1101b
    InitFC2-Cpl1110b
    UpdateFC-P1000b
    UpdateFC-NP1001b
    UpdateFC-Cpl1010b

  • VC ID（v[2:0]）：Virtual Channel的Id，Id一共有3位，代表8个VC。

  • HdrFC：TLP头部的Credit数量。在发送时，一个TLP头对应着一个Header Credit，不论该TLP的大小如何。

  • DataFC：TLP数据部分的Credit数量。一个 DW（Double Word，双字，即4字节）对应着一个Data Credit。

举个例子，我们假设有一个64位地址的内存的写请求，数据长度为128字节，那么我们会需要发送一个4 DW的TLP头，加上128字节的Payload，和一个1 DW可选的TLP Digest，所以我们一共最多消耗1个Header Credit，和 (128 + 4) / 4 = 33个Data Credit。

然后，为了保证发送方正常的消息发送，当接收方处理完部分消息后（或者一些特殊情况后），就会根据其当前缓存的大小，向发送方发送UpdateFC消息，告诉发送方，接收方的信用额度还剩下多少。另外，除了这种情况，接收方还会定时的向发送方上报自己的信用额度（最长间隔30us），这么做的原因是为了避免意外情况，如CRC校验出错，导致信用额度上报丢失，从而导致发送方停止发送消息的问题。

最后，数据链路层还支持Scaled Flow Control，即信用额度的数量可以是2的幂次方，这样就可以管理更大的信用额度了：

为了帮助理解，我们举一个例子：

注意：如果查看原始的包，在计算时需要注意，HdrFC和DataFC都没有对其到字节上，所以记得做好位运算。

  1. 首先，PCIe的Endpoint会向Switch发送如下三条消息来进行流控初始化：

  2. 当Switch收到这个消息后，也会向Endpoint发送三条类似的消息，进行反向的初始化。因为流程类似，从这里开始，之后Switch向Endpoint发送的反向流程我们就忽略了。

  3. Switch收到了InitFC1 DLLP后，会使用InitFC2 DLLP进行确认：

到此，等两边InitFC2的消息交换完毕之后，初始化就完成了！

3.3. 数据链路层小结

最后为了帮助理解，我们再来看一下数据链路层的整体架构：

到这里，数据链路层上和数据传输相关的核心内容就都介绍完了！数据链路层中其实还有很多其他的内容，比如Link的初始化，状态机，电源管理，和Vendor-specific DLLP等等，这些内容我们这里就不详细介绍了，有兴趣的读者可以自行查阅PCIe Spec [1]。

4. 小结

好了，由于篇幅原因，我们这一篇就先到这里。这一篇中我们介绍了PCIe的协议栈，并且详细的介绍了事务层（Transaction Layer）和数据链路层（Data Link Layer）是如何工作的，包括事务的分类，各种消息的格式，数据链路层的作用和封装，以及PCIe基于TC和VC的流控机制。

在下一篇中，我们会继续介绍PCIe协议栈中遗留的部分 —— 物理层（Physical Layer）。

5. 参考资料

同系列文章：
原创文章，转载请标明出处：Soul Orbit
本文链接地址：PCIe（三）—— PCIe协议栈，事务层和数据链路层]]> <p>在上一篇中，我们介绍了PCIe设备的配置空间，及其设计的目的，最后我们说到了消息路由的设计。所以，这一篇我们就继续这个话题，来看看PCIe设备之间的通信方式吧。</p> <h2 id="PCIe协议栈">1. PCIe协议栈</h2> <p>PCIe是以包（Packet）为单位传输数据的。和计算机网络类似，其协议也是分层的。其协议栈主要分为三层：物理层（Physical Layer），数据链路层（Data Link Layer）和事务层（Transaction Layer），如下图所示：</p> <p><img src="http://r12f-cdn.azureedge.net/r12f-assets/post_assets/2023-05-27-pcie-3-tl-dll/pcie-stack.png" alt></p> PCIe（二） —— 配置空间 http://r12f.com/posts/pcie-2-config/ 2023-05-23T23:53:51.000Z 2023-05-24T06:53:51.000Z 在上一篇中，我们简单的介绍了PCIe的总体架构，设备树和主要组成部分，并且了解了如何通过lspci命令和Windows下的设备管理器来查看PCIe的系统结构。这一篇，我们来更加深入的看看PCIe中的设备相关的信息，如配置空间，来帮助我们了解PCIe和这些命令的工作原理。

1. It is all about memory

理解PCIe的关键，我个人觉得是理解内存的访问。这里先小小的剧透一下，PCIe中主要定义了4种请求：Memory Transaction，I/O request，Configuration Space Access和Message。除了最后一种以外，其余三种全都是基于内存访问的，甚至连中断发起都是基于内存访问的，所以如果我们能很好的理解内存的访问，我们就能很好的理解PCIe。

学过操作系统的小伙伴对虚拟内存这个概念肯定不陌生。在现代的操作系统中，当CPU想去访问一段内存的时候，它访问的地址并不是真实内存的物理地址，而是一个虚拟地址，这个地址需要经过MMU进行地址转换，将其变为物理地址之后才能通过总线去物理内存拿到真实的数据 [2]。

而PCIe中基于内存访问的请求的实现，也正是利用类似的机制：

  • PCIe中的每一个设备，无论是Endpoint（Type 0）还是Switch（Type 1），都会分配自己的内存地址空间，而这个地址空间会被映射到系统的物理地址空间中，并最终映射到虚拟内存中去。
  • 当CPU发起一个内存读写请求的时候，如果这个地址经过了MMU的翻译，最后的物理地址落到了PCIe某个设备的内存空间之后，就会触发Root Complex将其转换为PCIe的请求，并通过PCIe总线发给对应的设备。

“但是等等，你说物理地址？？？物理地址不应该就是物理内存的地址吗？”嗯，没错，这里就是物理地址，物理地址空间中不仅仅有物理内存，还有PCIe设备的内存，在访问物理地址的时候，处理器会将请求发给内存控制器，内存控制器会根据总线上各个Root Complex的Host Bridge的配置，将其传递给DRAM或者对应的Root Complex，最终交给对应的PCIe的设备。

然而，系统是如何知道哪些地址的访问需要转换为PCIe的请求，最后又发送给哪些设备呢？这就需要我们来看看PCIe的配置空间了。

2. 设备配置空间

在PCIe中，每个设备都会拥有一块独立的配置空间（Configuuraiton Space），这块空间的大小是4096字节，其中头部和PCI3.0保持兼容，有64个字节，这块空间的大小是固定的，不会随着设备的类型或者系统的重启而改变。

上一章我们提到过，PCIe中有两类设备：Type 0表示终端设备，和Type 1表示Switch。由于职责的不同，其配置空间的内容也不同。但是为了保持一致，方便管理，这两类设备的配置有很多相同的部分，比如配置空间的头部，如下图所示：

除了我们上面提到的Vector ID和Device ID，这个头部还包含了很多其他的字段。由于太多细节对我们前期理解PCIe并没有太多帮助，我们这里就不一一介绍了，感兴趣小伙伴可以移步PCIe的规范文档7.5.1.1 Type 0/1 Common Configuration Space进行查看 [1]。

3. 配置空间的分配与访问

在系统启动时，BIOS会通过ACPI（Advanced Configuration and Power Interface）找到所有的PCIe设备，并为其分配配置空间，映射到物理地址空间中，然后通过ECAM（Enhanced Configuration Access Mechanism）转交给操作系统。我们通过acpidump对MCFG表进行导出，然后使用iasl就可以查看到ECAM的基址了：

1
2
3
4
5
6
7
8
9
10
# Dump MCFG table from ACPI as binary file: mcfg.dat
$ sudo acpidump -n MCFG -b

# Disassemble MCFG table
$ iasl ./mcfg.dat; cat mcfg.dsl
...
[000h 0000   4]                    Signature : "MCFG"    [Memory Mapped Configuration table]
...
[02Ch 0044   8]                 Base Address : 00000000E0000000
...

而为了方便访问，PCIe使用BDF来构造每个配置空间相对于ECAM的偏移。由于每个空间都是4096个字节，所以PCIe将BDF向左移位了12位，对其进行预留。其地址映射关系如下：

打个比方，如果某个设备的BDF是46:00.1，ECAM基址是0xE0000000，那么其配置空间起始地址就是：0xE0000000 + (0x46 << 20) | (0x00 << 15) | (0x01 << 12) = 0xE46001000。或者简单的记忆就是BDF的Hex后面跟三个0。我们这里也可以通过lspci和/dev/mem进行直接的物理内存访问来验证：

1
2
3
4
5
6
$ lspci -s 46:00.1  -nn
46:00.1 Ethernet controller [0200]: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe [14e4:165f]

$ sudo hexdump -x --skip 0xe4601000 /dev/mem | head
e4601000    14e4    165f    0406    0010    0000    0200    0010    0080
...

这段内存的前面几个数字14e4和165f就是这个设备的Vendor ID和Device ID，这和我们通过lspci看到的完全一致：[14e4:165f]。

当然，每次这样进行计算和转换来查看原始的配置空间是非常麻烦的，所以我们可以通过setpci来直接访问：

1
2
3
4
5
$ setpci -s 46:00.1 00.w
14e4

$ setpci -s 46:00.1 02.w
165f

使用setpci的时候需要注意：无论是读取和写入，请务必按照目标字段的长度来进行输入，PCIe的内存地址的IO并不一定是内存的读取，而有可能被转换成PCIe的请求，如果长度不对，则很有可能出现错误。

4. Type 0配置空间

接下来，我们来看看每一类设备的配置空间。由于PCIe上大部分我们使用的设备都是Type 0的终端设备，我们就先从Type 0开始吧！

4.1. Type 0配置空间的结构

Type 0设备的配置空间如下：

和公共字段相比，Type 0的配置空间多了一些字段：

  • Subsystem ID和Subsystem Vendor ID：顾名思义，用来帮助每个设备厂商标识更细粒度设备信息
  • Cardbus CIS Pointer Register：已经废弃，以前用于PC-Card中
  • Expansion ROM Base Address Register：用于描述设备的ROM的地址，这里和我们的主要内容关系不大，就不过多展开了

4.2. BAR（Base Address Register）

除了上面这些字段，其中最重要的就是BAR了。在Type 0的配置空间中，BAR区域有24个字节，可以保存6个指针/地址，每一个都可以用来描述一个不同的内存空间或者IO空间的地址和范围。

为了描述不同类型的地址空间，这里的指针不是单纯的指针，而有着自己的结构，如下 [1] [3] ：

其中：

  • 最低位Bit 0：是一个标志位，用于描述地址空间的类型，0表示内存空间，1表示IO空间
  • Memory Space中的Bit [2:1] - Type：用于描述内存空间的类型，00表示32位地址空间，10表示64位地址空间
  • Memory Space中的Bit 3 - Prefetchable：用于描述内存空间是否支持预取，0表示不支持，1表示支持。如果一段内存空间支持预取，它意味着读取时不会产生任何副作用，所以CPU可以随时将其预取到DRAM中。而如果预取被启用，在读取数据时，内存控制器也会先去DRAM查看是否有缓存。当然，这是一把双刃剑，如果数据本身不支持预取，那么除了可能导致数据不一致，多一次DRAM的查询还会导致速度下降。

另外也许你会觉得很奇怪，一个32位的空间，又是如何又表示地址又表示范围呢？这里其实和BAR的初始化过程有关。BAR的寄存器初始化主要有三步 [1]（7.5.1.2.1 Base Address Registers）：

  1. BIOS将全1的地址写入BAR寄存器，这样会导致BAR寄存器的值被重置，并被设备重新写入初始值。这个初始值是一个地址，表示如果将这个BAR寄存器指向的内存放在物理内存的最后，其地址为多少。比如，如果我们需要4KB的内存空间，那么这个地址就是0xFFFFF000，当然这里还需要加上最低几位表示类型的Flag。另外，如何这个空间不可用，那么返回全0。
  2. BIOS读取BAR寄存器的值，并去除掉最后几位Flag，然后将其取反并加1，求出其大小。比如0xFFFFF000，取反之后就是0x00000FFF，加1之后就是0x00001000，也就是4KB。
  3. BIOS接着进行真正的地址分配和映射，并将这个新的地址重新写入BAR。这个时候设备没有权利拒绝这个修改，并且也不能再对这个地址进行任何的更改了，不然系统可能会整个崩溃。

在这样的握手之后，我们就通过BAR中这一个地址大小的空间，又表示了地址，又传递了大小了。

对于BAR空间中保存的所有的地址，我们都可以通过lspci来查看到：

1
2
3
4
5
6
7
8
9
$ sudo lspci -s 81:00.0 -nn -vv
81:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e82] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: Gigabyte Technology Co., Ltd TU104 [GeForce RTX 2080] [1458:37c1]
        ...
        Region 0: Memory at f0000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at 20030000000 (64-bit, prefetchable) [size=256M]
        Region 3: Memory at 20040000000 (64-bit, prefetchable) [size=32M]
        Region 5: I/O ports at b000 [size=128]
        ...

从上面我们可以看到，这块显卡中有4个地址空间，三块是内存空间，一块是I/O空间。Region的编号表示其地址在BAR中间的偏移，比如Region 1就是BAR中的第二个DWORD，Region 3就是BAR中的第4个DWORD（Region 1是64位，所以需要占用8个字节），以此类推。这里我们也可以把原始的物理内存dump出来，进行验证。这里我把不同的地址，用不同的颜色标记了出来：

5. Type 1配置空间与PCIe遍历

接下来我们来看看Type 1设备，也就是Switch，的配置空间。它的配置空间和Type 0配置空间有着很大的不同。虽然我们可以看到它们大小是一样的，但是其中BAR空间和设备信息的字段变成了很多的地址信息，如下 [1]：

这些改动的原因是因为作为Switch，它并不需要也不会实现特定的功能，它的作用就是为PCIe的消息提供路由转发的机制，所以中间所有的字段几乎都变成了和路由转发相关的地址信息。

  • Primary Bus Number / Secondary Bus Number / Subordinate Bus Number：用于基于BDF的转发
  • Memory Base / Memory Limit：用于基于内存空间地址的转发
  • Prefetchable Memory Base (Upper) / Prefetchable Memory Limit (Upper)：也是用于基于内存空间地址的转发，不过是Prefetchable的地址
  • IO Base / IO Limit：用于基于IO空间地址的转发

然而，说到路由转发，一个很奇怪的问题就出现了：为什么我们没有在配置空间中看到我们网络交换机中的那种复杂的路由表呢？这其实和PCIe如何进行ID和地址的分配有关，这个过程叫做PCIe的遍历（PCIe Enumeration）。我们这里就用下面这张图来说明一下这个过程是如何进行的：

整个PCIe的遍历过程其实是一个简单的DFS和线段树，拿上图的BDF来举例子，每一个Bridge中都保存着三个用于路由的关键信息：

  • Primary Bus Number（Pri）：这个Bridge所在的Bus Number，也就是它的上游连接的Bus Number
  • Secondary Bus Number（Sec）：这个Bridge所连接的下一个Bridge的Bus Number
  • Subordinate Bus Number（Sub）：这个Bridge所连接的下游所有的Bus的最大的Bus Number

这些信息形成了一个递归的结构来帮助我们进行基于BDF进行路由，而PCIe的遍历就是来建立这个递归的结构。我们来看看上图中的遍历过程：

  1. 首先，我们从Root Complex的Host Bridge出发。Host Bridge略有不同，因为他的上游没有连接任何总线，所以没有Pri，它的下游连接的是Root Complex中的总线，也就是Bus 0，所以我们的遍历从Bus 0开始，此时Host Bridge中的Sec是0。另外，虽然此时Sub未知，但是为了安全，在向下遍历的过程中，我们会把Sub设置为最大值，也就是0xFF，这样即便是出错，我们也不会出现无法路由的情况。
  2. 然后，我们遍历到了Root Complex中的第一个Bridge，很明显它的Pri是0。由于桥接的原因，它的下游总线的Bus Number要保证唯一，于是我们加1，所以它的Sec是1，同样Sub还是改为0xFF。
  3. 然后，我们继续递归，到了第一个Switch的Upstream Bridge，因为它所连接的Bus Number是1，所以它的Pri是1，而同理，它的下游会连接到它的内部总线，于是需要把Bus Number再加1，变成2，于是Sec为2。
  4. 继续递归到第一个Downstream Bridge，同样它的下游的Bus Number需要加一，于是Pri为2，Sec为3。
  5. 继续递归，到了第一个Endpoint，它的下游没有任何设备，所以开始回溯。
  6. 回到了步骤4所在的Bridge，此时最大的Bus Number为3，所以Sub更新为3，最后Pri为3，Sec为3，Sub为3。
  7. 同理，第二个Bridge的Pri为3，Sec为4，Sub为4。
  8. 然后回到步骤3访问的Bridge，此时最大的Bus Number为4，所以Sub更新为4，最后Pri为1，Sec为2，Sub为4。
  9. 依次类推，直到所有的设备完成。

等所有的步骤结束，我们就会得到上面这张图中对应的分配了！类似的，内存的空间，IO的地址空间，Prefetchable的地址空间，都会进行类似的遍历和分配，然后把最后合并的区间保存在上游的配置空间中，这样大家应该就理解了为什么配置空间中只需要保存一个区间就可以进行路由了，而不需要保存复杂的路由表了。

另外，PCIe的热插拔其实就是靠在遍历过程中预留更多的Bus Number来实现的，这样就可以在不影响已有设备的情况下，插入新的设备了。

6. 消息路由

现在，有了上面的路由信息，我们就可以很轻松的来对PCIe的消息进行路由了！它其实就是一个非常简单的线段树，我们假设需要将一个消息从CPU发给BDF为04:00.0的设备，那么其路由过程如下：

  1. 首先，CPU会请求Host Bridge产生消息，然后由于Bus 4在第一个Bridge的Sec和Sub之间，Root Complex会将这个消息通过这个Bridge转发出去。
  2. 然后继续递归，这个消息将通过Bus 1传递给下游Switch中的连接上游总线的Bridge。而这个Switch会来检查它下游所有Bridge的配置，最后发现Bus 4在它的第二个下游Bridge的Sec和Sub之间，于是这个Switch会将这个消息通过这个Bridge转发出去。
  3. 消息经过Bus 4到达Function 04:00.0。

7. 配置空间访问流程

为了总结，我们就从CPU出发，用对配置空间的读请求做一个例子，来对整体的流程来一个总结吧！

  1. 首先，CPU执行内存访问指令来读取虚拟内存中映射的，在ECAM中的，某个配置空间的内容。比如：mov ax, [0x10e8100000]。
  2. 然后，这个读请求的地址经过MMU，查询页表得到物理内存的地址。假设，这个物理地址是BDF为 81:00.0 的设备的配置空间地址：0xe8100000。
  3. 这个读请求会被发送给Memory Controller，Memory Controller检查这个地址之后，发现这个地址不属于DRAM，于是转发给对应的PCIE控制器，到Root Complex中。
  4. Root Complex的Host Bridge收到这个请求，发现这个请求属于设备的配置空间，于是将这个请求转换为一个配置空间的读请求（请求名称叫CfgR0，具体的结构后面会介绍），地址是BDF 81:00.0，Offset是0，长度是2个字节，并利用BDF开始路由。
  5. Root Complex根据所有连接到其上面的设备和桥的配置空间里的配置，将这个请求转发给对应的设备。如果是设备本身就检查Device Number和Function Number，如果是桥，就检查Secondary Bus Number和Subordinate Bus Number，然后进行递归的转发。
  6. 最后，请求到达设备。

数据返回的流程和请求的流程非常类似，只不过是从设备出发，返回给CPU，这里就不再赘述了。

8. 总结

好了，这一篇我们把配置空间的结构，分配和访问，都大概总结了一遍，并且还介绍了它们的头部字段和这些字段的意义，包括BAR和消息路由的原理。之后，如果有时间，我们会继续来探索PCIe的数据报文的结构和传输等等。

9. 参考资料

同系列文章：
原创文章，转载请标明出处：Soul Orbit
本文链接地址：PCIe（二） —— 配置空间]]> <p>在<a href="/posts/pcie-1-basics/">上一篇中，我们简单的介绍了PCIe的总体架构，设备树和主要组成部分</a>，并且了解了如何通过<code>lspci</code>命令和Windows下的设备管理器来查看PCIe的系统结构。这一篇，我们来更加深入的看看PCIe中的设备相关的信息，如配置空间，来帮助我们了解PCIe和这些命令的工作原理。</p> <h2 id="It-is-all-about-memory">1. It is all about memory</h2> <p>理解PCIe的关键，我个人觉得是理解内存的访问。这里先小小的剧透一下，PCIe中主要定义了4种请求：Memory Transaction，I/O request，Configuration Space Access和Message。除了最后一种以外，其余三种全都是基于内存访问的，甚至连中断发起都是基于内存访问的，所以如果我们能很好的理解内存的访问，我们就能很好的理解PCIe。</p> PCIe（一） —— 基础概念与设备树 http://r12f.com/posts/pcie-1-basics/ 2023-05-22T16:56:15.000Z 2023-05-22T23:56:15.000Z PCIe的全称是Peripheral Component Interconnect Express，是一种用于连接外设的总线。它于2003年提出来，作为替代PCI和PCI-X的方案，现在已经成了现代CPU和其他几乎所有外设交互的标准或者基石，比如，我们马上能想到的GPU，网卡，USB控制器，声卡，网卡等等，这些都是通过PCIe总线进行连接的，然后现在非常常见的基于m.2接口的SSD，也是使用NVMe协议，通过PCIe总线进行连接的，除此以外，Thunderbolt 3 [2]，USB4 [3]，甚至最新的CXL互联协议 [4]，都是基于PCIe的！

所以一旦开始往设备相关的开发上面走了之后，PCIe可以算是一个绕不过的坎。这几天看了一些和PCIe相关的资料，这里简单的总结一下，也希望对大家有所帮助。这篇文章主要会聚焦在硬件的部分，和操作系统本身没有什么太大的关系，无论是Windows还是Linux，底层的部分都是非常类似的，文章中也会提到调试的方法，不过会主要以Linux为主。

那我们就开始吧！

1. PCIe总体框图

首先，我们先从PCIe的基本概念开始。PCIe的架构主要由五个部分组成：Root Complex，PCIe Bus，Endpoint，Port and Bridge，Switch。其整体架构呈现一个树状结构，如下图所示：

2. Root Complex（RC）

Root Complex是整个PCIe设备树的根节点，CPU通过它与PCIe的总线相连，并最终连接到所有的PCIe设备上。

由于Root Complex是管理外部IO设备的，所以在早期的CPU上，Root Complex其实是放在了北桥（MCU）上 [5]，后来随着技术的发展，现在已经都集成进了CPU内部了 [8]。（注意下图的System Agent的部分，他就是PCIe Root Complex所在的位置。）

另外，虽然是根节点，但是系统里面可以存在不只一个Root Complex。随着PCIe Lane的增加，PCIe控制器和Root Complex的数量也随之增加。比如，我的台式机的CPU是i9-10980xe，上面就有4个Root Complex，而我的笔记本是i7-9750H，上面就只有一个Root Complex。我们在Windows上可以通过设备管理器来查看：

i9-11900Ki7-9750H

Linux上也类似。下图是从我的服务器的主板说明书上截出来的框图，用的CPU是EPYC 7742，可以很明显的看到PEG P0-3，对应着4个PCIe Controller和Root Complex：[6]

而我们可以通过lspci命令来查看所有的Root Complex：

1
2
3
4
5
$ lspci -t -v
-+-[0000:c0]-+-00.0  Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex
 +-[0000:80]-+-00.0  Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex
 +-[0000:40]-+-00.0  Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex
 \-[0000:00]-+-00.0  Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex

3. PCIe总线（Bus）

PCIe上的设备通过PCIe总线互相连接。虽然PCIe是从PCI发展而来的，并且甚至有很多地方是兼容的，但是它与老式的PCI和PCI-X有两点特别重要的不同：

  1. PCIe的总线并不是我们传统意义上共享线路的总线（Bus），而是一个点对点的网络，我们如果把PCI比喻成网络中的集线器（Hub），那么PCIe对应的就是交换机了。换句话说，当Root Complex或者PCIe上的设备之间需要通信的时候，它们会与对方直接连接或者通过交换电路进行点对点的信号传输。[7]
PCI BusPCIe Bus
  1. 老式的PCI使用的是单端并行信号进行连接，但是由于干扰过大导致频率无法提升，所以后来就演变成PCIe之后就开始使用了高速串行信号。这也导致了PCI设备和PCIe设备无法兼容，只能通过PCI-PCIe桥接器来进行连接。当然这些我们都不需要再去关心了，因为现在已经很少看见PCI的设备了。

关于PCIe的通讯和包路由交换，我们先到这里，后面会更深入的介绍。

4. PCIe Device

PCIe上连接的设备可以分为两种类型：

  • Type 0：它表示一个PCIe上最终端的设备，比如我们常见的显卡，声卡，网卡等等。
  • Type 1：它表示一个PCIe Switch或者Root Port。和终端设备不同，它的主要作用是用来连接其他的PCIe设备，其中PCIe的Switch和网络中的交换机类似。

4.1. BDF（Bus Number, Device Number, Function Number）

PCIe上所有的设备，无论是Type 0还是Type 1，在系统启动的时候，都会被分配一个唯一的地址，它有三个部分组成：

  • Bus Number：8 bits，也就是最多256条总线
  • Device Number：5 bits，也就是最多32个设备
  • Function Number：3 bits，也就是最多8个功能

这就是我们常说的BDF，它类似于网络中的IP地址，一般写作BB:DD.F的格式。在Linux上，我们可以通过lspci命令来查看每个设备的BDF，比如，下面这个FCH SMBus Controller就是00:14.0：

1
2
3
4
5
$ lspci -t -v
 # [Domain:Bus]
 \-[0000:00]-+-00.0  Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex
         # Device.Function
             +-14.0  Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller

在我们知道了任何一个设备的BDF之后，我们就可以通过它查看到这个设备的详细信息了，如下：

1
2
3
4
5
6
7
8
$ lspci -s 00:14.0 -vv 
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61)
        Subsystem: Super Micro Computer Inc H12SSL-i
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        IOMMU group: 39
        Kernel driver in use: piix4_smbus
        Kernel modules: i2c_piix4, sp5100_tco

另外，由于默认BDF的方式最多只支持8个Function，可能不够用，所以PCIe还支持另一种解析方式，叫做ARI（Alternative Routing-ID Interpretation），它将Device Number和Function Number合并为一个8bit的字段，只用于表示Function，所以最多可以支持256个Function，但是它是可选的，需要通过设备配置启用 [1]。

4.2. Type 0 Device和Endpoint

所有连接到PCIe总线上的Type 0设备（终端设备），都可以来实现PCIe的Endpoint，用来发起或者接收PCIe的请求和消息。每个设备可以实现一个或者多个Endpoint，每个Endpoint都对应着一个特定的功能。比如：

  • 一块双网口的网卡，可以每个为每个网口实现一个单独的Endpoint；
  • 一块显卡，其中实现了4个Endpoint：一个显卡本身的Endpoint，一个Audio Endpoint，一个USB Endpoint，一个UCSI Endpoint；

这些我们都可以通过lspci或者Windows上的设备管理器来查看：

1
2
3
4
5
6
7
8
9
10
11
$ lspci -t -v
-+-[0000:c0]-+-00.0  Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex
             # A NIC card with 2 ports:
 |           +-01.1-[c1]--+-00.0  Mellanox Technologies MT2892 Family [ConnectX-6 Dx]
 |           |            \-00.1  Mellanox Technologies MT2892 Family [ConnectX-6 Dx]
 +-[0000:80]-+-00.0  Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex
             # A graphic card with 4 endpoints:
 |           +-01.1-[81]--+-00.0  NVIDIA Corporation TU104 [GeForce RTX 2080]
 |           |            +-00.1  NVIDIA Corporation TU104 HD Audio Controller
 |           |            +-00.2  NVIDIA Corporation TU104 USB 3.1 Host Controller
 |           |            \-00.3  NVIDIA Corporation TU104 USB Type-C UCSI Controller

4.3. RCIE（Root Complex Integrated Endpoint）

说到PCIe设备，脑海里面可能第一反应就是有一个PCIe的插槽，然后把显卡或者其他设备插在里面，就像我们上面看到的这样。但是其实系统中有大量的设备是主板上集成好了的，比如，内存控制器，集成显卡，Ethernet网卡，声卡，USB控制器等等。这些设备在连接PCIe的时候，可以直接连接到Root Complex上面。这种设备就叫做RCIE（Root Complex Integrated Endpoint），如果我们去查看的话，他们的Bus Number都是0，代表Root Complex。

4.4. Port / Bridge

那么其他的需要通过插槽连接的设备呢？这些设备就需要通过PCIe Port来连接了。

在Root Complex上，有很多的Root Port，这些Port每一个都可以连接一个PCIe设备（Type 0或者Type 1）。

本质上，所有这些连接其他设备用的部件都是由桥（Bridge）来实现的，这些桥的两端连接着两个不同的PCIe Bus（Bus Number不同）。比如，一个Root Port其实是靠两个Bridge来实现的：一个（共享的）Host Bridge（上游连接着CPU，下游连接着Bus 0）和一个PCI Bridge用来连接下游设备（上游连着的是Bus 0（Root Complex），下游连着的PCIe的设备（Bus Number在启动过程中自动分配）） [1]。

我们通过lspci命令可以看到这些桥的存在（注意设备详情中的Kernel driver in use: pcieport）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 +-[0000:80]-+-00.0  Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex
             # This is the Host bridge that connects to the root port and CPU:
 |           +-01.0  Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
             # This is the PCI bridge that connects to the root port and device with a new bus - 0x81:
 |           +-01.1-[81]--+-00.0  NVIDIA Corporation TU104 [GeForce RTX 2080]
 |           |            +-00.1  NVIDIA Corporation TU104 HD Audio Controller
 |           |            +-00.2  NVIDIA Corporation TU104 USB 3.1 Host Controller
 |           |            \-00.3  NVIDIA Corporation TU104 USB Type-C UCSI Controller

# Host bridge
$ sudo lspci -s 80:01.0 -v
80:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
        Flags: fast devsel, IOMMU group 13

# PCI bridge
$ sudo lspci -s 80:01.1 -v
80:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0, IRQ 35, IOMMU group 13
        Bus: primary=80, secondary=81, subordinate=81, sec-latency=0
        I/O behind bridge: 0000b000-0000bfff [size=4K]
        Memory behind bridge: f0000000-f10fffff [size=17M]
        Prefetchable memory behind bridge: 0000020030000000-00000200420fffff [size=289M]
        ....
        Kernel driver in use: pcieport

注意：是否使用PCIe Bridge和是否通过插槽连接不能直接划等号，这取决于你系统的硬件实现，比如，从上面RCIE的截图中我们可以看到USB Controller作为RCIE存在，而下面EPYC的CPU则不同，USB控制器是通过Root Port连接的，但是它在主板上并没有插槽。

1
2
3
4
5
6
$ lspci -t -v
 +-[0000:40]-+-00.0  Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex
             +-03.0  Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
 |           +-03.3-[42]----00.0  ASMedia Technology Inc. ASM1042A USB 3.0 Host Controller
             # ^====== 40:03.3 here is a Bridge. And USB controller is connected
             #         to this Bridge with a new Bus Number 42.

4.5. Switch

如果我们需要连接不止一个设备怎么办呢？这时候就需要用到PCIe Switch了。

PCIe Switch内部主要有三个部分：

  • 一个Upstream Port和Bridge：用于连接到上游的Port，比如，Root Port或者上游Switch的Downstream Port
  • 一组Downstream Port和Bridge：用于连接下游的设备，比如，显卡，网卡，或者下游Switch的Upstream Port
  • 一根虚拟总线：用于将上游和下游的所有端口连接起来，这样，上游的Port就可以访问下游的设备了

另外，这里再说明一次 —— 由于PCIe的信号传输是点对点的，所以Switch中间的这个总线只是一个逻辑上的虚拟的总线，其实并不存在，里面真正的结构是一套用于转发的交换电路 [9]。

最后，看到这里也许你会突然想到Root Complex是不是也可以看成是一个Switch呢？我觉得这两个概念最好还是分开，虽然从很多框图上看着确实很像，只不过Root Complex没有Upstream Port，连接上游的Host Bridge是连接到CPU上，不过Root Complex内部的功能要远比Switch复杂的多，里面不仅仅是简单的包转发，比如，后面会说到的PCIe请求的生成和转换等等。

5. 小结

好了，到这里我们已经将PCIe设备树中的主要部件都介绍完毕了。如果我们把所有这些部件连接在一起，那么其整体的结构就是这样的 [10]：

好的，为了避免文章过长，我们这一篇就先到这里，后面有时间再继续总结和PCIe相关的其他知识，比如配置空间和域，消息和消息路由等等。

6. 参考资料

同系列文章：
原创文章，转载请标明出处：Soul Orbit
本文链接地址：PCIe（一） —— 基础概念与设备树]]> <p>PCIe的全称是Peripheral Component Interconnect Express，是一种用于连接外设的总线。它于2003年提出来，作为替代PCI和PCI-X的方案，现在已经成了现代CPU和其他几乎所有外设交互的标准或者基石，比如，我们马上能想到的GPU，网卡，USB控制器，声卡，网卡等等，这些都是通过PCIe总线进行连接的，然后现在非常常见的基于m.2接口的SSD，也是使用NVMe协议，通过PCIe总线进行连接的，除此以外，Thunderbolt 3 <a href="https://www.thunderbolttechnology.net/sites/default/files/18-241_Thunder7000Controller_Brief_FIN_HI.pdf">[2]</a>，USB4 <a href="https://www.usb.org/document-library/usb4r-specification-v20">[3]</a>，甚至最新的CXL互联协议 <a href="https://www.computeexpresslink.org/download-the-specification">[4]</a>，都是基于PCIe的！</p> <p>所以一旦开始往设备相关的开发上面走了之后，PCIe可以算是一个绕不过的坎。这几天看了一些和PCIe相关的资料，这里简单的总结一下，也希望对大家有所帮助。这篇文章主要会聚焦在硬件的部分，和操作系统本身没有什么太大的关系，无论是Windows还是Linux，底层的部分都是非常类似的，文章中也会提到调试的方法，不过会主要以Linux为主。</p> <p>那我们就开始吧！</p> 在Hexo中使用MathJax http://r12f.com/posts/use-mathjax-in-hexo/ 2023-05-19T21:50:09.000Z 2023-05-19T21:50:09.000Z Hexo虽然可以通过一些方法来支持MathJax，比如next主题或者Hexo Filter MathJax，但是它们都提到了默认renderer的兼容性问题，并且说最好是换成pandoc，不过我切换成pandoc之后所有的页面渲染却全都失败了……整个博客都瘫痪了，正当我快放弃的时候，突然发现hexo-renderer-markdown-it好像兼容的还不错，所以遇到了类似问题的小伙伴，可以也试一试这个～

以下是一些常用的测试和效果：

  • _会被hexo-renderer-marked转义导致失败：
    • $\epsilon_0$：$\epsilon_0$
  • *会被转义导致失败
    • $\begin{eqnarray*}\nabla\cdot\vec{E}&=&\frac{\rho}{\epsilon_0}\end{eqnarray*}$：$\begin{eqnarray*}\nabla\cdot\vec{E}&=&\frac{\rho}{\epsilon_0}\end{eqnarray*}$
  • 其他一些测试：
    • $\frac{\partial}{\partial t}$：$\frac{\partial}{\partial t}$

这里可以看到，即便是使用"`"包裹的代码，也没有什么问题！挺好～

关于配置方法，需要先卸载自带的renderer，然后安装hexo-renderer-markdown-it。

1
2
npm un hexo-renderer-marked --save
npm i hexo-renderer-markdown-it --save

另外因为我使用的是next主题，所以直接在_config.yml中修改配置启用即可：

1
2
3
4
5
6
7
8
9
10
math:
  # Default (false) will load mathjax / katex script on demand.
  # That is it only render those page which has `mathjax: true` in front-matter.
  # If you set it to true, it will load mathjax / katex script EVERY PAGE.
  every_page: true

  mathjax:
    enable: true
    # Available values: none | ams | all
    tags: ams
原创文章，转载请标明出处：Soul Orbit
本文链接地址：在Hexo中使用MathJax]]> <p>Hexo虽然可以通过一些方法来支持MathJax，比如<a href="https://github.com/theme-next/hexo-theme-next/blob/master/docs/MATH.md">next主题</a>或者<a href="https://github.com/next-theme/hexo-filter-mathjax">Hexo Filter MathJax</a>，但是它们都提到了默认renderer的兼容性问题，并且说最好是换成pandoc，不过我切换成pandoc之后所有的页面渲染却全都失败了……整个博客都瘫痪了，正当我快放弃的时候，突然发现<a href="https://github.com/hexojs/hexo-renderer-markdown-it">hexo-renderer-markdown-it</a>好像兼容的还不错，所以遇到了类似问题的小伙伴，可以也试一试这个～</p> <p>以下是一些常用的测试和效果：</p> <ul> <li><code>_</code>会被<code>hexo-renderer-marked</code>转义导致失败： <ul> <li><code>$\epsilon_0$</code>：$\epsilon_0$</li> </ul> </li> <li><code>*</code>会被转义导致失败 <ul> <li><code>$\begin&#123;eqnarray*&#125;\nabla\cdot\vec&#123;E&#125;&amp;=&amp;\frac&#123;\rho&#125;&#123;\epsilon_0&#125;\end&#123;eqnarray*&#125;$</code>：$\begin{eqnarray*}\nabla\cdot\vec{E}&amp;=&amp;\frac{\rho}{\epsilon_0}\end{eqnarray*}$</li> </ul> </li> <li>其他一些测试： <ul> <li><code>$\frac&#123;\partial&#125;&#123;\partial t&#125;$</code>：$\frac{\partial}{\partial t}$</li> </ul> </li> </ul> <p>这里可以看到，即便是使用&quot;`&quot;包裹的代码，也没有什么问题！挺好～</p> 在Hexo中使用WaveDrom http://r12f.com/posts/use-wavedrom-in-hexo/ 2023-05-19T18:27:32.000Z 2023-05-19T18:27:32.000Z 画数字时序图怎么能没有WaveDrom呢？所以必须整一个！给正在用的Hexo皮肤Next添加了WaveDrom的支持，现在可以在文章中直接使用WaveDrom了！效果如下：

代码也很简单，都是使用js直接绘制，不需要额外的向其他服务器发送请求：

1
2
3
4
5
6
7
{% wavedrom %}
{ signal : [
  { name: "clk",  wave: "p......" },
  { name: "bus",  wave: "x.34.5x",   data: "head body tail" },
  { name: "wire", wave: "0.1..0." },
]}
{% endwavedrom %}

PR还在review中，希望能顺利通过，等合并了我再更新一下这篇文章。

对WaveDrom感兴趣的朋友，也可以围观以下这两篇文章，真的是非常方便的：

原创文章，转载请标明出处：Soul Orbit
本文链接地址：在Hexo中使用WaveDrom]]> <p>画数字时序图怎么能没有WaveDrom呢？所以必须整一个！给正在用的Hexo皮肤Next添加了WaveDrom的支持，现在可以在文章中直接使用WaveDrom了！效果如下：</p> <div class="wavedrom"><script type="WaveDrom"> { signal : [ { name: "clk", wave: "p......" }, { name: "bus", wave: "x.34.5x", data: "head body tail" }, { name: "wire", wave: "0.1..0." }, ]} </script></div> SONiC学习笔记（四）：通信机制 http://r12f.com/posts/sonic-4-communication/ 2023-05-09T14:55:00.000Z 2023-05-09T21:55:00.000Z 在大概了解了各个服务和源码仓库之后，相信大家已经对可以开始自如的浏览SONiC的源码了，所以这一篇文章中，我们就来看看SONiC中最常用的组件 - 通信机制。

SONiC中主要的通信机制有两种：与内核的通信和基于Redis的服务间的通信。所有的实现都在sonic-swss-common这个repo中的common目录下。我们这里就来看看这两种通信机制的实现吧！

1. 与内核的通信

1.1. 命令行调用

SONiC中的与内核通信最简单的方式就是命令行调用了，其实现放在common/exec.h文件下，且十分简单，接口如下：

1
2
3
// File: common/exec.h
// Namespace: swss
int exec(const std::string &cmd, std::string &stdout);

其中，cmd是要执行的命令，stdout是命令执行的输出。这里的exec函数是一个同步调用，调用者会一直阻塞，直到命令执行完毕。其内部通过调用popen函数来创建子进程，并且通过fgets函数来获取输出。不过，虽然这个函数返回了输出，但是基本上并没有人使用，而只是通过返回值来判断是否成功，甚至连错误log中都不会写入输出的结果。

这个函数虽然粗暴，但是使用广泛，特别是在各个*mgrd服务中，比如portmgrd中就用它来设置每一个Port的状态等等。

1
2
3
4
5
6
7
8
9
10
11
12
// File: sonic-swss - cfgmgr/portmgr.cpp
bool PortMgr::setPortAdminStatus(const string &alias, const bool up)
{
    stringstream cmd;
    string res, cmd_str;

    // ip link set dev <port_name> [up|down]
    cmd << IP_CMD << " link set dev " << shellquote(alias) << (up ? " up" : " down");
    cmd_str = cmd.str();
    int ret = swss::exec(cmd_str, res);

    // ...

为什么说命令行调用是一种通信机制呢？原因是当*mgrd服务调用exec函数对系统进行的修改，会触发下面马上会提到的netlink事件，从而通知其他服务进行相应的修改，比如*syncd，这样就间接的构成了一种通信。所以这里我们把命令行调用看作一种通信机制能帮助我们以后更好的理解SONiC的各种工作流。

Netlink是Linux内核中用于内核与用户空间进程之间的一种基于消息的通信机制。它通过套接字接口和自定义的协议族来实现，可以用来传递各种类型的内核消息，包括网络设备状态、路由表更新、防火墙规则变化、系统资源使用情况等等。而SONiC的*sync服务就大量使用了Netlink的机制来监听系统中网络设备的变化，并将最新的状态同步到Redis中，并通知其他服务进行相应的修改。

Netlink的实现主要在这几个文件中：common/netmsg.*、common/netlink.* 和 common/netdispatcher.*，具体类图如下：

其中：

  • Netlink：封装了Netlink的套接字接口，提供了Netlink消息的接口和接收消息的回调。
  • NetDispatcher：它是一个单例，提供了Handler注册的接口。当Netlink类接收到原始的消息后，就会调用NetDispatcher将其解析成nl_onject，并根据消息的类型调用相应的Handler。
  • NetMsg：Netlink消息Handler的基类，仅提供了onMsg的接口，其中没有实现。

举一个例子，当portsyncd启动的时候，它会创建一个Netlink对象，用来监听Link相关的状态变化，并且会实现NetMsg的接口，对Link相关的消息进行处理。具体的实现如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// File: sonic-swss - portsyncd/portsyncd.cpp
int main(int argc, char **argv)
{
    // ...

    // Create Netlink object to listen to link messages
    NetLink netlink;
    netlink.registerGroup(RTNLGRP_LINK);

    // Here SONiC request a fulldump of current state, so that it can get the current state of all links
    netlink.dumpRequest(RTM_GETLINK);      
    cout << "Listen to link messages..." << endl;
    // ...

    // Register handler for link messages
    LinkSync sync(&appl_db, &state_db);
    NetDispatcher::getInstance().registerMessageHandler(RTM_NEWLINK, &sync);
    NetDispatcher::getInstance().registerMessageHandler(RTM_DELLINK, &sync);

    // ...
}

上面的LinkSync，就是一个NetMsg的实现，它实现了onMsg接口，用来处理Link相关的消息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// File: sonic-swss - portsyncd/linksync.h
class LinkSync : public NetMsg
{
public:
    LinkSync(DBConnector *appl_db, DBConnector *state_db);

    // NetMsg interface
    virtual void onMsg(int nlmsg_type, struct nl_object *obj);

    // ...
};

// File: sonic-swss - portsyncd/linksync.cpp
void LinkSync::onMsg(int nlmsg_type, struct nl_object *obj)
{
    // ...

    // Write link state to Redis DB
    FieldValueTuple fv("oper_status", oper ? "up" : "down");
    vector<FieldValueTuple> fvs;
    fvs.push_back(fv);
    m_stateMgmtPortTable.set(key, fvs);
    // ...
}

2. 基于Redis的服务间通信

除了和内核的通信接口，SONiC还在Redis的基础上提供了一组PubSub的服务间通信的接口，我们这里就自底向上的来看看这些接口的实现吧！

（虽然SONiC的repo中并没有将以下的代码放在不同的目录下，但是为了方便建立一个清晰的模型，这里我还是会将他们按照层次分开来描述。）

2.1. Redis数据库操作层

第一层，也是最底层，是Redis的数据库操作层，封装了各种基本命令，比如，DB的连接，命令的执行，事件通知的回调接口等等。具体的类图如下：

其中：

  • RedisContext：封装并保持着与Redis的连接，当其销毁时会将其连接关闭。
  • DBConnector：封装了所有的底层使用到的Redis的命令，比如SET、GET、DEL等等。
  • RedisTransactioner：封装了Redis的事务操作，用于在一个事务中执行多个命令，比如MULTI、EXEC等等。
  • RedisPipeline：封装了hiredis的redisAppendFormattedCommand API，提供了一个类似队列的异步的执行Redis命令的接口（虽然大部分使用方法依然是同步的）。它也是少有的对SCRIPT LOAD命令进行了封装的类，用于在Redis中加载Lua脚本实现存储过程。SONiC中绝大部分需要执行Lua脚本的类，都会使用这个类来进行加载和调用。
  • RedisSelect：它实现了Selectable的接口，用来支持基于epoll的事件通知机制（Event Polling）。主要是在我们收到了Redis的回复，用来触发epoll进行回调（我们最后会更详细的介绍）。
  • SonicDBConfig：这个类是一个“静态类”，它主要实现了SONiC DB的配置文件的读取和解析。其他的数据库操作类，如果需要任何的配置信息，都会通过这个类来获取。

2.2. 表（Table）抽象层

在Redis数据库操作层之上，便是SONiC自己利用Redis中间的Key建立的表（Table）的抽象了，因为每一个Redis的Key的格式都是<table-name><separator><key-name>，所以SONiC在访问数据库时需要对其进行一次转换（没有印象的小伙伴可以移步我之前的博客了解更多的信息）。

相关类的主要类图如下：

其中关键的类有三个：

  • TableBase：这个类是所有表的基类，它主要封装了表的基本信息，如表的名字，Redis Key的打包，每个表发生修改时用于通信的Channel的名字，等等。
  • Table：这个类就是对于每个表增删改查的封装了，里面包含了表的名称和分隔符，这样就可以在调用时构造最终的key了。
  • ConsumerTableBase：这个类是各种SubscriptionTable的基类，里面主要是封装了一个简单的队列和其pop操作（对，只有pop，没有push），用来给上层调用。

2.3. 通信层

在表抽象层之上，便是SONiC的通信层了，由于需求的不同，这一层中提供了四种不同的PubSub的封装，用于服务间的通信。

2.3.1. SubscriberStateTable

最直接的就是SubscriberStateTable了。

它的原理是利用Redis数据库中自带的keyspace消息通知机制 [6] —— 当数据库中的任何一个key对应的值发生了变化，就会触发Redis发送两个keyspace的事件通知，一个是__keyspace@<db-id>__:<key>下的<op>事件，一个是__keyspace@<db-id>__:<op>下的<key>>事件，比如，在数据库0中删除了一个key，那么就会触发两个事件通知：

1
2
PUBLISH __keyspace@0__:foo del
PUBLISH __keyevent@0__:del foo

而SubscriberStateTable就是监听了第一个事件通知，然后调用相应的回调函数。和其直接相关的主要的类的类图如下，这里可以看到它继承了ConsumerTableBase，因为它是Redis的消息的Consumer：

在初始化时，我们可以看到它是如何订阅Redis的事件通知的：

1
2
3
4
5
6
7
8
// File: sonic-swss-common - common/subscriberstatetable.cpp
SubscriberStateTable::SubscriberStateTable(DBConnector *db, const string &tableName, int popBatchSize, int pri)
    : ConsumerTableBase(db, tableName, popBatchSize, pri), m_table(db, tableName)
{
    m_keyspace = "__keyspace@";
    m_keyspace += to_string(db->getDbId()) + "__:" + tableName + m_table.getTableNameSeparator() + "*";
    psubscribe(m_db, m_keyspace);
    // ...

其事件接收和分发主要由两个函数负责：

  • readData()负责将redis中待读取的事件读取出来，并放入ConsumerTableBase中的队列中
  • pops()：负责将队列中的原始事件取出来，并且进行解析，然后通过函数参数传递给调用方
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// File: sonic-swss-common - common/subscriberstatetable.cpp
uint64_t SubscriberStateTable::readData()
{
    // ...
    reply = nullptr;
    int status;
    do {
        status = redisGetReplyFromReader(m_subscribe->getContext(), reinterpret_cast<void**>(&reply));
        if(reply != nullptr && status == REDIS_OK) {
            m_keyspace_event_buffer.emplace_back(make_shared<RedisReply>(reply));
        }
    } while(reply != nullptr && status == REDIS_OK);
    // ...
    return 0;
}

void SubscriberStateTable::pops(deque<KeyOpFieldsValuesTuple> &vkco, const string& /*prefix*/)
{
    vkco.clear();
    // ...

    // Pop from m_keyspace_event_buffer, which is filled by readData()
    while (auto event = popEventBuffer()) {
        KeyOpFieldsValuesTuple kco;
        // Parsing here ...
        vkco.push_back(kco);
    }

    m_keyspace_event_buffer.clear();
}

2.3.2. NotificationProducer / NotificationConsumer

既然说到消息通信，我们很容易就会联想到消息队列，而这就是我们的第二种通信方式 —— NotificationProducer和NotificationConsumer。

这种通信方式通过Redis的自带的PubSub来实现，主要是对PUBLISH和SUBSCRIBE命令的包装，很有限的应用在最简单的通知型的场景中，比如orchagent中的timeout check, restart check之类，非传递用户配置和数据的场景：

这种通信模式下，消息的发送方Producer，主要会做两件事情：一是将消息打包成JSON格式，二是调用Redis的PUBLISH命令将消息发送出去。而且由于PUBLISH命令只能携带一个消息，所以请求中的op和data字段会被放在values的最前面，然后再调用buildJson函数将其打包成一个JSON数组的格式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
int64_t swss::NotificationProducer::send(const std::string &op, const std::string &data, std::vector<FieldValueTuple> &values)
{
    // Pack the op and data into values array, then pack everything into a JSON string as the message
    FieldValueTuple opdata(op, data);
    values.insert(values.begin(), opdata);
    std::string msg = JSon::buildJson(values);
    values.erase(values.begin());

    // Publish message to Redis channel
    RedisCommand command;
    command.format("PUBLISH %s %s", m_channel.c_str(), msg.c_str());
    // ...
    RedisReply reply = m_pipe->push(command);
    reply.checkReplyType(REDIS_REPLY_INTEGER);
    return reply.getReply<long long int>();
}

接收方则是利用SUBSCRIBE命令来接收所有的通知：

1
2
3
4
5
6
7
8
9
10
11
12
void swss::NotificationConsumer::subscribe()
{
    // ...
    m_subscribe = new DBConnector(m_db->getDbId(),
                                    m_db->getContext()->unix_sock.path,
                                    NOTIFICATION_SUBSCRIBE_TIMEOUT);
    // ...

    // Subscribe to Redis channel
    std::string s = "SUBSCRIBE " + m_channel;
    RedisReply r(m_subscribe, s, REDIS_REPLY_ARRAY);
}

2.3.3. ProducerTable / ConsumerTable

我们可以看到NotificationProducer/Consumer实现简单粗暴，但是由于API的限制 [8]，它并不适合用来传递数据，所以，SONiC中提供了一种和它非常接近的另外一种基于消息队列的通信机制 —— ProducerTable和ConsumerTable。

这种通信方式通过Redis的List来实现，和Notification不同的地方在于，发布给Channel中的消息非常的简单（单字符"G"），所有的数据都存储在List中，从而解决了Notification中消息大小限制的问题。在SONiC中，它主要用在FlexCounter，syncd服务和ASIC_DB中：

  1. 消息格式：每条消息都是一个（Key, FieldValuePairs, Op）的三元组，如果用JSON来表达这个消息，那么它的格式如下：（这里的Key是Table中数据的Key，被操作的数据是Hash，所以Field就是Hash中的Field，Value就是Hash中的Value了，也就是说一个消息可以对很多个Field进行操作）

    1
    [ "Key", "[\"Field1\", \"Value1\", \"Field2", \"Value2\", ...]", "Op" ]

  2. Enqueue：ProducerTable通过Lua脚本将消息三元组原子的写入消息队列中（Key = <table-name>_KEY_VALUE_OP_QUEUE，并且发布更新通知到特定的Channel（Key = <table-name>_CHANNEL）中。

  3. Pop：ConsumerTable也通过Lua脚本从消息队列中原子的读取消息三元组，并在读取过程中将其中请求的改动真正的写入到数据库中。

注意：Redis中Lua脚本和MULTI/EXEC的原子性和通常说的数据库ACID中的原子性（Atomicity）不同，Redis中的原子性其实更接近于ACID中的隔离性（Isolation），他保证Lua脚本中所有的命令在执行的时候不会有其他的命令执行，但是并不保证Lua脚本中的所有命令都会执行成功，比如，如果Lua脚本中的第二个命令执行失败了，那么第一个命令依然会被提交，只是后面的命令就不会继续执行了。更多的细节可以参考Redis官方文档 [4] [5]。

其主要类图如下，这里我们可以看到在ProducerTable中的m_shaEnqueue和ConsumerTable中的m_shaPop，它们就是上面我们提到的这两个Lua脚本在加载时获得的SHA了，而之后我们就可以使用Redis的EVALSHA命令对他们进行原子的调用了：

ProducerTable的核心逻辑如下，我们可以看到对Values的JSON打包，和使用EVALSHA来进行Lua脚本的调用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// File: sonic-swss-common - common/producertable.cpp
ProducerTable::ProducerTable(RedisPipeline *pipeline, const string &tableName, bool buffered)
    // ...
{
    string luaEnque =
        "redis.call('LPUSH', KEYS[1], ARGV[1], ARGV[2], ARGV[3]);"
        "redis.call('PUBLISH', KEYS[2], ARGV[4]);";

    m_shaEnque = m_pipe->loadRedisScript(luaEnque);
}

void ProducerTable::set(const string &key, const vector<FieldValueTuple> &values, const string &op, const string &prefix)
{
    enqueueDbChange(key, JSon::buildJson(values), "S" + op, prefix);
}

void ProducerTable::del(const string &key, const string &op, const string &prefix)
{
    enqueueDbChange(key, "{}", "D" + op, prefix);
}

void ProducerTable::enqueueDbChange(const string &key, const string &value, const string &op, const string& /* prefix */)
{
    RedisCommand command;

    command.format(
        "EVALSHA %s 2 %s %s %s %s %s %s",
        m_shaEnque.c_str(),
        getKeyValueOpQueueTableName().c_str(),
        getChannelName(m_pipe->getDbId()).c_str(),
        key.c_str(),
        value.c_str(),
        op.c_str(),
        "G");

    m_pipe->push(command, REDIS_REPLY_NIL);
}

而另一侧的ConsumerTable就稍稍复杂一点，因为其支持的op类型很多，所以逻辑都写在了一个单独的文件中（common/consumer_table_pops.lua），我们这里就不贴代码了，有兴趣的同学可以自己去看看。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// File: sonic-swss-common - common/consumertable.cpp
ConsumerTable::ConsumerTable(DBConnector *db, const string &tableName, int popBatchSize, int pri)
    : ConsumerTableBase(db, tableName, popBatchSize, pri)
    , TableName_KeyValueOpQueues(tableName)
    , m_modifyRedis(true)
{
    std::string luaScript = loadLuaScript("consumer_table_pops.lua");
    m_shaPop = loadRedisScript(db, luaScript);
    // ...
}

void ConsumerTable::pops(deque<KeyOpFieldsValuesTuple> &vkco, const string &prefix)
{
    // Note that here we are processing the messages in bulk with POP_BATCH_SIZE!
    RedisCommand command;
    command.format(
        "EVALSHA %s 2 %s %s %d %d",
        m_shaPop.c_str(),
        getKeyValueOpQueueTableName().c_str(),
        (prefix+getTableName()).c_str(),
        POP_BATCH_SIZE,

    RedisReply r(m_db, command, REDIS_REPLY_ARRAY);
    vkco.clear();

    // Parse and pack the messages in bulk
    // ...
}

2.3.4. ProducerStateTable / ConsumerStateTable

Producer/ConsumerTable虽然直观，而且保序，但是它一个消息只能处理一个Key，并且还需要JSON的序列化，然而很多时候我们并用不到保序的功能，反而更需要更大的吞吐量，所以为了优化性能，SONiC就引入了第四种通信方式，也是最常用的通信方式：ProducerStateTable和ConsumerStateTable。

与ProducerTable不同，ProducerStateTable使用Hash的方式来存储消息，而不是List。这样虽然不能保证消息的顺序，但是却可以很好的提升性能！首先，我们省下了JSON的序列化的开销，其次，对于同一个Key下的相同的Field如果被变更多次，那么只需要保留最后一次的变更，这样就将关于这个Key的所有变更消息就合并成了一条，减少了很多不必要的消息处理。

Producer/ConsumerStateTable的底层实现相比于Producer/ConsumerTable也更加复杂一些。其相关联的类的主要类图如下，这里我们依然可以看到它的实现是通过EVALSHA调用Lua脚本来实现的，m_shaSet和m_shaDel就是用来存放修改和发送消息的，而另一边m_shaPop就是用来获取消息的：

在传递消息时：

  • 首先，每个消息会被存放成两个部分：一个是KEY_SET，用来保存当前有哪些Key发生了修改，它以Set的形式存放在<table-name_KEY_SET>的key下，另一个是所有被修改的Key的内容，它以Hash的形式存放在_<redis-key-name>的key下。

  • 然后，消息存放之后Producer如果发现是新的Key，那么就是调用PUBLISH命令，来通知<table-name>_CHANNEL@<db-id>Channel，有新的Key出现了。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    // File: sonic-swss-common - common/producerstatetable.cpp
    ProducerStateTable::ProducerStateTable(RedisPipeline *pipeline, const string &tableName, bool buffered)
        : TableBase(tableName, SonicDBConfig::getSeparator(pipeline->getDBConnector()))
        , TableName_KeySet(tableName)
        // ...
    {
        string luaSet =
            "local added = redis.call('SADD', KEYS[2], ARGV[2])\n"
            "for i = 0, #KEYS - 3 do\n"
            "    redis.call('HSET', KEYS[3 + i], ARGV[3 + i * 2], ARGV[4 + i * 2])\n"
            "end\n"
            " if added > 0 then \n"
            "    redis.call('PUBLISH', KEYS[1], ARGV[1])\n"
            "end\n";

        m_shaSet = m_pipe->loadRedisScript(luaSet);

  • 最后，Consumer会通过SUBSCRIBE命令来订阅<table-name>_CHANNEL@<db-id>Channel，一旦有新的消息到来，就会使用Lua脚本调用HGETALL命令来获取所有的Key，并将其中的值读取出来并真正的写入到数据库中去。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    ConsumerStateTable::ConsumerStateTable(DBConnector *db, const std::string &tableName, int popBatchSize, int pri)
        : ConsumerTableBase(db, tableName, popBatchSize, pri)
        , TableName_KeySet(tableName)
    {
        std::string luaScript = loadLuaScript("consumer_state_table_pops.lua");
        m_shaPop = loadRedisScript(db, luaScript);
        // ...

        subscribe(m_db, getChannelName(m_db->getDbId()));
        // ...

为了方便理解，我们这里举一个例子：启用Port Ethernet0：

  • 首先，我们在命令行下调用config interface startup Ethernet0来启用Ethernet0，这会导致portmgrd通过ProducerStateTable向APP_DB发送状态更新消息，如下：

    1
    2
    3
    EVALSHA "<hash-of-set-lua>" "6" "PORT_TABLE_CHANNEL@0" "PORT_TABLE_KEY_SET" 
        "_PORT_TABLE:Ethernet0" "_PORT_TABLE:Ethernet0" "_PORT_TABLE:Ethernet0" "_PORT_TABLE:Ethernet0" "G"
        "Ethernet0" "alias" "Ethernet5/1" "index" "5" "lanes" "9,10,11,12" "speed" "40000"

    这个命令会在其中调用如下的命令来创建和发布消息：

    1
    2
    3
    4
    5
    6
    SADD "PORT_TABLE_KEY_SET" "_PORT_TABLE:Ethernet0"
    HSET "_PORT_TABLE:Ethernet0" "alias" "Ethernet5/1"
    HSET "_PORT_TABLE:Ethernet0" "index" "5"
    HSET "_PORT_TABLE:Ethernet0" "lanes" "9,10,11,12"
    HSET "_PORT_TABLE:Ethernet0" "speed" "40000"
    PUBLISH "PORT_TABLE_CHANNEL@0" "_PORT_TABLE:Ethernet0"

    所以最终这个消息会在APPL_DB中被存放成如下的形式：

    1
    2
    3
    4
    5
    6
    7
    8
    PORT_TABLE_KEY_SET:
      _PORT_TABLE:Ethernet0

    _PORT_TABLE:Ethernet0:
      alias: Ethernet5/1
      index: 5
      lanes: 9,10,11,12
      speed: 40000

  • 当ConsumerStateTable收到消息后，也会调用EVALSHA命令来执行Lua脚本，如下：

    1
    EVALSHA "<hash-of-pop-lua>" "3" "PORT_TABLE_KEY_SET" "PORT_TABLE:" "PORT_TABLE_DEL_SET" "8192" "_"

    和Producer类似，这个脚本会执行如下命令，将PORT_TABLE_KEY_SET中的key，也就是_PORT_TABLE:Ethernet0读取出来，然后再将其对应的Hash读取出来，并更新到PORT_TABLE:Ethernet0去，同时将_PORT_TABLE:Ethernet0从数据库和PORT_TABLE_KEY_SET中删除。

    1
    2
    3
    4
    5
    6
    7
    SPOP "PORT_TABLE_KEY_SET" "_PORT_TABLE:Ethernet0"
    HGETALL "_PORT_TABLE:Ethernet0"
    HSET "PORT_TABLE:Ethernet0" "alias" "Ethernet5/1"
    HSET "PORT_TABLE:Ethernet0" "index" "5"
    HSET "PORT_TABLE:Ethernet0" "lanes" "9,10,11,12"
    HSET "PORT_TABLE:Ethernet0" "speed" "40000"
    DEL "_PORT_TABLE:Ethernet0"

    到这里，数据的更新才算是完成了。

2.4. 服务层：Orch

最后，为了方便各个服务使用，SONiC还在通信层上进行了更进一步的封装，为各个服务提供了一个基类：Orch。

由于有了上面这些封装，Orch中关于消息通信的封装就相对简单了，主要的类图如下：

注意：由于这一层是服务层，所以其代码是在sonic-swss的仓库中，而不是sonic-swss。这个类中除了消息通信的封装以外，还提供了很多和服务实现相关的公共函数，比如，日志文件等等。

可以看到，Orch主要是封装了SubscriberStateTable和ConsumerStateTable来简化和统一消息的订阅，核心代码非常简单，就是根据不同的数据库创建不同的Consumer，如下：

1
2
3
4
5
6
7
8
void Orch::addConsumer(DBConnector *db, string tableName, int pri)
{
    if (db->getDbId() == CONFIG_DB || db->getDbId() == STATE_DB || db->getDbId() == CHASSIS_APP_DB) {
        addExecutor(new Consumer(new SubscriberStateTable(db, tableName, TableConsumable::DEFAULT_POP_BATCH_SIZE, pri), this, tableName));
    } else {
        addExecutor(new Consumer(new ConsumerStateTable(db, tableName, gBatchSize, pri), this, tableName));
    }
}

3. 基于epoll的事件分发机制

好了，我们现在已经了解了所有关于消息通信机制的上层封装了，关于消息通信，还有一个很重要的就是消息的检测和分发，我们这里就也来看看吧！

和很多的Linux服务一样，SONiC底层使用了epoll作为事件分发机制：

  • 所有需要支持事件分发的类都需要继承Selectable类，并实现两个最核心的函数：int getFd();（用于返回epoll能用来监听事件的fd）和uint64_t readData()（用于在监听到事件到来之后进行读取）。而对于一般服务而言，这个fd就是redis通信使用的fd，所以getFd()函数的调用，都会被最终转发到Redis的库中。
  • 所有需要参与事件分发的对象，都需要注册到Select类中，这个类会将所有的Selectable对象的fd注册到epoll中，并在事件到来时调用Selectable的readData()函数。

其类图如下：

在Select类中，我们可以很容易的找到其最核心的代码，实现也非常的简单：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
int Select::poll_descriptors(Selectable **c, unsigned int timeout, bool interrupt_on_signal = false)
{
    int sz_selectables = static_cast<int>(m_objects.size());
    std::vector<struct epoll_event> events(sz_selectables);
    int ret;

    while(true) {
        ret = ::epoll_wait(m_epoll_fd, events.data(), sz_selectables, timeout);
        // ...
    }
    // ...

    for (int i = 0; i < ret; ++i)
    {
        int fd = events[i].data.fd;
        Selectable* sel = m_objects[fd];

        sel->readData();
        // error handling here ...

        m_ready.insert(sel);
    }

    while (!m_ready.empty())
    {
        auto sel = *m_ready.begin();
        m_ready.erase(sel);
        
        // After update callback ...
        return Select::OBJECT;
    }

    return Select::TIMEOUT;
}

然而，问题来了…… 回调呢？我们上面提过，readData()只是把消息读出来放在一个待处理队列中，并不会真正的处理消息，真正的消息处理需要调用pops()函数，将消息拿出来处理，所以什么地方会调用每一个上层封装的消息处理呢？

这里我们还是找到我们的老朋友portmgrd的main函数，从下面简化的代码中，我们可以看到和一般的Event Loop实现不同，SONiC中，最后的事件处理不是通过回调来实现的，而是需要最外层的Event Loop来主动调用完成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
int main(int argc, char **argv)
{
    // ...

    // Create PortMgr, which implements Orch interface.
    PortMgr portmgr(&cfgDb, &appDb, &stateDb, cfg_port_tables);
    vector<Orch *> cfgOrchList = {&portmgr};

    // Create Select object for event loop and add PortMgr to it.
    swss::Select s;
    for (Orch *o : cfgOrchList) {
        s.addSelectables(o->getSelectables());
    }

    // Event loop
    while (true)
    {
        Selectable *sel;
        int ret;

        // When anyone of the selectables gets signaled, select() will call
        // into readData() and fetch all events, then return.
        ret = s.select(&sel, SELECT_TIMEOUT);
        // ...

        // Then, we call into execute() explicitly to process all events.
        auto *c = (Executor *)sel;
        c->execute();
    }
    return -1;
}

4. 错误处理

关于Event Loop我们还有最后一个问题，那就是错误处理，比如，如果Redis的命令执行出错了，连接断开了，故障了等等的情况下，我们的服务会发生什么呢？

从代码上来看，SONiC中的错误处理是非常简单的，就是直接抛出异常（比如，获取命令执行结果的代码，如下），然后在Event Loop中捕获异常，打印日志，接着继续执行。关于异常和错误的种类及其原因，在代码里面并没有看到用于统计和Telemetry的代码，所以监控上说是比较薄弱的。另外还需要考虑数据出错的场景，比如数据库写到一半突然断开导致的脏数据，不过简单的重启相关的*syncd和*mgrd服务可能可以解决此类问题，因为启动时会进行全量同步。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
RedisReply::RedisReply(RedisContext *ctx, const RedisCommand& command)
{
    int rc = redisAppendFormattedCommand(ctx->getContext(), command.c_str(), command.length());
    if (rc != REDIS_OK)
    {
        // The only reason of error is REDIS_ERR_OOM (Out of memory)
        // ref: https://github.com/redis/hiredis/blob/master/hiredis.c
        throw bad_alloc();
    }

    rc = redisGetReply(ctx->getContext(), (void**)&m_reply);
    if (rc != REDIS_OK)
    {
        throw RedisError("Failed to redisGetReply with " + string(command.c_str()), ctx->getContext());
    }
    guard([&]{checkReply();}, command.c_str());
}

5. 总结

好了，这就是所有和SONiC中内核和服务间通信相关的所有内容了，之后有时间，我们再来深入的看看一些有特色的工作流或者模块吧！

6. 参考资料

同系列文章：
原创文章，转载请标明出处：Soul Orbit
本文链接地址：SONiC学习笔记（四）：通信机制]]> <p>在大概了解了<a href="/posts/sonic-2-key-components/">各个服务</a>和<a href="/posts/sonic-3-code-repos/">源码仓库</a>之后，相信大家已经对可以开始自如的浏览SONiC的源码了，所以这一篇文章中，我们就来看看SONiC中最常用的组件 - 通信机制。</p> <p>SONiC中主要的通信机制有两种：与内核的通信和基于Redis的服务间的通信。所有的实现都在<a href="https://github.com/sonic-net/sonic-swss-common">sonic-swss-common</a>这个repo中的<code>common</code>目录下。我们这里就来看看这两种通信机制的实现吧！</p> SONiC学习笔记（三）：代码仓库 http://r12f.com/posts/sonic-3-code-repos/ 2023-05-01T19:16:37.000Z 2023-05-02T02:16:37.000Z 在上一章中，我们了解了SONiC的整体设计和核心组件，为我们提供了一副看代码的地图，所以这一章，我们就来从代码的级别来继续了解SONiC吧！

SONiC的代码都托管在GitHub的sonic-net账号上，仓库数量有30几个之多，所以刚开始看SONiC的代码时，肯定是会有点懵的，不过不用担心，我们这里就来一起看看～

1. 核心仓库

首先是SONiC中最重要的两个核心仓库：SONiC和sonic-buildimage。

1.1. Landing仓库：SONiC

https://github.com/sonic-net/SONiC

这个仓库里面存储着SONiC的Landing Page和大量的文档，Wiki，教程，以往的Talk的Slides，等等等等。这个仓库可以说是每个新人上手最常用的仓库了，但是注意，这个仓库里面没有任何的代码，只有文档。

1.2. 镜像构建仓库：sonic-buildimage

https://github.com/sonic-net/sonic-buildimage

这个构建仓库为什么对于我们十分重要？和其他项目不同，SONiC的构建仓库其实才是它的主仓库！这个仓库里面包含：

  • 所有的功能实现仓库，它们都以submodule的形式被加入到了这个仓库中（src目录）
  • 所有设备厂商的支持文件（device目录），比如每个型号的交换机的配置文件，用来访问硬件的支持脚本，等等等等，比如：我的交换机是Arista 7050 QX-32S，那么我就可以在device/arista/x86_64-arista_7050_qx32s目录中找到它的支持文件。
  • 所有ASIC芯片厂商提供的支持文件（platform目录），比如每个平台的驱动程序，BSP，底层支持的脚本等等。这里我们可以看到几乎所有的主流芯片厂商的支持文件，比如：Broadcom，Mellanox，等等，也有用来做模拟软交换机的实现，比如vs和p4。
  • SONiC用来构建所有容器镜像的Dockerfile（dockers目录）
  • 各种各样通用的配置文件和脚本（files目录）
  • 用来做构建的编译容器的dockerfile（sonic-slave-*目录）
  • 等等……

正因为这个仓库里面将所有相关的资源全都放在了一起，所以我们学习SONiC的代码时，基本只需要下载这一个源码仓库就可以了，不管是搜索还是跳转都非常方便！

2. 功能实现仓库

除了核心仓库，SONiC下还有很多功能实现仓库，里面都是各个容器和子服务的实现，这些仓库都被以submodule的形式放在了sonic-buildimage的src目录下，如果我们想对SONiC进行修改和贡献，我们也需要了解一下。

2.1. SWSS（Switch State Service）相关仓库

在上一篇中我们介绍过，SWSS容器是SONiC的大脑，在SONiC下，它由两个repo组成：sonic-swss-common和sonic-swss。

2.1.1. SWSS公共库：sonic-swss-common

首先是公共库：sonic-swss-common（https://github.com/sonic-net/sonic-swss-common）。

这个仓库里面包含了所有*mgrd和*syncd服务所需要的公共功能，比如，logger，json，netlink的封装，Redis操作和基于Redis的各种服务间通讯机制的封装等等。虽然能看出来这个仓库一开始的目标是专门给swss服务使用的，但是也正因为功能多，很多其他的仓库都有它的引用，比如swss-sairedis和swss-restapi。

2.1.2. SWSS主仓库：sonic-swss

然后就是SWSS的主仓库sonic-swss了：https://github.com/sonic-net/sonic-swss。

我们可以在这个仓库中找到：

  • 绝大部分的*mgrd和*syncd服务：orchagent, portsyncd/portmgrd/intfmgrd，neighsyncd/nbrmgrd，natsyncd/natmgrd，buffermgrd，coppmgrd，macsecmgrd，sflowmgrd，tunnelmgrd，vlanmgrd，vrfmgrd，vxlanmgrd，等等。
  • swssconfig：在swssconfig目录下，用于在快速重启时（fast reboot）恢复FDB和ARP表。
  • swssplayer：也在swssconfig目录下，用来记录所有通过SWSS进行的配置下发操作，这样我们就可以利用它来做replay，从而对问题进行重现和调试。
  • 甚至一些不在SWSS容器中的服务，比如fpmsyncd（bgp容器）和teamsyncd/teammgrd（teamd容器）。

2.2. SAI/平台相关仓库

接下来就是作为交换机抽象接口的SAI了，虽然SAI是微软提出来并在2015年3月份发布了0.1版本，但是在2015年9月份，SONiC都还没有发布第一个版本的时候，就已经被OCP接收并作为一个公共的标准了，这也是SONiC能够在这么短的时间内就得到了这么多厂商的支持的原因之一。而也因为如此，SAI的代码仓库也被分成了两部分：

  • OCP下的OpenComputeProject/SAI：https://github.com/opencomputeproject/SAI。里面包含了有关SAI标准的所有代码，包括SAI的头文件，behavior model，测试用例，文档等等。
  • SONiC下的sonic-sairedis：https://github.com/sonic-net/sonic-sairedis。里面包含了SONiC中用来和SAI交互的所有代码，比如syncd服务，和各种调试统计，比如用来做replay的saiplayer和用来导出asic状态的saidump。

除了这两个仓库之外，还有一个平台相关的仓库，比如：sonic-platform-vpp，它的作用是通过SAI的接口，利用vpp来实现数据平面的功能，相当于一个高性能的软交换机，个人感觉未来可能会被合并到buildimage仓库中，作为platform目录下的一部分。

2.3. 管理服务（mgmt）相关仓库

然后是SONiC中所有和管理服务相关的仓库：

名称说明
sonic-mgmt-common管理服务的基础库，里面包含着translib，yang model相关的代码
sonic-mgmt-framework使用Go来实现的REST Server，是下方架构图中的REST Gateway（进程名：rest_server）
sonic-gnmi和sonic-mgmt-framework类似，是下方架构图中，基于gRPC的gNMI（gRPC Network Management Interface）Server
sonic-restapi这是SONiC使用go来实现的另一个配置管理的REST Server，和mgmt-framework不同，这个server在收到消息后会直接对CONFIG_DB进行操作，而不是走translib（下图中没有，进程名：go-server-server）
sonic-mgmt各种自动化脚本（ansible目录），测试（tests目录），用来搭建test bed和测试上报（test_reporting目录）之类的，

这里还是附上SONiC管理服务的架构图，方便大家配合食用 [4]：

2.4. 平台监控相关仓库：sonic-platform-common和sonic-platform-daemons

以下两个仓库都和平台监控和控制相关，比如LED，风扇，电源，温控等等：

名称说明
sonic-platform-common这是给厂商们提供的基础包，用来定义访问风扇，LED，电源管理，温控等等模块的接口定义，这些接口都是用python来实现的
sonic-platform-daemons这里包含了SONiC中pmon容器中运行的各种监控服务：chassisd，ledd，pcied，psud，syseepromd，thermalctld，xcvrd，ycabled，它们都使用python实现，通过和中心数据库Redis进行连接，和加载并调用各个厂商提供的接口实现来对各个模块进行监控和控制

2.5. 其他功能实现仓库

除了上面这些仓库以外，SONiC还有很多实现其方方面面功能的仓库，有些是一个或多个进程，有些是一些库，它们的作用如下表所示：

仓库介绍
sonic-snmpagentAgentX SNMP subagent的实现（sonic_ax_impl），用于连接Redis数据库，给snmpd提供所需要的各种信息，可以把它理解成snmpd的控制面，而snmpd是数据面，用于响应外部SNMP的请求
sonic-frrFRRouting，各种路由协议的实现，所以这个仓库中我们可以找到如bgpd，zebra这类的路由相关的进程实现
sonic-linkmgrdDual ToR support，检查Link的状态，并且控制ToR的连接
sonic-dhcp-relayDHCP relay agent
sonic-dhcpmon监控DHCP的状态，并报告给中心数据库Redis
sonic-dbsyncdlldp_syncd服务，但是repo的名字没取好，叫做dbsyncd
sonic-pinsGoogle开发的基于P4的网络栈支持（P4 Integrated Network Stack，PINS），更多信息可以参看PINS的官网。
sonic-stpSTP（Spanning Tree Protocol）的支持
sonic-ztpZero Touch Provisioning
DASHDisaggregated API for SONiC Hosts
sonic-host-services运行在host上通过dbus用来为容器中的服务提供支持的服务，比如保存和重新加载配置，保存dump之类的非常有限的功能，类似一个host broker
sonic-fipsFIPS（Federal Information Processing Standards）的支持，里面有很多为了支持FIPS标准而加入的各种补丁文件
sonic-wpa-supplicant各种无线网络协议的支持

3. 工具仓库：sonic-utilities

https://github.com/sonic-net/sonic-utilities

这个仓库存放着SONiC所有的命令行下的工具：

  • config，show，clear目录：这是三个SONiC CLI的主命令的实现。需要注意的是，具体的命令实现并不一定在这几个目录里面，大量的命令是通过调用其他命令来实现的，这几个命令只是提供了一个入口。
  • scripts，sfputil，psuutil，pcieutil，fwutil，ssdutil，acl_loader目录：这些目录下提供了大量的工具命令，但是它们大多并不是直接给用户使用的，而是被config，show和clear目录下的命令调用的，比如：show platform fan命令，就是通过调用scripts目录下的fanshow命令来实现的。
  • utilities_common，flow_counter_util，syslog_util目录：这些目录和上面类似，但是提供的是基础类，可以直接在python中import调用。
  • 另外还有很多其他的命令：fdbutil，pddf_fanutil，pddf_ledutil，pddf_psuutil，pddf_thermalutil，等等，用于查看和控制各个模块的状态。
  • connect和consutil目录：这两个目录下的命令是用来连接到其他SONiC设备并对其进行管理的。
  • crm目录：用来配置和查看SONiC中的CRM（Critical Resource Monitoring）。这个命令并没有被包含在config和show命令中，所以用户可以直接使用。
  • pfc目录：用来配置和查看SONiC中的[PFC（Priority-based Flow Control）][SONiCPFC]。
  • pfcwd目录：用来配置和查看SONiC中的[PFC Watch Dog][SONiCPFCWD]，比如启动，停止，修改polling interval之类的操作。

4. 内核补丁：sonic-linux-kernel

https://github.com/sonic-net/sonic-linux-kernel

虽然SONiC是基于debian的，但是默认的debian内核却不一定能运行SONiC，比如某个模块默认没有启动，或者某些老版本的驱动有问题，所以SONiC需要或多或少有一些修改的Linux内核。而这个仓库就是用来存放所有的内核补丁的。

5. 小结

嗯……到最后我也没有想到SONiC的仓库有这么多，居然需要花一整篇文章来介绍它们，不过这也说明了SONiC的强大和可扩展性。本来想在这一篇文章中把服务间的通信机制也介绍一下的，但是两个内容加在一起可能就太长了，所以就放到下一篇文章中介绍吧。

6. 参考资料

同系列文章：
原创文章，转载请标明出处：Soul Orbit
本文链接地址：SONiC学习笔记（三）：代码仓库]]> <p>在<a href="/posts/sonic-2-key-components/">上一章中，我们了解了SONiC的整体设计和核心组件</a>，为我们提供了一副看代码的地图，所以这一章，我们就来从代码的级别来继续了解SONiC吧！</p> <p>SONiC的代码都托管在<a href="https://github.com/sonic-net">GitHub的sonic-net账号</a>上，仓库数量有30几个之多，所以刚开始看SONiC的代码时，肯定是会有点懵的，不过不用担心，我们这里就来一起看看～</p> <h2 id="核心仓库">1. 核心仓库</h2> <p>首先是SONiC中最重要的两个核心仓库：SONiC和sonic-buildimage。</p> SONiC学习笔记（二）：核心组件 http://r12f.com/posts/sonic-2-key-components/ 2023-04-29T15:16:37.000Z 2023-04-29T22:16:37.000Z 在上一篇文章中，我们简单的介绍了SONiC的基本架构，以及它的一些特点。在这篇文章中，我们来继续自上向下的来看看SONiC，更加深入一点的来了解SONiC的核心组件的构成。

1. 前置知识

这篇文章和SONiC的官方文档中会经常出现这几个词：ASIC（Application-Specific Integrated Circuit）和ASIC状态（State）。它们指的是交换机中用来进行包处理的Pipeline的状态，比如，ACL，转发方式等等，这个和其他交换机的硬件状态，比如，端口状态（端口速度，接口类型），IP信息等等硬件状态是非常不同的。如果大家有兴趣了解更深入的细节，可以先移步阅读两个相关资料：SAI (Switch Abstraction Interface) API和一篇RMT（Reprogrammable Match Table）的相关论文：Forwarding Metamorphosis: Fast Programmable Match-Action Processing in Hardware for SDN。这些都会对我们阅读SONiC的文档有很大的帮助。

为了方便我们的理解和阅读，我们把上一篇文章中已经放过的SONiC架构图在这里再放一次 [1]：

2. 数据库

首先，在SONiC里面最核心的服务，自然是当之无愧的中心数据库Redis了！它的主要目的有两个：存储所有服务的配置和状态，并且为各个服务提供通信的媒介。具体的细节，我们这里不会展开，后面会用专门的文章来介绍。

SONiC会在Redis中创建一个名为sonic-db的数据库，其配置和分库信息我们可以在/var/run/redis/sonic-db/database_config.json中找到：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
admin@sonic:~$ cat /var/run/redis/sonic-db/database_config.json
{
    "INSTANCES": {
        "redis": {
            "hostname": "127.0.0.1",
            "port": 6379,
            "unix_socket_path": "/var/run/redis/redis.sock",
            "persistence_for_warm_boot": "yes"
        }
    },
    "DATABASES": {
        "APPL_DB": { "id": 0, "separator": ":", "instance": "redis" },
        "ASIC_DB": { "id": 1, "separator": ":", "instance": "redis" },
        "COUNTERS_DB": { "id": 2, "separator": ":", "instance": "redis" },
        "LOGLEVEL_DB": { "id": 3, "separator": ":", "instance": "redis" },
        "CONFIG_DB": { "id": 4, "separator": "|", "instance": "redis" },
        "PFC_WD_DB": { "id": 5, "separator": ":", "instance": "redis" },
        "FLEX_COUNTER_DB": { "id": 5, "separator": ":", "instance": "redis" },
        "STATE_DB": { "id": 6, "separator": "|", "instance": "redis" },
        "SNMP_OVERLAY_DB": { "id": 7, "separator": "|", "instance": "redis" },
        "RESTAPI_DB": { "id": 8, "separator": "|", "instance": "redis" },
        "GB_ASIC_DB": { "id": 9, "separator": ":", "instance": "redis" },
        "GB_COUNTERS_DB": { "id": 10, "separator": ":", "instance": "redis" },
        "GB_FLEX_COUNTER_DB": { "id": 11, "separator": ":", "instance": "redis" },
        "APPL_STATE_DB": { "id": 14, "separator": ":", "instance": "redis" }
    },
    "VERSION": "1.0"
}

虽然我们可以看到SONiC中的数据库有十来个，但是我们大部分时候只需要关注以下几个最重要的数据库就可以了：

  • CONFIG_DB：ID为4，存储所有服务的配置信息，比如端口配置，VLAN配置等等。它代表着用户想要交换机达到的状态的数据模型，这也是所有CLI和外部应用程序修改配置时的主要操作对象。
  • APPL_DB（Application DB）：ID为0，存储所有服务的内部状态信息。这些信息有两种：一种是各个服务在读取了CONFIG_DB的配置信息后，自己计算出来的。我们可以理解为各个服务想要交换机达到的状态（Goal State），还有一种是当最终硬件状态发生变化被写回时，有些服务会直接写回到APPL_DB，而不是我们下面马上要介绍的STATE_DB。这些信息我们可以理解为各个服务认为交换机当前的状态（Current State）。
  • STATE_DB：ID为6，存储着交换机各个部件当前的状态（Current State）。当SONiC中的服务收到了STATE_DB的状态变化，但是发现和Goal State不一致的时候，SONiC就会重新下发配置，直到两者一致。（当然，对于那些回写到APPL_DB状态，服务就会监听APPL_DB的变化，而不是STATE_DB了。）
  • ASIC_DB：ID为1，存储着SONiC想要交换机ASIC达到状态信息，比如，ACL，转发方式等等。和APPL_DB不同，这个数据库里面的数据模型是面向ASIC设计的，而不是面向服务抽象的。这样做的目的是为了方便各个厂商进行SAI和ASIC驱动的开发。

目前我的感觉是APPL_DB和STATE_DB这两个DB的设计并不是很干净，它们的职责经常重叠，不过也有可能是我理解不够深入。欢迎大家一起讨论。

这里，我们会发现一个很直观的问题：交换机里面这么多服务，难道所有的配置和状态都放在一个数据库里面没有隔离的么？如果两个服务用了同一个Redis Key怎么办呢？这个问题非常的好，SONiC的解决也很直接，那就是在每个数据库里面继续分表！

我们知道Redis在每个数据库里面并没有表的概念，而是使用key-value的方式来存储数据。所以，为了进一步分表，SONiC的解决方法是将表的名字放入key中，并且使用分隔符将表和key隔开。上面的配置文件中separator字段就是做这个了。比如：APPL_DB中的PORT_TABLE表中的Ethernet4端口的状态，我们可以通过PORT_TABLE:Ethernet4来获取，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
127.0.0.1:6379> select 0
OK

127.0.0.1:6379> hgetall PORT_TABLE:Ethernet4
 1) "admin_status"
 2) "up"
 3) "alias"
 4) "Ethernet6/1"
 5) "index"
 6) "6"
 7) "lanes"
 8) "13,14,15,16"
 9) "mtu"
10) "9100"
11) "speed"
12) "40000"
13) "description"
14) ""
15) "oper_status"
16) "up"

当然在SONiC中，不仅仅是数据模型，包括通信机制，都是使用类似的方法来实现“表”级别的隔离的。

3. 服务

3.1. 服务分类

接下来就是服务了。SONiC里面的服务（常驻进程）非常的多，有二三十种，它们会在随着交换机启动而启动，并一直保持运行，直到交换机关机。如果我们想快速掌握SONiC，一个一个服务的去了解，会很容易陷入细节的泥潭，所以，我们最好把这些服务进行一个大的分类。

我们这里不会深入到某一个具体的服务中去，而是先从整体上来看看SONiC中的服务的结构，帮助我们建立一个整体的认识。关于各个具体的服务，如果有机会，我们会在后面的文章中再进行介绍。

总体而言，SONiC中的服务可以分为以下几类：*syncd, *mgrd，feature实现，orchagent和syncd。

3.1.1. *syncd服务

这类服务名字中都以syncd结尾。它们做的事情都很类似：它们负责将硬件状态同步到Redis中，一般目标都以APPL_DB或者STATE_DB为主。

比如，portsyncd就是通过监听netlink的事件，将交换机中所有Port的状态同步到STATE_DB中，而natsyncd则是监听netlink的事件，将交换机中所有的NAT状态同步到APPL_DB中。

3.1.2. *mgrd服务

这类服务名字中都以mgrd结尾。顾名思义，这些服务是所谓的“Manager”服务，也就是说它们负责各个硬件的配置，和*syncd完全相反。它们的逻辑主要有两个部分：

  1. 配置下发：负责读取配置文件和监听Redis中的配置和状态改变（主要是CONFIG_DB，APPL_DB和STATE_DB），然后将这些修改推送到交换机硬件中去。推送的方法有多种，取决于更新的目标是什么，可以通过更新APPL_DB并发布更新消息，或者是直接调用linux下的命令行，对系统进行修改。比如：nbrmgr就是监听CONFIG_DB，APPL_DB和STATE_DB中neighbor的变化，并调用netlink和command line来对neighbor和route进行修改，而intfmgr除了调用command line还会将一些状态更新到APPL_DB中去。
  2. 状态同步：对于需要Reconcile的服务，*mgrd还会监听STATE_DB中的状态变化，如果发现硬件状态和当前期望状态不一致，就会重新发起配置流程，将硬件状态设置为期望状态。这些STATE_DB中的状态变化一般都是*syncd服务推送的。比如：intfmgr就会监听STATE_DB中，由portsyncd推送的，端口的Up/Down状态和MTU变化，一旦发现和其内存中保存的期望状态不一致，就会重新下发配置。

3.1.3. 功能实现服务

有一些功能并不是依靠OS本身来完成的，而是由一些特定的进程来实现的，比如BGP，或者一些外部接口。这些服务名字中经常以d结尾，表示deamon，比如：bgpd，lldpd，snmpd，teamd等，或者干脆就是这个功能的名字，比如：fancontrol。

3.1.4. orchagent服务

这个是SONiC中最重要的一个服务，不像其他的服务只负责一两个特定的功能，orchagent作为交换机ASIC状态的编排者（orchestrator），会检查数据库中所有来自*syncd服务的状态，整合起来并下发给用于保存交换机ASIC配置的数据库：ASIC_DB。这些状态最后会被syncd接收，并调用SAI API经过各个厂商提供的SAI实现和ASIC SDK和ASIC进行交互，最终将配置下发到交换机硬件中。

3.1.5. syncd服务

syncd服务是orchagent的下游，它虽然名字叫syncd，但是它却同时肩负着ASIC的*mgrd和*syncd的工作。

  • 首先，作为*mgrd，它会监听ASIC_DB的状态变化，一旦发现，就会获取其新的状态并调用SAI API，将配置下发到交换机硬件中。
  • 然后，作为*syncd，如果ASIC发送了任何的通知给SONiC，它也会将这些通知通过消息的方式发送到Redis中，以便orchagent和*mgrd服务获取到这些变化，并进行处理。这些通知的类型我们可以在SwitchNotifications.h中找到。

3.2. 服务间控制流分类

有了这些分类，我们就可以更加清晰的来理解SONiC中的服务了，而其中非常重要的就是理解服务之间的控制流。有了上面的分类，我们这里也可以把主要的控制流有分为两类：配置下发和状态同步。

3.2.1. 配置下发

配置下发的流程一般是这样的：

  1. 修改配置：用户可以通过CLI或者REST API修改配置，这些配置会被写入到CONFIG_DB中并通过Redis发送更新通知。或者外部程序可以通过特定的接口，比如BGP的API，来修改配置，这种配置会通过内部的TCP Socket发送给*mgrd服务。
  2. *mgrd下发配置：服务监听到CONFIG_DB中的配置变化，然后将这些配置推送到交换机硬件中。这里由两种主要情况（并且可以同时存在）：
    1. 直接下发：
      1. *mgrd服务直接调用linux下的命令行，或者是通过netlink来修改系统配置
      2. *syncd服务会通过netlink或者其他方式监听到系统配置的变化，并将这些变化推送到STATE_DB或者APPL_DB中。
      3. *mgrd服务监听到STATE_DB或者APPL_DB中的配置变化，然后将这些配置和其内存中存储的配置进行比较，如果发现不一致，就会重新调用命令行或者netlink来修改系统配置，直到它们一致为止。
    2. 间接下发：
      1. *mgrd将状态推送到APPL_DB并通过Redis发送更新通知。
      2. orchagent服务监听到配置变化，然后根据所有相关的状态，计算出此时ASIC应该达到的状态，并下发到ASIC_DB中。
      3. syncd服务监听到ASIC_DB的变化，然后将这些新的配置通过统一的SAI API接口，调用ASIC Driver更新交换机ASIC中的配置。

配置初始化和配置下发类似，不过是在服务启动的时候读取配置文件，这里就不展开了。

3.2.2. 状态同步

如果这个时候，出现了一些情况，比如网口坏了，ASIC中的状态变了等等，这个时候我们就需要进行状态更新和同步了。这个流程一般是这样的：

  1. 检测状态变化：这个状态变化主要来源于*syncd服务（netlink等等）和syncd服务（SAI Switch Notification），这些服务在检测到变化后，会将它们发送给STATE_DB或者APPL_DB。
  2. 处理状态变化：orchagent和*mgrd服务会监听到这些变化，然后开始处理，将新的配置重新通过命令行和netlink下发给系统，或者下发到ASIC_DB中，让syncd服务再次对ASIC进行更新。

3.2.3. 具体例子

SONiC的官方文档中给出了几个典型的控制流流转的例子，这里就不过多的展开了，有兴趣的朋友可以去这里看看：SONiC Subsystem Interactions。

4. 容器

然后，就是SONiC的设计中最具特色的地方：容器化。

从SONiC的上面的设计图中，我们可以看出来，SONiC中，所有的服务都是以容器的形式存在的。在登录进交换机之后，我们可以通过docker ps命令来查看当前运行的容器：

1
2
3
4
5
6
7
8
9
10
11
12
13
admin@sonic:~$ docker ps
CONTAINER ID   IMAGE                                COMMAND                  CREATED      STATUS        PORTS     NAMES
ddf09928ec58   docker-snmp:latest                   "/usr/local/bin/supe…"   2 days ago   Up 32 hours             snmp
c480f3cf9dd7   docker-sonic-mgmt-framework:latest   "/usr/local/bin/supe…"   2 days ago   Up 32 hours             mgmt-framework
3655aff31161   docker-lldp:latest                   "/usr/bin/docker-lld…"   2 days ago   Up 32 hours             lldp
78f0b12ed10e   docker-platform-monitor:latest       "/usr/bin/docker_ini…"   2 days ago   Up 32 hours             pmon
f9d9bcf6c9a6   docker-router-advertiser:latest      "/usr/bin/docker-ini…"   2 days ago   Up 32 hours             radv
2e5dbee95844   docker-fpm-frr:latest                "/usr/bin/docker_ini…"   2 days ago   Up 32 hours             bgp
bdfa58009226   docker-syncd-brcm:latest             "/usr/local/bin/supe…"   2 days ago   Up 32 hours             syncd
655e550b7a1b   docker-teamd:latest                  "/usr/local/bin/supe…"   2 days ago   Up 32 hours             teamd
1bd55acc181c   docker-orchagent:latest              "/usr/bin/docker-ini…"   2 days ago   Up 32 hours             swss
bd20649228c8   docker-eventd:latest                 "/usr/local/bin/supe…"   2 days ago   Up 32 hours             eventd
b2f58447febb   docker-database:latest               "/usr/local/bin/dock…"   2 days ago   Up 32 hours             database

这里我们来简单介绍一下这些容器。

4.1. 数据库容器：database

这个容器中运行的就是我们多次提到的SONiC中的中心数据库Redis了，它里面存放着所有交换机的配置和状态信息，SONiC也是主要通过它来向各个服务提供底层的通信机制。

我们通过docker进入这个容器，就可以看到里面正在运行的redis进程了：

1
2
3
4
5
6
7
8
9
10
admin@sonic:~$ sudo docker exec -it database bash

root@sonic:/# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...
root          82 13.7  1.7 130808 71692 pts/0    Sl   Apr26 393:27 /usr/bin/redis-server 127.0.0.1:6379
...

root@sonic:/# cat /var/run/redis/redis.pid
82

那么别的容器是如何来访问这个Redis数据库的呢？答案是通过Unix Socket。我们可以在database容器中看到这个Unix Socket，它将交换机上的/var/run/redis目录map进database容器，让database容器可以创建这个socket：

1
2
3
4
5
6
7
# In database container
root@sonic:/# ls /var/run/redis
redis.pid  redis.sock  sonic-db

# On host
admin@sonic:~$ ls /var/run/redis
redis.pid  redis.sock  sonic-db

然后再将这个socket给map到其他的容器中，这样所有容器就都可以来访问这个中心数据库啦，比如，swss容器：

1
2
3
4
5
6
7
8
9
admin@sonic:~$ docker inspect swss
...
        "HostConfig": {
            "Binds": [
                ...
                "/var/run/redis:/var/run/redis:rw",
                ...
            ],
            ...

4.2. 交换机状态管理容器：swss（Switch State Service）

这个容器可以说是SONiC中最关键的容器了，它是SONiC的大脑，里面运行着大量的*syncd和*mgrd服务，用来管理交换机方方面面的配置，比如Port，neighbor，ARP，VLAN，Tunnel等等等等。另外里面还运行着上面提到的orchagent，用来统一处理和ASIC相关的配置和状态变化。

这些服务大概的功能和流程我们上面已经提过了，所以就不再赘述了。这里我们可以通过ps命令来看一下这个容器中运行的服务：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
admin@sonic:~$ docker exec -it swss bash
root@sonic:/# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...
root          43  0.0  0.2  91016  9688 pts/0    Sl   Apr26   0:18 /usr/bin/portsyncd
root          49  0.1  0.6 558420 27592 pts/0    Sl   Apr26   4:31 /usr/bin/orchagent -d /var/log/swss -b 8192 -s -m 00:1c:73:f2:bc:b4
root          74  0.0  0.2  91240  9776 pts/0    Sl   Apr26   0:19 /usr/bin/coppmgrd
root          93  0.0  0.0   4400  3432 pts/0    S    Apr26   0:09 /bin/bash /usr/bin/arp_update
root          94  0.0  0.2  91008  8568 pts/0    Sl   Apr26   0:09 /usr/bin/neighsyncd
root          96  0.0  0.2  91168  9800 pts/0    Sl   Apr26   0:19 /usr/bin/vlanmgrd
root          99  0.0  0.2  91320  9848 pts/0    Sl   Apr26   0:20 /usr/bin/intfmgrd
root         103  0.0  0.2  91136  9708 pts/0    Sl   Apr26   0:19 /usr/bin/portmgrd
root         104  0.0  0.2  91380  9844 pts/0    Sl   Apr26   0:20 /usr/bin/buffermgrd -l /usr/share/sonic/hwsku/pg_profile_lookup.ini
root         107  0.0  0.2  91284  9836 pts/0    Sl   Apr26   0:20 /usr/bin/vrfmgrd
root         109  0.0  0.2  91040  8600 pts/0    Sl   Apr26   0:19 /usr/bin/nbrmgrd
root         110  0.0  0.2  91184  9724 pts/0    Sl   Apr26   0:19 /usr/bin/vxlanmgrd
root         112  0.0  0.2  90940  8804 pts/0    Sl   Apr26   0:09 /usr/bin/fdbsyncd
root         113  0.0  0.2  91140  9656 pts/0    Sl   Apr26   0:20 /usr/bin/tunnelmgrd
root         208  0.0  0.0   5772  1636 pts/0    S    Apr26   0:07 /usr/sbin/ndppd
...

4.3. ASIC管理容器：syncd

这个容器中主要是用于管理交换机上的ASIC的，里面运行着syncd服务。我们之前提到的各个厂商提供的SAI（Switch Abstraction Interface）和ASIC Driver都是放在这个容器中的。正是因为这个容器的存在，才使得SONiC可以支持多种不同的ASIC，而不需要修改上层的服务。换句话说，如果没有这个容器，那SONiC就是一个缸中大脑，除了一些基本的配置，其他只能靠想的，什么都干不了。

在syncd容器中运行的服务并不多，就是syncd，我们可以通过ps命令来查看，而在/usr/lib目录下，我们也可以找到这个为了支持ASIC而编译出来的巨大无比的SAI文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
admin@sonic:~$ docker exec -it syncd bash

root@sonic:/# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...
root          20  0.0  0.0  87708  1544 pts/0    Sl   Apr26   0:00 /usr/bin/dsserve /usr/bin/syncd --diag -u -s -p /etc/sai.d/sai.profile -b /tmp/break_before_make_objects
root          32 10.7 14.9 2724404 599408 pts/0  Sl   Apr26 386:49 /usr/bin/syncd --diag -u -s -p /etc/sai.d/sai.profile -b /tmp/break_before_make_objects
...

root@sonic:/# ls -lh /usr/lib
total 343M
...
lrwxrwxrwx 1 root root   13 Apr 25 04:38 libsai.so.1 -> libsai.so.1.0
-rw-r--r-- 1 root root 343M Feb  1 06:10 libsai.so.1.0
...

4.4. 各种实现特定功能的容器

SONiC中还有很多的容器是为了实现一些特定功能而存在的。这些容器一般都有着特殊的外部接口（非SONiC CLI和REST API）和实现（非OS或ASIC），比如：

  • bgp：用来实现BGP协议（Border Gateway Protocol，边界网关协议）的容器
  • lldp：用来实现LLDP协议（Link Layer Discovery Protocol，链路层发现协议）的容器
  • teamd：用来实现Link Aggregation（链路聚合）的容器
  • snmp：用来实现SNMP协议（Simple Network Management Protocol，简单网络管理协议）的容器

和SWSS类似，为了适应SONiC的架构，它们中间也都会运行着上面我们提到的那几种服务：

  • 配置管理和下发（类似*mgrd）：lldpmgrd，zebra（bgp）
  • 状态同步（类似*syncd）：lldpsyncd，fpmsyncd（bgp），teamsyncd
  • 服务实现或者外部接口（*d）：lldpd，bgpd，teamd，snmpd

4.5. 管理服务容器：mgmt-framework

我们在上一篇中的安装部分已经看过如何使用SONiC的CLI来进行一些交换机的配置，但是在实际生产环境中，手动登录交换机使用CLI来配置所有的交换机是不现实的，所以SONiC提供了一个REST API来解决这个问题。这个REST API的实现就是在mgmt-framework容器中。我们可以通过ps命令来查看：

1
2
3
4
5
6
admin@sonic:~$ docker exec -it mgmt-framework bash
root@sonic:/# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...
root          16  0.3  1.2 1472804 52036 pts/0   Sl   16:20   0:02 /usr/sbin/rest_server -ui /rest_ui -logtostderr -cert /tmp/cert.pem -key /tmp/key.pem
...

其实除了REST API，SONiC还可以通过其他方式来进行管理，如gNMI，这些也都是运行在这个容器中的。其整体架构如下图所示 [7]：

这里我们也可以发现，其实我们使用的CLI，底层也是通过调用这个REST API来实现的～

4.6. 平台监控容器：pmon（Platform Monitor）

这个容器里面的服务基本都是用来监控交换机一些基础硬件的运行状态的，比如温度，电源，风扇，SFP事件等等。同样，我们可以用ps命令来查看这个容器中运行的服务：

1
2
3
4
5
6
7
8
9
10
11
12
13
admin@sonic:~$ docker exec -it pmon bash
root@sonic:/# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...
root          28  0.0  0.8  49972 33192 pts/0    S    Apr26   0:23 python3 /usr/local/bin/ledd
root          29  0.9  1.0 278492 43816 pts/0    Sl   Apr26  34:41 python3 /usr/local/bin/xcvrd
root          30  0.4  1.0  57660 40412 pts/0    S    Apr26  18:41 python3 /usr/local/bin/psud
root          32  0.0  1.0  57172 40088 pts/0    S    Apr26   0:02 python3 /usr/local/bin/syseepromd
root          33  0.0  1.0  58648 41400 pts/0    S    Apr26   0:27 python3 /usr/local/bin/thermalctld
root          34  0.0  1.3  70044 53496 pts/0    S    Apr26   0:46 /usr/bin/python3 /usr/local/bin/pcied
root          42  0.0  0.0  55320  1136 ?        Ss   Apr26   0:15 /usr/sbin/sensord -f daemon
root          45  0.0  0.8  58648 32220 pts/0    S    Apr26   2:45 python3 /usr/local/bin/thermalctld
...

其中大部分的服务从名字我们就能猜出来是做什么的了，中间只有xcvrd不是那么明显，这里xcvr是transceiver的缩写，它是用来监控交换机的光模块的，比如SFP，QSFP等等。

5. SAI

最后就是SAI（Switch Abstraction Interface，交换机抽象接口）了，它是SONiC的基石，正因为有了它，SONiC才能支持多种硬件平台。我们在这个SAI API的文档中，可以看到它定义的所有接口。

上面我们提到，SAI运行在syncd容器中。不过和其他组件不同，它并不是一个服务，而是一个组动态链接库（.so）。在syncd容器中，SONiC会在启动时启动统一的syncd服务，而syncd服务会加载依赖的SAI组件。这个组件由各个厂商提供，它们会根据自己的硬件平台来实现SAI的接口，从而让SONiC可以支持多种硬件平台。

我们可以通过ps, ls和nm命令来简单的对这个进行验证：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# Enter into syncd container
admin@sonic:~$ docker exec -it syncd bash

# List all processes. We will only see syncd process here.
root@sonic:/# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...
root          21  0.0  0.0  87708  1532 pts/0    Sl   16:20   0:00 /usr/bin/dsserve /usr/bin/syncd --diag -u -s -p /etc/sai.d/sai.profile -b /tmp/break_before_make_objects
root          33 11.1 15.0 2724396 602532 pts/0  Sl   16:20  36:30 /usr/bin/syncd --diag -u -s -p /etc/sai.d/sai.profile -b /tmp/break_before_make_objects
...

# Find all libsai*.so.* files.
root@sonic:/# find / -name libsai*.so.*
/usr/lib/x86_64-linux-gnu/libsaimeta.so.0
/usr/lib/x86_64-linux-gnu/libsaimeta.so.0.0.0
/usr/lib/x86_64-linux-gnu/libsaimetadata.so.0.0.0
/usr/lib/x86_64-linux-gnu/libsairedis.so.0.0.0
/usr/lib/x86_64-linux-gnu/libsairedis.so.0
/usr/lib/x86_64-linux-gnu/libsaimetadata.so.0
/usr/lib/libsai.so.1
/usr/lib/libsai.so.1.0

# Copy the file out of switch and check libsai.so on your own dev machine.
# We will see the most important SAI export functions here.
$ nm -C -D ./libsai.so.1.0 > ./sai-exports.txt
$ vim sai-exports.txt
...
0000000006581ae0 T sai_api_initialize
0000000006582700 T sai_api_query
0000000006581da0 T sai_api_uninitialize
...

6. 小结

好了，到此我们就把所有SONiC的关键组件都简单的过完了！

我们能感觉到，交换机上的组件其实非常的多，而且由于SONiC中Redis的解耦，我们很难简单的对代码进行跟踪来理解服务之间的关系，这就需要我们先建立一个比较抽线的整体模型，然后再去深入的学习每个组件的细节。这也是为什么我们会这里先对每个组件都做一个点到为止的介绍。

后面如果有时间，我们会继续自上向下的来看各个组件的细节。由于篇幅原因，这篇文章就先到这里吧～

7. 参考资料

同系列文章：
原创文章，转载请标明出处：Soul Orbit
本文链接地址：SONiC学习笔记（二）：核心组件]]> <p><a href="/posts/sonic-1-intro/">在上一篇文章中，我们简单的介绍了SONiC的基本架构，以及它的一些特点</a>。在这篇文章中，我们来继续自上向下的来看看SONiC，更加深入一点的来了解SONiC的核心组件的构成。</p> <h2 id="前置知识">1. 前置知识</h2> <p>这篇文章和SONiC的官方文档中会经常出现这几个词：ASIC（Application-Specific Integrated Circuit）和ASIC状态（State）。它们指的是交换机中用来进行包处理的Pipeline的状态，比如，ACL，转发方式等等，这个和其他交换机的硬件状态，比如，端口状态（端口速度，接口类型），IP信息等等硬件状态是非常不同的。如果大家有兴趣了解更深入的细节，可以先移步阅读两个相关资料：<a href="https://github.com/opencomputeproject/SAI/wiki/SAI-APIs">SAI (Switch Abstraction Interface) API</a>和一篇RMT（Reprogrammable Match Table）的相关论文：<a href="http://yuba.stanford.edu/~grg/docs/sdn-chip-sigcomm-2013.pdf">Forwarding Metamorphosis: Fast Programmable Match-Action Processing in Hardware for SDN</a>。这些都会对我们阅读SONiC的文档有很大的帮助。</p> SONiC学习笔记（一）：概述与安装 http://r12f.com/posts/sonic-1-intro/ 2023-04-27T13:39:10.000Z 2023-04-27T20:39:10.000Z 这几天都在看和SONiC相关的资料，所以按照习惯，这里也简单的对学习的结果进行一个总结，希望也能对其他对SONiC感兴趣的小伙伴有所帮助。

1. 为什么要做SONiC

我们知道交换机内部都有一套可大可小的操作系统，用于配置和查看交换机的状态。但是，从1986年第一台交换机面世开始，虽然各个厂商都在进行着相关的开发，到现在为止种类也相当的多，但是依然存在一些问题，比如：

  1. 生态封闭，不开源，主要是为了支持自家的硬件，无法很好的兼容其他厂商的设备
  2. 支持的场景很有限，难以使用同一套系统去支撑大规模的数据中心中复杂多变的场景
  3. 升级可能会导致网络中断，难以实现无缝升级，这对于云提供商来说有时候是致命的
  4. 设备功能升级缓慢，难以很好的支持快速的产品迭代

所以，微软在2016年开源了SONiC，希望能够通过开源的方式，让SONiC能够成为一个通用的网络操作系统，从而解决上面的问题。而且，由于Azure的背书，也能保证SONiC确实能够承受大规模的生产环境的考验，这也是SONiC的一个优势。

2. 主体架构

SONiC是微软开发的基于debian的开源的网络操作系统，它的设计核心思想有三个：

  1. 硬件和软件解耦：通过SAI（Switch Abstraction Interface）将硬件的操作抽象出来，从而使得SONiC能够支持多种硬件平台。这一层抽象层由SONiC定义，由各个厂商来实现。
  2. 使用docker容器将软件微服务化：SONiC上的主要功能都被拆分成了一个个的docker容器，和传统的网络操作系统不同，升级系统可以只对其中的某个容器进行升级，而不需要整体升级和重启，这样就可以很方便的进行升级和维护，支持快速的开发和迭代。
  3. 使用redis作为中心数据库对服务进行解耦：绝大部分服务的配置和状态最后都被存储到中心的redis数据库中，这样不仅使得所有的服务可以很轻松的进行协作（数据存储和pubsub），也可以让我们很方便的在上面开发工具，使用统一的方法对各个服务进行操作和查询，而不用担心状态丢失和协议兼容问题，最后还可以很方便的进行状态的备份和恢复。

这让SONiC拥有了非常开放的生态（Community，Devices，Workgroups），总体而言，SONiC的架构如下图所示 [1]：

当然，这样的设计也有一些缺点，比如：对磁盘的占用会变大，不过，现在一点点存储空间并不是什么很大的问题，而且这个问题也都可以通过一些方法来解决。

3. 安装

3.1. 硬件交换机

如果你自己就拥有一台交换机，或者想购买一台交换机，在上面安装SONiC，那么请认真阅读这一小节，否则可以自行跳过。:D

3.1.1. 交换机选择和SONiC安装

首先，请确认你的交换机是否支持SONiC，SONiC目前支持的交换机型号可以在这里找到，如果你的交换机型号不在列表中，那么就需要联系厂商，看看是否有支持SONiC的计划。有很多交换机是不支持SONiC的，比如：

  1. 普通针对家用的交换机，这些交换机的硬件配置都比较低（即便支持的带宽很高，比如MikroTik CRS504-4XQ-IN，虽然它支持100GbE网络，但是它只有16MB的Flash存储和64MB的RAM，所以基本只能跑它自己的RouterOS了）。
  2. 有些虽然是数据中心用的交换机，但是可能由于型号老旧，厂商并没有计划支持SONiC。

对于安装过程，由于每一家厂商的交换机设计不同，其底层接口各有差别，所以，其安装方法也都有所差别，这些差别主要集中在两个地方：

  1. 每个厂商都会有自己的SONiC Build，还有的厂商会在SONiC的基础之上进行扩展开发，为自己的交换机支持更多的功能，比如：Dell Enterprise SONiC，EdgeCore Enterprise SONiC，所以需要根据自己的交换机选择对应的版本。
  2. 每个厂商的交换机也会支持不同的安装方式，有一些是直接使用USB对ROM进行Flash，有一些是通过ONIE进行安装，这也需要根据自己的交换机来进行配置。

所以，虽然安装方法各有差别，但是总体而言，安装的步骤都是差不多的。请联系自己的厂商，获取对应的安装文档，然后按照文档进行安装即可。

3.1.2. 配置交换机

安装好之后，我们需要进行一些基础设置，部分设置是通用的，我们在这里简单总结一下。

3.1.2.1. 设置admin密码

默认SONiC的账号密码是admin:YourPaSsWoRd，使用默认密码显然不安全：

1
sudo passwd admin
3.1.2.2. 设置风扇转速

数据中心用的交换机风扇声音都特别的大！比如，我用的交换机是Arista 7050QX-32S，上面有4个风扇，最高能到每分钟17000转，放在车库中，高频的啸叫即便是在二楼隔着3面墙还是能听得到，所以如果你是在家使用的话，建议对其进行一些设置，将转速调低。

可惜，由于SONiC并没有cli对风扇转速的规则进行控制，所以我们需要通过手动修改pmon容器中的配置文件的方式来进行设置。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Enter pmon container
sudo docker exec -it pmon bash

# Use pwmconfig to detect all pwm fans and create configuration file. The configuration file will be created at /etc/fancontrol.
pwmconfig

# Start fancontrol and make sure it works. If it doesn't work, you can run fancontrol directly to see what's wrong.
VERBOSE=1 /etc/init.d/fancontrol start
VERBOSE=1 /etc/init.d/fancontrol status

# Exit pmon container
exit

# Copy the configuration file from the container to the host, so that the configuration will not be lost after reboot.
# This command needs to know what is the model of your switch, for example, the command I need to run here is as follows. If your switch model is different, please modify it yourself.
sudo docker cp pmon:/etc/fancontrol /usr/share/sonic/device/x86_64-arista_7050_qx32s/fancontrol
3.1.2.3. 设置交换机Management Port IP

一般的数据中心用的交换机都提供了Serial Console连接的方式，但是其速度实在是太慢了，所以我们在安装完成之后，都会尽快的把Management Port给设置好，然后通过SSH的方式来进行管理。

一般来说，management port的设备名是eth0，所以我们可以通过SONiC的配置命令来进行设置：

1
2
3
4
5
6
# sudo config interface ip add eth0 <ip-cidr> <gateway>
# IPv4
sudo config interface ip add eth0 192.168.1.2/24 192.168.1.1

# IPv6
sudo config interface ip add eth0 2001::8/64 2001::1
3.1.2.4. 创建网络配置

新安装完的SONiC交换机会有一个默认的网络配置，这个配置有很多问题，比如对于10.0.0.0的IP的使用，如下：

1
2
3
4
5
6
admin@sonic:~$ show ip interfaces
Interface    Master    IPv4 address/mask    Admin/Oper    BGP Neighbor    Neighbor IP
-----------  --------  -------------------  ------------  --------------  -------------
Ethernet0              10.0.0.0/31          up/up         ARISTA01T2      10.0.0.1
Ethernet4              10.0.0.2/31          up/up         ARISTA02T2      10.0.0.3
Ethernet8              10.0.0.4/31          up/up         ARISTA03T2      10.0.0.5

所以我们需要创建一个新的网络配置，然后将我们使用的Port都放入到这个网络配置中。这里简单的方法就是创建一个VLAN，使用VLAN Routing：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Create untagged vlan
sudo config vlan add 2

# Add IP to vlan
sudo config interface ip add Vlan2 10.2.0.0/24

# Remove all default IP settings
show ip interfaces | tail -n +3 | grep Ethernet | awk '{print "sudo config interface ip remove", $1, $2}' > oobe.sh; chmod +x oobe.sh; ./oobe.sh

# Add all ports to the new vlan
show interfaces status | tail -n +3 | grep Ethernet | awk '{print "sudo config vlan member add -u 2", $1}' > oobe.sh; chmod +x oobe.sh; ./oobe.sh

# Enable proxy arp, so switch can respond to arp requests from hosts
sudo config vlan proxy_arp 2 enabled

# Save config, so it will be persistent after reboot
sudo config save -y

这样就完成了，我们可以通过show vlan brief来查看一下：

1
2
3
4
5
6
7
8
admin@sonic:~$ show vlan brief
+-----------+--------------+-------------+----------------+-------------+-----------------------+
|   VLAN ID | IP Address   | Ports       | Port Tagging   | Proxy ARP   | DHCP Helper Address   |
+===========+==============+=============+================+=============+=======================+
|         2 | 10.2.0.0/24  | Ethernet0   | untagged       | enabled     |                       |
...
|           |              | Ethernet124 | untagged       |             |                       |
+-----------+--------------+-------------+----------------+-------------+-----------------------+
3.1.2.5. 配置主机

如果你家里只有一台主机使用多网口连接交换机进行测试，那么我们还需要在主机上进行一些配置，以保证流量会通过网卡，流经交换机，否则，请跳过这一步。

这里网上的攻略很多，比如使用iptables中的DNAT和SNAT创建一个虚拟地址，但是过程非常繁琐，经过一些实验，我发现最简单的办法就是将其中一个网口移动到一个新的网络命名空间中，就可以了，即便使用的是同一个网段的IP，也不会有问题。

比如，我家使用的是Netronome Agilio CX 2x40GbE，它会创建两个interface：enp66s0np0和enp66s0np1，我们这里可以将enp66s0np1移动到一个新的网络命名空间中，再配置好ip地址就可以了：

1
2
3
4
5
6
7
8
9
10
# Create a new network namespace
sudo ip netns add toy-ns-1

# Move the interface to the new namespace
sudo ip link set enp66s0np1 netns toy-ns-1

# Setting up IP and default routes
sudo ip netns exec toy-ns-1 ip addr add 10.2.0.11/24 dev enp66s0np1
sudo ip netns exec toy-ns-1 ip link set enp66s0np1 up
sudo ip netns exec toy-ns-1 ip route add default via 10.2.0.1

这样就可以了，我们可以通过iperf来测试一下，并在交换机上进行确认：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# On the host (enp66s0np0 has ip 10.2.0.10 assigned)
$ iperf -s --bind 10.2.0.10

# Test within the new network namespace
$ sudo ip netns exec toy-ns-1 iperf -c 10.2.0.10 -i 1 -P 16
------------------------------------------------------------
Client connecting to 10.2.0.10, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
...
[SUM] 0.0000-10.0301 sec  30.7 GBytes  26.3 Gbits/sec
[ CT] final connect times (min/avg/max/stdev) = 0.288/0.465/0.647/0.095 ms (tot/err) = 16/0

# Confirm on switch
admin@sonic:~$ show interfaces counters
      IFACE    STATE       RX_OK        RX_BPS    RX_UTIL    RX_ERR    RX_DRP    RX_OVR       TX_OK        TX_BPS    TX_UTIL    TX_ERR    TX_DRP    TX_OVR
-----------  -------  ----------  ------------  ---------  --------  --------  --------  ----------  ------------  ---------  --------  --------  --------
  Ethernet4        U   2,580,140  6190.34 KB/s      0.12%         0     3,783         0  51,263,535  2086.64 MB/s     41.73%         0         0         0
 Ethernet12        U  51,261,888  2086.79 MB/s     41.74%         0         1         0   2,580,317  6191.00 KB/s      0.12%         0         0         0

3.2. 软件交换机

如果你没有交换机，想自己在家里虚拟一个玩，那么可以参考我的这篇文章：通过GNS3快速搭建本地SONiC Lab。配置过程还是比较简单的，大概半个小时左右就可以搞定（主要是等待下载或者导入镜像之类的）。

4. 发展方向

虽然交换机已经发展很多很多年了，但是随着现在云的发展，对网络的要求也越来越高，不管是直观的需求，比如更大的带宽，更大的容量，还是最新的研究，比如，带内计算，端网融合等等，都对交换机的发展提出了更高的要求和挑战，也促使着各大厂商和研究机构不断的进行创新。SONiC也一样，随着时间的发展，需求一点没有减少。

关于SONiC的发展方向，我们可以在它的roadmap中看到。如果大家对最新的动态感兴趣，也可以关注它的Workshop，比如，最近的OCP Global Summit 2022 - SONiC Workshop。这里就不展开了。

5. 总结

好了，为了避免我的老毛病 —— 文章过长，我们就先到此为止。

这篇文章主要是对SONiC的一个简单介绍，以及如何在家里搭建一个SONiC的实验环境，以便于大家可以自己动手玩一玩。如果你对SONiC感兴趣，可以参考下面的参考资料，了解更多的信息。后面我有时间也会接着进行总结。

6. 参考资料

同系列文章：
原创文章，转载请标明出处：Soul Orbit
本文链接地址：SONiC学习笔记（一）：概述与安装]]> <p>这几天都在看和SONiC相关的资料，所以按照习惯，这里也简单的对学习的结果进行一个总结，希望也能对其他对SONiC感兴趣的小伙伴有所帮助。</p> <h2 id="为什么要做SONiC">1. 为什么要做SONiC</h2> <p>我们知道交换机内部都有一套可大可小的操作系统，用于配置和查看交换机的状态。但是，从1986年第一台交换机面世开始，虽然各个厂商都在进行着相关的开发，到现在为止种类也相当的多，但是依然存在一些问题，比如：</p> <ol> <li>生态封闭，不开源，主要是为了支持自家的硬件，无法很好的兼容其他厂商的设备</li> <li>支持的场景很有限，难以使用同一套系统去支撑大规模的数据中心中复杂多变的场景</li> <li>升级可能会导致网络中断，难以实现无缝升级，这对于云提供商来说有时候是致命的</li> <li>设备功能升级缓慢，难以很好的支持快速的产品迭代</li> </ol> <p>所以，微软在2016年开源了SONiC，希望能够通过开源的方式，让SONiC能够成为一个通用的网络操作系统，从而解决上面的问题。而且，由于Azure的背书，也能保证SONiC确实能够承受大规模的生产环境的考验，这也是SONiC的一个优势。</p> 通过GNS3快速搭建本地SONiC Lab http://r12f.com/posts/sonic-local-lab-gns3/ 2023-04-19T17:00:25.000Z 2023-04-20T00:00:25.000Z SONiC是微软Azure推出的一个开源的网络操作系统，它通过微服务的思想，将网络操作系统中各个服务容器化，并利用中心Redis数据库进行协作，使得每个服务都可以独立的开发、测试、部署、升级，大大的提高了网络操作系统的可靠性、可扩展性、可维护性。现在SONiC支持的交换机厂商也非常的多，包括：Arista、Broadcom、Cisco、Dell、Edgecore、Mellanox等等。然而，一台DCN交换机的价格是非常昂贵的。如果你和我一样，想试一试SONiC，但是又不想花钱买一台SONiC的硬件设备，那么这篇文章就是为你准备的。本文会大概总结一下如何通过GNS3在本地搭建一个虚拟的SONiC的Lab，让你可以很快的在本地体验一把SONiC的基本功能。

在本地运行SONiC的方法很好几种，比如docker + vswitch，p4软交换机等等，对于初次使用而言，用GNS3可能是最方便快捷的了，所以本文就以GNS3为例，介绍一下如何在本地搭建一个SONiC的Lab。那么，我们就开始吧！

1. 安装GNS3

首先，我们要先来安装一下GNS3。

GNS3，全称为Graphical Network Simulator 3，是一个图形化的网络仿真软件。它支持多种不同的虚拟化技术，比如：QEMU、VMware、VirtualBox等等。这样，我们在等会搭建虚拟网络的时候，就不需要手动的运行很多命令，或者写脚本了，大部分的工作都可以通过图形界面来完成了。

1.1. 安装依赖

安装它之前，我们需要先安装几个其他的软件：docker, wireshark, putty, qemu, ubridge, libvirt和bridge-utils，已经装好的小伙伴可以自行跳过。

首先是Docker，它们的安装过程，大家可以自己通过下面的传送门去安装：https://docs.docker.com/engine/install/

其他的在ubuntu上安装都非常简单，只需要执行下面的命令就可以了。这里安装时要注意，ubridge和Wireshark的安装过程中会询问是不是要创建wireshark用户组来bypass sudo，这里一定要选择Yes。

1
sudo apt-get install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils wireshark putty ubridge

安装好了之后，我们就可以来安装GNS3了。

1.2. 安装GNS3

在Ubuntu上，GNS3的安装非常简单，只需要执行下面的命令就可以了。

1
2
3
sudo add-apt-repository ppa:gns3/ppa
sudo apt update                                
sudo apt install gns3-gui gns3-server

然后把你的用户加入到如下的组中，这样GNS3就可以去访问docker，wireshark等功能而不用sudo了。

1
2
3
for g in ubridge libvirt kvm wireshark docker; do
    sudo usermod -aG $g <user-name>
done

如果你使用的不是Ubuntu，更详细的安装文档可以参考他们的官方文档。

2. 准备SONiC的镜像

首先，我们需要一个SONiC的镜像。由于需要支持大量不同的厂商，而每个厂商的底层实现都不一样，所以最后每个厂商都会编译一个自己的镜像。这里因为我们是软件模拟交换机，所以我们需要使用基于VSwitch的镜像：sonic-vs.img.gz。

SONiC镜像的项目在这里，虽然我们可以自己去编译，但是速度实在有点慢，所以为了节省时间，我们可以直接去这里下载最新的镜像。只要找一个最新的成功的Build就行，在Artifacts中找到sonic-vs.img.gz，下载就可以了。

然后，我们来准备一下项目：

1
2
3
4
5
6
7
8
git clone --recurse-submodules https://github.com/sonic-net/sonic-buildimage.git
cd sonic-buildimage/platform/vs

# 将下载的镜像放在这个目录下，然后运行下面这个命令进行解压缩。
gzip -d sonic-vs.img.gz

# 下面这个命令会生成GNS3的镜像配置文件
./sonic-gns3a.sh

执行完成之后，我们运行ls命令就可以看到我们需要的镜像文件了。

1
2
3
4
5
6
7
r12f@r12f-svr:~/code/sonic/sonic-buildimage/platform/vs
$ l
total 2.8G
...
-rw-rw-r--  1 r12f r12f 1.1K Apr 18 16:36 SONiC-latest.gns3a  # <= 这个是GNS3的镜像配置文件
-rw-rw-r--  1 r12f r12f 2.8G Apr 18 16:32 sonic-vs.img        # <= 这个是我们解压出来的镜像
...

3. 导入镜像

现在，在命令行里面输入gns3，就可以启动GNS3了。如果你是ssh到另外一台机器上，可以试着启用X11转发，这样就可以在远程运行GNS3，但是图形界面显示在本地了。我就是这样，将GNS3运行在了远程的服务器上，但是图形界面通过MobaXterm显示在了本地的Windows机器上。

运行起来之后，GNS3会让我们创建一个项目，很简单，填个目录地址就好。如果你是使用的X11转发，请注意，这个目录是在你远程服务器上，而不是本地。

然后，我们就可以通过File -> Import appliance来导入我们刚刚生成的镜像了。

选择我们刚刚生成的SONiC-latest.gns3a镜像配置文件，然后点击Next。

这个时候就可以看到我们的ji镜像了，点击Next。

这个时候会开始导入镜像，这个过程可能会比较慢，因为GNS3需要将镜像转换成qcow2格式，放入我们的项目目录中。导入完成之后，我们就可以看到我们的镜像了。

好的！完成！

4. 创建网络

好了！现在一切就绪，我们还是创建一个虚拟的网络吧！

GNS3的图形界面非常的好用，基本上就是打开侧边栏，把交换机拖进来，把VPC拖进来，然后把线连起来就可以了。连接好之后记得点上面的Play按钮开始网络模拟。这里我们就不多说了，直接上图。

接着，在交换机上点击右键，选择Custom Console，再选择Putty，就可以打开我们的上面看到的交换机的Console了。这里，SONiC的默认用户名和密码是admin和YourPaSsWoRd。登录进去之后，我们就可以运行熟悉的命令，用show interfaces status或者show ip interface来查看网络的状态了。我们这里也可以看到，前面两个我们连接好了的Interface的状态都是up的了。

除了这种简单的网络以外，GNS3还可以创建非常复杂的网络，比如多层ECMP结构等等。这里就不多说了，有兴趣的可以自己去试一试~

5. 配置网络

SONiC软交换机下，默认的端口使用的是10.0.0.x的子网（如下），而且都是eth pair：

1
2
3
4
5
6
admin@sonic:~$ show ip interfaces
Interface    Master    IPv4 address/mask    Admin/Oper    BGP Neighbor    Neighbor IP
-----------  --------  -------------------  ------------  --------------  -------------
Ethernet0              10.0.0.0/31          up/up         ARISTA01T2      10.0.0.1
Ethernet4              10.0.0.2/31          up/up         ARISTA02T2      10.0.0.3
Ethernet8              10.0.0.4/31          up/up         ARISTA03T2      10.0.0.5

这里，我们比较方便的做法是创建一个小的vlan，把我们的端口都包在里面（我们这里用的是Ethernet4和Ethernet8）：

1
2
3
4
5
6
7
8
9
10
11
12
13
# Remove old config
sudo config interface ip remove Ethernet4 10.0.0.2/31
sudo config interface ip remove Ethernet8 10.0.0.4/31

# Create VLAN with id 2
sudo config vlan add 2

# Add ports to VLAN
sudo config vlan member add -u 2 Ethernet4
sudo config vlan member add -u 2 Ethernet8

# Add IP address to VLAN
sudo config interface ip add Vlan2 10.0.0.0/24

这样，我们的vlan就创建好了，我们可以通过show vlan brief来查看一下：

1
2
3
4
5
6
7
admin@sonic:~$ show vlan brief
+-----------+--------------+-----------+----------------+-------------+-----------------------+
|   VLAN ID | IP Address   | Ports     | Port Tagging   | Proxy ARP   | DHCP Helper Address   |
+===========+==============+===========+================+=============+=======================+
|         2 | 10.0.0.0/24  | Ethernet4 | untagged       | disabled    |                       |
|           |              | Ethernet8 | untagged       |             |                       |
+-----------+--------------+-----------+----------------+-------------+-----------------------+

然后，我们就可以给所有的主机配置一个10.0.0.x的IP地址了。

1
2
3
4
5
# VPC1
ip 10.0.0.2 255.0.0.0 10.0.0.1

# VPC2
ip 10.0.0.3 255.0.0.0 10.0.0.1

好的，现在我们来Ping一下吧！

通了！

6. 抓包

上面，我们安装GNS3前，我们特意安装了Wireshark，这样我们就可以在GNS3里面抓包了。我们只需要右键点击图中我们想抓包的Link上，然后选择Start capture，就可以开始抓包了。

稍等一下，Wireshark就会自动打开，实时的显示所有的包，非常的方便：

原创文章，转载请标明出处：Soul Orbit
本文链接地址：通过GNS3快速搭建本地SONiC Lab]]> <p>SONiC是微软Azure推出的一个开源的网络操作系统，它通过微服务的思想，将网络操作系统中各个服务容器化，并利用中心Redis数据库进行协作，使得每个服务都可以独立的开发、测试、部署、升级，大大的提高了网络操作系统的可靠性、可扩展性、可维护性。现在SONiC支持的交换机厂商也非常的多，包括：Arista、Broadcom、Cisco、Dell、Edgecore、Mellanox等等。然而，一台DCN交换机的价格是非常昂贵的。如果你和我一样，想试一试SONiC，但是又不想花钱买一台SONiC的硬件设备，那么这篇文章就是为你准备的。本文会大概总结一下如何通过GNS3在本地搭建一个虚拟的SONiC的Lab，让你可以很快的在本地体验一把SONiC的基本功能。</p> <p>在本地运行SONiC的方法很好几种，比如docker + vswitch，p4软交换机等等，对于初次使用而言，用GNS3可能是最方便快捷的了，所以本文就以GNS3为例，介绍一下如何在本地搭建一个SONiC的Lab。那么，我们就开始吧！</p> 漫谈中断（二）：Local APIC http://r12f.com/posts/interrupts-2-local-apic/ 2023-04-17T17:00:25.000Z 2023-04-18T00:00:25.000Z 在上一篇，我们总结了和中断相关的概念和x86平台下最基础的，基于PIC的，中断处理流程。虽然看起来PIC可以很好的解决中断的问题，而且凭借主从扩展，能力也不错（默认支持15个设备，最多64个设备），但是随着系统的发展，多处理器系统开始出现，PIC的结构就不够用了，所以，APIC（Advanced PIC）就出现了。在这一篇中，我们就来看看吧！

1. 多处理器系统中的中断问题

我们知道PIC和CPU直接相连，所以PIC其实是一个全局的中断控制器，也就是说，它只能支持一个CPU。而随着系统的发展，多核处理器开始出现，有很多问题PIC就无能为力了，比如：

  1. 当外部中断发生的时候，我们怎么知道这个中断要去哪个处理器呢？
  2. 如果一个处理器需要请求另外一个处理器发生中断，我们要如何去触发呢？
  3. 有些中断是每个处理器都需要单独处理的，比如温度过高的中断，所以我们的新模型是不是还需要支持类似PIC的本地中断处理模型呢？

于是为了解决这些问题，APIC就被发明了出来。

2. APIC（Advanced PIC）

APIC是一个全新的中断控制器架构，它的设计目标就是为了支持多处理器系统（SMP）。（这里的处理器（Processor），是指一个CPU内部的一个逻辑处理器/线程，不是指的Socket，后面只要提到处理器，我们都是指的这个相同的意思）。与PIC的monolithic设计非常不同，为了支持多处理器，APIC采用了分布式的设计，它将中断控制器分成了两个大的部分，其主要思想如下：

  1. 每个处理器都拥有自己独占的Local APIC（LAPIC），主要用来处理每个处理器本地的中断，比如时钟中断，NMI等等。这个部分一般作为处理器的一部分存在，也就是说现在处理器上提供的中断引脚，并非直接连接在处理器的核心上，而是连接在Local APIC上。
  2. 整个系统会存在一个或者多个全局共享的I/O APIC，用来处理外部设备的中断，比如，鼠标，键盘，或者其他PCI设备等等。
  3. Local APIC之间，还有与I/O APIC之间，会通过系统总线或者APIC总线来进行通信（APIC总线现在已经不用了，所以后面我们只会讨论系统总线）。外部设备的中断会被汇聚到I/O APIC上，然后通过总线发送给指定的Local APIC，最后转发给处理器。

这样，我们就可以很好的解决上面我们提到的三个问题了！它的设计总体框图大概如下：

(Source: Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1)

有意思的是，也许是Intel的工程师们，在很早就开始思考多处理器系统的问题了，所以第一个APIC的设计在Intel 80486时就已经出现了，叫做82489DX，当时才1989年，但是也许是因为当时没有多处理器的出现，所以并没有采用分离的设计，但是在1994年，奔腾（Pentium）P54C（80502）的系统中，Local APIC和I/O APIC就完全分离了。Local APIC被集成进了CPU作为CPU的一部分，而I/O APIC则是一个独立的芯片，叫做82093AA，用来处理外部设备的中断。之后随着系统的演化，I/O APIC也被集成进了南桥，后来的PCH（Platform Controller Hub），甚至与CPU内部了。

为了给大家一个直观的I/O APIC的印象，这里是一张Intel 82093AA的照片，使用的QFP64的封装：

(Source: CPU-world)

好了，那么我们先从靠核心的部分开始，Local APIC。

3. Local APIC

上面我们已经提到，Local APIC是一个针对CPU中每个处理器的本地的中断控制器，用来处理只和这个处理器相关的中断。每个Local APIC/处理器在系统启动的时候，都会被BIOS分配全局唯一的ID，并通过处理器上特定的引脚传递并保存在Local APIC ID Register中，这个ID一般也用作处理器Id，用于在整个系统中区分自己。

我们通过解析系统中的MADT（Multiple APIC Description Table）表来查看系统中所有的Local APIC，及其ID和处理器的对应关系，Windows上可以使用Firmware Tables View, Linux上可以使用acpidump，方法大家可以查看链接或者自行在网上Google，这里就不赘述了。

我用来实验的系统中有64个核，128线程，从下图中我们可以看到：

  • 在MADT表中有128个（下标127）合法的Local APIC的信息（apic_id != 0xFF && flags != 0）。
  • 对于合法的Local APIC，它们的ID和处理器的ID是一致的，不然它会是0xFF，同样，Flag中的高位第二位的1也是一个证明，它表示这个处理器是在线的（Online）或者可用的。

我们知道中断控制器主要的作用是来支持外部中断的处理，帮助CPU减负，Local APIC也是一样，其总体框图如下，我们可以在其中看到和PIC很多类似的设计，比如ISR（In-Service Register）和IRR（Interrupt Request Register）寄存器：

(Source: Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1)

Local APIC除了与CPU处理器的INTR和INTA相连以外，为了来支持更丰富的中断场景，它和CPU处理器的其他引脚也相连，比如，ExtINT，NMI，SMI，INIT等等，这些引脚的具体用途我们后面会讲到。

另外和PIC一样，Local APIC也与系统总线相连，并将其所有的寄存器都映射到内存中，这样我们就可以通过内存读写来访问它们了。Intel的文档中很清楚的描述了所有寄存器和其地址的映射关系，大家可以在这里找到Table 10-1 Local APIC Register Address Map自行查看，表有点长，这里就不放出来了，我们下面如果用到了，我们会单独把地址列出来。

默认情况下，Local APIC的寄存器都被map到0xFEE00000到0xFEE00FFF的地址空间中，但是这个地址空间是可以被修改的，我们可以通过修改Local APIC Base Address Register（IA32_APIC_BASE MSR，MSR：1BH）来修改它。

3.1. 中断类型

为了支持APIC的分布式的结构，Local APIC的一部分设计和PIC非常不同。从实现角度来看，Local APIC将外部中断又细分成了两个大类：本地中断 和 基于中断消息的中断。我们这里来依次看看这两个部分。

3.1.1. 本地中断

首先，和PIC架构设计最接近的就是本地中断的处理了，它的主要目的是用来处理和这个处理器相关的中断，比如，时钟中断，NMI中断，本地错误等等。和PIC类似，每个中断源都有其独立的引脚，而由于其集成到了处理器的内部，每个处理器对外提供的中断引脚，其实就是Local APIC的引脚了。

从上面的框图中，我们可以看到其处理的中断类型和中断源主要有如下几种：

中断源中断类型
时钟计数器时钟中断
温度传感器引脚温度传感器中断，比如过热
性能监控引脚性能监控计数器overflow时产生的中断
LINT0 / LINT1本地连接的I/O设备的中断
错误寄存器错误中断，比如，寄存器访问错误等等
3.1.1.1. 时钟中断

和PIC不同，Local APIC不再依赖外部的PIT，而是自带了一个32位的时钟，由于和处理器集成在了一起，它的时钟频率就是CPU处理器的总线频率。它由三个寄存器实现：

  • Initial Count Register（ICR，0xFEE00380）：用来设置时钟计数器的初始值，如果被设置为0，则时钟计数器会被禁用
  • Current Count Register（CCR, 0xFEE00390）：用来保存当前的时钟计数器的值，当计时开始的时候，时钟会将初始值拷贝到这个寄存器中，并开始倒数计数，而当它到0时，就会产生一个时钟中断
  • Divide Configuration Register（DCR，0xFEE003E0）：用来设置时钟计数器的时钟分频系数，比如，设置为2，则时钟计数器的时钟频率为总线频率的1/2

为了方便使用，Local APIC的时钟通过LVT表项中的配置（下面会提到）提供了三种不同的模式：

  • One-Shot Mode*：时钟倒计时完成后，时钟计数器会被禁用
  • Periodic Mode：时钟倒计时完成后，时钟计数器会被重新设置为初始值，然后继续倒数计数
  • TSC-Deadline Mode：它也是一种One-Shot模式，不同的是，在这个模式下，我们不会使用Local APIC时钟中的寄存器，而使用另一个寄存器IA32_TSC_DEADLINE MSR来指定时钟的deadline，并使用当前逻辑处理器的时间戳作为当前的时钟计数器，当其大于或等于deadline的时候，处理器就会触发中断。通过这种方式，我们可以使用绝对时间来进行中断，而不是相对时间。
3.1.1.2. LINT0 / LINT1

相比于PIC连接设备用的中断引脚，LINT0和LINT1有一点特殊，虽然它们连接的是所谓的“本地设备”，但是这两个引脚却是所有处理器都共享的！也就是说，如果中断被触发，这个中断会被传递到所有的处理器上。不过，每个处理器可以使用单独的LVT配置，来决定是否对其进行响应。

3.1.1.3. NMI

这里我们并没有看见专门用于NMI的引脚，原因是因为NMI的引脚是和LINT0/1共用的，比如，在我们上面提到的实验系统中，NMI引脚其实是连接到了LINT1上的，我们从MADT表中也可以找到这个信息（如下），而这也符合Intel的文档中对于禁用APIC的要求（NMI必须连接到LINT1引脚上）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20200925 (64-bit version)
 * Copyright (c) 2000 - 2020 Intel Corporation
 *
 * Disassembly of ./apic.dat, Sat Apr 15 01:32:36 2023
 *
 * ACPI Data Table [APIC]
 *
 * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
 */

...

[82Ch 2092   1]                Subtable Type : 04 [Local APIC NMI]
[82Dh 2093   1]                       Length : 06
[82Eh 2094   1]                 Processor ID : FF
[82Fh 2095   2]        Flags (decoded below) : 0005
                                    Polarity : 1
                                Trigger Mode : 1
[831h 2097   1]         Interrupt Input LINT : 01     // <=== LINT1

...

这里，我们可以通过Intel 82093AA的datasheet来确认这个设计：

3.1.1.4. 本地向量表（LVT）

本地向量表（LVT，Local Vector Table）是一个用于保存各个中断的配置的表，当本地中断到来之后，Local APIC便会从LVT表中找到对应的中断配置，读取中断向量号，并根据其配置开始中断处理流程，通知处理器进行处理。具体的流程，我们会放在后面基于中断消息的中断之后来一起讨论。

本地向量表由一系列寄存器组成，每个寄存器对应一个中断源，和其他寄存器一样，它也被映射到了内存空间中，方便我们进行访问：

寄存器地址用途
LVT CMCI0xFEE002F0CMCI（Corrected Machine Check Interrupt）中断
LVT Timer0xFEE00320时钟中断
LVT Performance Monitoring Counter0xFEE00340性能监控计数器overflow时产生的中断
LVT LINT00xFEE00350本地连接的I/O设备的中断
LVT LINT10xFEE00360本地连接的I/O设备的中断
LVT Error0xFEE00370错误中断，比如，寄存器访问错误等等

其中每个寄存器都是32位，保存着对应的中断向量号，当前是否有中断等待和其他配置，比如是否启用，触发方式，通过哪个针脚通知CPU，等等。具体的信息如下图所示（在这里，我们也可以看到上面提到的时钟中断的配置）：

(Source: Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1)

3.1.2. 基于中断消息（Interrupt Message）的中断

好了，现在我们已经大概了解了本地中断的接收设施了，那么如何在处理器之间发送和接收中断，还有如何接收汇聚到I/O APIC再转发过来的外部设备中断呢？这就是APIC的另一个重要的功能了，它提供了一种基于中断消息的中断处理机制，这种机制可以让我们在不同的处理器之间传递中断请求，也可以让我们处理外部设备的中断。这个机制是APIC中最重要的一部分，它也是后面更为现代的中断的基石。

由于这两种中断在接收方处理的方法是一样的，所以，我们这里就只来看看和Local APIC相关的部分：跨处理器中断（IPI，Inter-Processor Interrupt），而关于I/O APIC的中断转发，我们放在以后说I/O APIC的时候再来讨论。

3.1.2.1. 跨处理器中断（IPI）与中断命令寄存器（ICR）

跨处理器中断（IPI，Inter-Processor Interrupt）在系统中十分有用，它不仅可以用于通知对方处理器执行中断或者某些特殊操作，如Flush TLB，也可以用来给自己发送中断，打断当前执行的任务，做抢占式调度等等。

为了支持跨处理器中断，Local APIC中，有一个非常特殊的寄存器，叫做中断命令寄存器（ICR，Interrupt Command Register），他是一个64Bit的寄存器，在内存中会被map到0xFEE00300的地址上。其结构如下：

(Source: Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1)

当我们需要发送IPI消息的时候，我们要对这个寄存器进行两次操作：

  1. 写入目标处理器ID：将目标CPU的ID写入到这个寄存器的高32位，这个ID就是我们系统启动的时候给每个Local APIC和处理器分配的ID
  2. 写入中断配置：将中断向量号和其他相关的中断配置写入到这个寄存器的低32位，而这个写操作就会触发Local APIC产生一个IPI消息，发送给系统总线了

这个寄存器的结构比较复杂，以下是它每个字段的含义：

字段用途
Vector需要触发的中断向量号
Destination Mode目标处理器ID的模式，0表示物理模式，1表示逻辑模式
Destination Field目标处理器的ID，物理模式和逻辑模式下，ID的含义不同
Destination Shorthand目标处理器的范围，0x00 = 由Destination Field指定，0x01 = 自己，0x10 = 所有处理器，0x11 = 除了自己的所有处理器
Delivery Status表示中断是否已经被发送出去了，0表示当前没有消息需要发送，1表示正在等待发送
Trigger Mode目标处理器上中断的触发方式，0表示电平触发，1表示边沿触发
Delivery Mode目标处理器上如何通知处理器，比如通过IVT来触发，还是SMI，NMI或者INIT针脚来触发
Level已经基本废弃，永远为1
Reserved保留字段，必须为0

另外需要注意的一点是，如果中断消息发送失败，那么Local APIC会尝试重新发送此消息。所以，如果指定的目标处理器不存在，那么这个消息将被重复发送多次。

3.1.2.2. 目标处理器的选择

在选择目标处理器时，我们有两种方法来通过Destination Field来指定目标处理器：物理模式或者逻辑模式。这个模式可以通过Desination Mode来设置。

首先是物理模式，很好理解，这个时候Destination Field就是目标处理器的ID，也就是Local APIC的ID。

然后是逻辑模式，在这个模式下，Destination Field中我们需要填写MDA（Message Destination Address），这个MDA并不是一个真实的地址，而接收方需要根据其DFR（Destination Format Register）和LDR（Logical Destination Register）来判断是否应该接收这个消息。其流程如下：

  • 先从DFR中读取当前目标地址的格式：这个格式有4位，但是目前只有两个值：Flat Model（0b1111）和Cluster model（0b0000）。
  • 再从LDR中读取当前目标地址的值：如果是Flat model，那么这个值中的每一位代表着一个单独的处理器；如果是Cluster model，那么这个值的高4位将被看作是一个Cluster ID，低4位和Flat model一样，每一位代表着一个单独的处理器。

当然，随着时间推移，Cluster model也有了更多新的玩法，甚至需要专门的，独立于APIC之外的Cluster Manager来帮忙，但是这些都不是我们今天要讨论的内容，所以我们就不再深入了。

3.1.2.3. 消息发送

好了，我们已经知道中断是靠系统总线上的消息进行传递的，可是这个消息是如何发送到系统总线上的呢，它又长什么样子呢？

这里有一些可惜，关于Intel对系统总线的实现细节和内部消息的结构，公开的资料非常少，所以我们只能通过一些相关的资料来大概的对其进行一些猜测了。

3.1.2.3.1. 中断消息

Local APIC支持过两种总线：系统总线和APIC总线，虽然APIC总线现在已经被系统总线淘汰了，但是它的消息格式却是完全公开的。我们知道不同的片上网络会有自己的独特的消息格式，但是如果是同一个消息，那么很有可能只是用来路由的包头和包尾不同，包体很有可能是一样的，所以我们可以通过APIC总线的消息格式来推测系统总线的消息格式。

首先，是请求中断的消息，又称短消息（Short Message），它全长42个bit，用来发送绝大部分的中断，比如基于IVT, NMT, SMI, INIT, Start-up，ExtINT和带Focus的最低优先级的中断请求，其结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
struct apic_short_message {
    // Header
    uint8_t type:2;             // 0b01 = Normal interrupt
    uint8_t arbitration_id:6;   // Arbitration ID

    // Body
    uint8_t destination_mode:1; // Destination mode, 0 = Physical, 1 = Logical
    uint8_t delivery_mode:3;    // Delivery mode
    uint8_t level:1;            // Level, Always 1
    uint8_t trigger_mode:1;     // Trigger mode, 0 = Level, 1 = Edge
    uint8_t vector;             // Interrupt vector
    uint8_t destination_field;  // Destination ID
    uint8_t checksum:2;         // Checksum of packet body

    // Separator
    uint8_t reserved:2;         // Always 0

    // Reply
    uint8_t status:4;           // Destination APIC reply status

    // End
    uint8_t idle:2;             // Idle, Always 0
};

这个消息中有两处注意的地方：

  1. status字段不是由源Local APIC发送的，而是由目标Local APIC回复的，0代表成功，其他的值则代表有错误。

    (Source: Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1)

  2. 这个消息里面并没有destination_shorthand字段，当需要广播中断的时候，我们会使用physical destination mode，然后将destination field设置为0x0F，这样就可以将消息广播到所有的处理器上了。如果是需要将自己排除在广播外，那么需要源Local APIC自己做判断，发给总线上的数据包是没有区别的。

而用于ACK中断的消息，全长28个bit，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
struct apic_eoi_message {
    // Header
    uint8_t type:2;             // 0b11 = EOT
    uint8_t arbitration_id:6;   // Arbitration ID

    // Body
    uint8_t vector;             // Interrupt vector
    uint8_t checksum:2;         // Checksum of packet body

    // Separator
    uint8_t reserved:2;         // Always 0

    // Reply
    uint8_t status:4;           // Destination APIC reply status

    // End
    uint8_t idle:2;             // Idle, Always 0
};
3.1.2.3.2. 系统总线与消息发送

Intel的CPU通常使用两种体系结构中经典的系统总线来做互联：环形总线（Ring）和网状总线（Mesh）。环形总线是一个圈，所有的处理器依次连接在上面，而网状总线会复杂一些，它们在网络中形成一个网格的形式。这两种结构的区别对我们理解消息发送关系不大，所以我们就选一种比较简单的Ring来进行分析。

(左边是Ring Bus，右面是Mesh Bus，Source: Intel® Xeon® Processor Scalable Family Technical Overview)

环形系统总线其实并不是一个简单的电路环路，它是一个双向的通信通道，连接着CPU里面很多重要的模块，比如，计算处理器，图像处理单元，LLC，System Agent（以前叫un-core，里面包含了I/O接口等等）。从大的方面来说，它两个大部分组成：

  1. Ring Agent：每个处理器都有一个Ring Agent，它连接到真正的总线上，负责管理和这个处理器相关的消息。Ring Agent会进行总线的仲裁，消息路由等等操作。
  2. 四条环形总线：一个Ring Bus其实是由四条32位的环形总线组成的：Data, Request，Ack和Snoop，每条总线都是双向的，每个Clock Cycle都可以读写32个bit，并且工作频率与处理器保持一致，且随着处理器的变化而变化。

当消息从Local APIC通过Bus Interface发给Ring Agent之后，Ring Agent便会开始根据arbitration id进行仲裁，并开始寻路，将消息投递给目标处理器对应的Ring Agent上，然后Ring Agent会将消息转发给目标处理器的Local APIC，这样就完成了消息的发送。另外，关于总线的占用，虽然总线是一个环形，但是总线却是双向的，Ring Agent会永远使用和目标处理器最短的路线进行投递，并且总线还可以同时收发多条消息，只要路径上没有冲突就可以。

这样子，我们上面的消息基本上在几个Clock Cycle就可以完成发送了，如果CPU是3GHz，整个过程只需要大概1ns左右。

这里，大神Locuza对Intel Alter Lake CPU的DIE floor plan进行了一个很好的注释，也让我们可以一窥Ring Bus的真实面貌，以及它是如何连接CPU中各个模块的：

(请注意：为了节省CPU内宝贵的面积，Ring Bus和Ring Agent都是叠在LLC上方的，是一个3D的设计。Source: Die walkthrough: Alder Lake-S/P and a touch of Zen 3)

3.1.2.4. 中断接收

当IPI消息到达Local APIC时，Local APIC会对消息进行一些检查：

  1. Checksum校验：在接收过程中，Local APIC会对checksum进行校验，如果失败了，就会在status位上回复0b11，然后丢弃消息
  2. 检查目标地址：消息接收完成后，Local APIC会对目标地址进行检查，如果目标地址不是自己，那么就会将消息丢弃。具体的检查流程根据物理模式和逻辑模式的不同会有不同，我们在上面目标处理器的选择已经说过了，这里就不再赘述了。

如果检查都通过了，那么Local APIC就会根据其消息中的中断请求配置，开始和本地中断类似的正常的中断处理流程了，我们在下面马上会来介绍。

3.2. 中断请求的处理

无论是本地中断还是基于中断消息的中断，中断请求最后都会通过这最后的一步将中断请求转发给处理器，这里我们就来一起看看这个过程吧。

3.2.1. 中断寄存器

和PIC非常类似，Local APIC中有三个关键的256bit的寄存器控制中断请求的处理：

  • IRR（Interrupt Request Register，0xFEE00200）：记录中断请求的到来，每个bit对应一个中断，如果有中断请求，则会标记为1，否则为0。
  • ISR（In-Service Register，0xFEE00100）：记录中断请求正在被处理，和IRR类似，每个bit对应一个中断，如果有中断请求正在被处理，则会标记为1，否则为0。
  • TMR（Trigger Mode Register，0xFEE00180）：记录中断请求的触发模式，每个bit对应一个中断，0代表水平触发，1代表边缘触发。

3.2.2. 中断优先级

在APIC中，中断优先级依然和中断向量号相关，但是和PIC不同的是，APIC中的，中断优先级由向量号的高4位来决定。

当中断到来后，Local APIC会检查如下两个寄存器，如果待执行的中断的优先级比它们都高，则会开始通知处理器，否则就会被忽略掉，直到当前的中断处理完毕。

  • TPR（Task Priority Register）：任务优先级寄存器，这个寄存器可以被软件修改，用来屏蔽比它小的所有的中断。

  • PPR（Processor Priority Register）：处理器优先级寄存器，它是一个只读的寄存器，表示当前处理器上正在执行的中断的优先级。

3.2.3. EOI寄存器和中断处理结束

对于使用INTR引脚进行通知的中断，如Fixed Delivery Mode，当处理器处理完中断后，我们还需要进行一些清理的工作，比如，更新ISR，选择下一个中断，回复IPI消息等等。但是和PIC不同，我们不能简单的调用IRET函数，而是需要对一个叫做EOI（End Of Interrupt）的寄存器进行写操作，这个寄存器的地址是0xFEE000B0，写入任意值都可以。

这个写操作会触发Local APIC执行刚刚提到的清理操作，具体流程我们会在后面流程小结的时候和整体流程放在一起来看。

这样，我们整个中断处理流程就完成了。

3.3. xAPIC / x2APIC

在看APIC的架构的时候，我们经常看到这两个词：xAPIC和x2APIC，它们是什么呢？

这个主要是因为在1995年Intel推出的i686（P6）架构的时候，使用了APIC，但是之后，在2000年，Intel推出了新的架构NetBurst，将之前用于连接所有APIC的特有的APIC总线替换成了系统总线，于是不得不制定了新的标准 —— xAPIC（Extended APIC）。我们现在的系统里面默认跑的都是xAPIC，早期的APIC架构现在已经完全被淘汰了。

而随着系统的发展，在2008年，Intel推出了新的架构Nehalem，引入了x2APIC，它是xAPIC的升级版，它的优势在于：

  • 更大的ID：x2APIC中处理器的ID可以达到32位（Destination Field），这样在物理模式下，我们可以支持最多2^32 - 1个处理器，而虚拟模式也有所改变，我们可以支持最多2^20 - 16个处理器。
  • 更方便的操作：比如，广播用的ID变简单了，ICR中的Delivery Status也被删掉了，发送变成了Fire and forget，给自己发送中断可以使用Self IPI寄存器了，等等。

如下是x2APIC中ICR的结构，可以帮助大家更清晰的感受到和xAPIC的变化：

这些简化也带来了很多好处，比如，kvm可以通过软件模拟的方式来实现x2APIC，而不需要硬件支持，等等。

4. x86下基于Local APIC的中断处理流程小结

好了！到此，我们终于对和Local APIC的中断处理相关的每个组件都有了一个大概的认识。

首先，根据中断的分类，Local APIC处理的中断其实都属于外部中断。然后，对于Local APIC而言，中断源主要有两类：一类是本地中断，比如时钟中断，NMI中断等等；一类是基于中断消息的中断，比如IPI消息，或者I/O APIC中转发过来的中断。它们的不同主要在于中断信号接收的部分，所以这里，我们来假设当前内核已经初始化完成，系统运行在保护模式下，然后用两个例子来总结一下它们的处理流程吧！

（注：软件部分这里不会过多涉及，主要是关注在硬件的部分）

4.1. 本地中断接收流程

我们假设系统中LINT0引脚连接了一个本地设备A，并且在处理器A中的LVT将其标记为了启用，然后它触发了，那么其整体中断的流程大致如下：

  1. 设备发起中断：设备A发起中断，将LINT0引脚的电平拉高。
  2. Local APIC响应中断：处理器A的Local APIC根据当前CPU的时钟对所有引脚的电平进行检测，发现LINT0的电平变高后，便会开始读取LVT（本地向量表）中对应的配置，比如中断向量号，然后检查是否启用，向量号是否合法等等。如果没有问题，则会开始中断响应流程。

4.2. 基于中断消息的中断的发送和接收流程

我们假设系统中某个处理器B需要通知处理器A执行某个中断，那么其整体中断的流程大致如下：

  1. 源处理器B发起中断：处理器B首先将处理器A的ID写入ICR寄存器的高32位，然后将IPI消息写入低32位，用以触发Local APIC像总线发送IPI消息给处理器A。
  2. 源处理器B的Local APIC发送消息：处理器B的Local APIC将IPI消息发送给系统总线上的Agent（环形总线则是Ring Agent），然后，Agent会根据消息中的arbitration ID进行仲裁。如果仲裁成功，则开始寻路，找到去处理器A最近的路线，发送消息。
  3. 目标处理器A的Local APIC接收消息：处理器A的Agent接收到消息后，将消息转发给Local APIC，Local APIC对消息进行解析和检查，如Checksum和向量号，如果发现错误，则会立刻在status位回发错误，通知源处理器B失败。如果没有问题，则会开始中断响应流程。

4.3. 中断响应流程

到这里，中断信号已经在目标处理器A上通过了检查，接下来就可以开始正式的逻辑处理了：

  1. Local APIC检查delivery mode：Local APIC检查LVT或者IPI消息中的delivery mode，如果是NMI，SMI，INIT，ExtINIT，或者Start-up IPI，那么将直接通过特殊针脚直接转发给处理器进行处理，否则继续下一步。
  2. Local APIC记录中断：Local APIC根据收到的中断向量号，对修改IRR（中断请求寄存器）进行更新，将对应的位设置为1，表示有中断正在等待处理。
  3. Local APIC进行优先级检查：Local APIC获取当前IRR中的最高的bit来进行优先级检查，对比当前TPR（Task Priority Register）和PPR（Processor Priority Register）中的值，如果优先级不满足，则继续等待，直到处理器上当前的中断处理完毕。
  4. Local APIC通知处理器中断到来：Local APIC更新IRR和ISR，将IRR中选中的中断向量号对应的标志位至0，ISR中的置1，然后将处理器的INTR引脚电平拉高，通知处理器中断到来。此时，如果新的中断到来，会被继续保存在IRR中，而如果发生了中断嵌套，ISR寄存器则会出现多个标志位置为1的情况。
  5. CPU响应中断：处理器收到INTR引脚的电平变化后，会等待当前正在执行的指令的完成，然后停止执行，准备中断处理。这个时候，CPU上CS:IP保存的地址是下一条指令的地址。
  6. CPU获取中断向量号：CPU通过系统总线向Local APIC获取存储在ISR寄存器中的中断向量号。
  7. CPU通知Local APIC中断响应：CPU通过INTA引脚通知PIC中断已经被响应，但是此时APIC并不会把ISR寄存器清0。
  8. Local APIC取消中断信号：APIC恢复INTR引脚的电平，这样CPU就可以继续接收新的中断了，这是为了支持中断嵌套。
  9. CPU读取中断描述符：CPU从IDTR寄存器中获取中断描述符表的地址，然后根据中断向量号来获取中断描述符，并通过GDTR寄存器找到GDT的基址和段描述符，最后结合IDT中的CS:IP，计算出ISR的最终地址。
  10. CPU进行特权级检查：CPU根据中断描述符中的特权级（DPL）来检查当前的特权级（CPL）是否满足中断描述符的要求，如果不满足，就会触发一个特权级异常并结束中断。
  11. CPU暂停接收中断信号：CPU根据当前中断描述符的类型，有选择的修改IF标记，暂停中断信号的接收，这是为了能安全的保存上下文。
  12. CPU保存当前的上下文：这里的上下文并不是完整的上下文，只是保存了当前的CS，EIP和EFLAGS寄存器。如果在步骤8中发现需要进行栈切换，那么这里还会保存SS和ESP寄存器。
  13. CPU跳转至中断服务例程：根据步骤7中计算出的ISR地址，CPU更新指令寄存器，跳转到中断服务例程。
  14. 中断服务例程开始（SOI）：开始阶段，中断服务例程会做两件事情，一个保存当前的进程更加完整的上下文，另一个是如果允许中断嵌套，则会开始恢复中断，但是不同的系统做的事情可能略有不同。
  15. 中断服务例程执行：这里就是执行中断服务例程的主逻辑了，另外，在linux内核中，为了保证中断响应速度，硬中断处理的代码会尽量的短，处理器逻辑会被移入软中断中来实现，这里就不多展开了。
  16. 中断服务例程结束（EOI）：结束阶段，中断服务例程会做两件事情，首先再次禁止中断，保证上下文安全的恢复，然后从堆栈中恢复当前进程的上下文。
  17. CPU恢复上下文：中断服务例程的最后会给EOI寄存器中写入任意值，通知中断完成，然后调用iret指令，将控制流交还给CPU，CPU会从堆栈中恢复CS、EIP、EFLAGS寄存器，然后重置IF标记，恢复中断信号的接收。此时CS和EIP指向的是中断前CPU执行的下一条指令，于是CPU可以恢复指令执行。
  18. Local APIC更新ISR：将ISR寄存器中最高的为1的bit置为0，表示中断处理完成。
  19. Local APIC选择下一个中断：Local APIC会根据当前的IRR（Interrupt Request Register）寄存器中的值，选择下一个优先级最高的中断（最高位），继续通知处理器进行处理。
  20. Local APIC回复IPI消息：如果当前中断是IPI消息，那么Local APIC会向发送者回复EOI消息，通知其处理完成。如果TMR（Trigger Mode Register）寄存器中的值为1（水平触发），那么此时会给所有的I/O APIC广播EOI消息。
  21. 结束：中断处理结束。

5. 小结

好了，在这一篇中，我们详细总结了和x86平台下和Local APIC相关的中断请求和处理流程。这一篇总结虽然有点长，而且细节也较多，但是，有了它我们就可以更方便的理解IO APIC的中断处理和其他更现代的中断方式，比如：MSI/MSI-X了。

另外，ARM上解决方式也非常类似，与APIC对应的架构叫做GIC，而Local APIC对应着里面的CPU Interface，我们这里不会深入的讨论，如果后面有时间，我们再补上。

6. 参考资料

同系列文章：
原创文章，转载请标明出处：Soul Orbit
本文链接地址：漫谈中断（二）：Local APIC]]> <p>在上一篇，<a href="/posts/interrupts/">我们总结了和中断相关的概念和x86平台下最基础的，基于PIC的，中断处理流程</a>。虽然看起来PIC可以很好的解决中断的问题，而且凭借主从扩展，能力也不错（默认支持15个设备，最多64个设备），但是随着系统的发展，多处理器系统开始出现，PIC的结构就不够用了，所以，APIC（Advanced PIC）就出现了。在这一篇中，我们就来看看吧！</p> <h2 id="多处理器系统中的中断问题">1. 多处理器系统中的中断问题</h2> <p>我们知道PIC和CPU直接相连，所以PIC其实是一个全局的中断控制器，也就是说，它只能支持一个CPU。而随着系统的发展，多核处理器开始出现，有很多问题PIC就无能为力了，比如：</p> <ol> <li>当外部中断发生的时候，我们怎么知道这个中断要去哪个处理器呢？</li> <li>如果一个处理器需要请求另外一个处理器发生中断，我们要如何去触发呢？</li> <li>有些中断是每个处理器都需要单独处理的，比如温度过高的中断，所以我们的新模型是不是还需要支持类似PIC的本地中断处理模型呢？</li> </ol> <p>于是为了解决这些问题，APIC就被发明了出来。</p> 漫谈中断（一）：PIC http://r12f.com/posts/interrupts/ 2023-04-11T23:45:31.000Z 2023-04-12T06:45:31.000Z 这段时间想把Linux的网络栈给理顺一下，然后发现在读书的时候，很多书对于中断的产生都是很快的带过了，解释的并不是非常的清楚。虽然这个原因很好理解 —— 这些书的重点在于内核如何处理，但是我总觉得这样的话，我的知识的拼图就少了很重要的一块，所以就单独看了看（硬件）中断这一部分。看完之后发现其实内容也挺多的，所以在这里小小的总结一下，正因如此，这篇博客会更加注重硬件的层面，至于软件上如何进行处理，大家可以参照对应的内核书籍，这里就不多说了。

另外因为内容太多，所以这篇文章主要会借用x86/x64的架构来作为例子，arm的架构我们可以在后面的文章中再来讨论。

好了，闲话少说，我们这就开始！

1. 中断（Interrupt）

所谓中断，顾名思义，就是一种可以打断处理器当前运行的程序，转而去运行其他的程序的方式。当某些特定事件（event）被触发，如外部设备完成特定操作，或者执行了未知的指令，或者访问了无法访问的内存，处理器就会触发一个中断请求（IRQ, Interrupt Request），来对其进行处理。通过这种方式，我们可以快速的对这些事件进行响应。

中断理论上分为三类：外部中断（External Interrupt），软件中断（Software Interrupt）和内部中断（Internal Interrupt）。不同的平台的分类经常有些许不同，但是大体都差不多，比如，intel就把它分类为：外部中断，可忽略的硬件中断，软件中断和异常。所以这里我们就不过多的对它们的叫法进行展开了，而是来依次看一看其内部的细节。

1.1. 外部中断

外部中断（External Interrupt），又叫硬件中断或者硬中断（Hardware Interrupt），是由外部硬件设备，以异步的方式，产生的中断。它一般通过触发CPU上对应的中断引脚来通知CPU对其进行处理，这就是中断请求（Interrupt Request，IRQ）。

中断请求其实非常简单，大体上都是用CPU上的中断引脚（Interrupt Input Pin）上的电平变化来表示的，无论是从低电平变为高电平或者从高电平变为低电平都可以。处理器会根据其内部时钟不停的对这个引脚的电平进行检查，如果发现电平变化了，就知道中断请求来了，于是就会跳转至中断处理例程（ISR, Interrupt Service Routine）进行处理。

这里我手上正好有一些小的模块，我们可以看到他们都有一个INT引脚，这个引脚就是用来发起中断请求的：

devices-and-interrupt-pins

看到这里，我们很容易联想到几个问题：

  • 如果有多个设备怎么办？处理器如何知道是哪个设备发出的请求的呢？
  • 处理器是如何找到设备对应的中断处理例程的呢？
  • 多个设备同时发起请求要如何解决呢？如果某个高优先级设备发起了中断，而处理器正在处理另一个低优先级设备的中断该怎么办呢？
  • 当中断处理结束之后，中断又是如何被清除的呢？

而这些问题，也是一个基本的中断的处理系统需要处理的核心问题，无论是那种指令集和架构，比如x86和arm。我们接下来在讨论完中断的类型之后，就来依次看一看这些问题。

1.2. 软件中断

软件中断（Software Interrupt），又叫自陷（Trap），顾名思义，是由软件，以同步的方式，产生的中断。它一般是通过调用特定的指令来触发的，比如x86的int指令，arm的swi指令。

它与外部中断有几点不同：

  1. 首先，它是由指令触发的，所以它的触发是同步的，也就是说，当我们调用了int指令之后，处理器就会立即跳转至中断处理例程进行处理，而不会等待CPU中断引脚的电平发生变化。
  2. 其次，它的中断处理例程一般是由OS来指定的，与外部设备没有关系，比如，int 3调用breakpoint中断处理例程，int 0x80调用系统调用中断处理例程（现在已经不用了），等等。
  3. 最后，它的中断向量号是由指令的操作数来指定的，所以不需要通过中断控制器来进行中断向量号的分配。（关于中断控制器和中断向量号，我们后面会讲到）

1.3. 内部中断

内部中断（Internal Interrupt），又叫异常（Exception），是由处理器，以同步的方式，产生的中断。它一般是由处理器内部的一些特殊的事件触发的，比如，除0错误，内存访问错误，系统调用，等等。

它和前两种中断也有些许的不同：

  1. 首先，它是由处理器内部的一些特殊的事件触发的，所以它的触发是同步的，也就是说，当处理器内部的某个事件发生时，处理器就会立即跳转至中断处理例程进行处理，而不会等待CPU中断引脚的电平发生变化。
  2. 其次，它的中断向量号都是处理器hardcode的，所以不需要通过中断控制器来进行中断向量号的分配。（关于中断控制器和中断向量号，我们后面会讲到）
  3. 和软件中断一样，它的中断处理例程也是一般由OS来指定的，与外部设备没有关系。

2. 多设备处理

由于处理器不知道有多少的设备会连接上，所以没有办法给每一个设备都预留一个中断用的引脚，而且这样也是对引脚的一种浪费，所以一般来说，CPU（核心）都只有一条中断请求引脚（INT/INTR）和一条中断确认引脚（INTA），而这也引入了我们的第一个麻烦 —— 我们要如何接收多设备的请求并且知道请求的来源呢？

2.1. 中断控制器（PIC）

首先，我们来解决发送中断请求的问题。我们先祭出计算机界的老套路，直接来不行，就加一层帮忙，而在中断处理中，这一层就是中断控制器（PIC，Programmable Interrupt Controller），它在主板上用来连接CPU和所有的外部设备，帮助CPU将并发的，带优先级的中断信号，转换成串行的中断信号，简化CPU的设计。

中断控制器出现的非常的早。早在1976年，Intel的MCS-85系列（8085）的CPU就用上了中断控制器 —— 8259，后来1983年，在8088上升级为了8259A，它和CPU的中断引脚直接相连，支持8个中断引脚连接8个设备，并且有8个数据引脚连接到总线，让处理器读取和写入中断相关的数据和配置，另外它还支持级联连接，有一个主8259A连接8个从8259A，这样最多可以连接64个外部设备，这对于当时的系统来说已经是非常强力了，不过一般根本用不了这么多，所以当时的主板上是一个主加一个从，一共可以连接15个外部设备，而这个设计也一直保留了下来，哪怕我们现在最新的intel cpu的设计中，也还是可以看到它的身影。

为了支持中断发送，PIC和CPU的两个中断引脚直接相连：

  • INTR：用于PIC发送中断给CPU
  • INTA：CPU接收到中断并且开始处理后，会激发该引脚（高电平转低电平），通知PIC中断已经接收，这样PIC就可以继续接收之后的中断请求，而不用担心请求过快而丢失了。

为了检查来自设备的中断，8259的IRQ0引脚连接着一个可编程时钟（Programmable Interval Timer，PIT），最开始是8253/8254，它最快的频率是1.1931816MHz，也就是说，它每隔838ns会检查一次INTR引脚的电平，如果发现电平变化了，就会将中断请求发送给CPU。当然现在的PIC连接的一般都是处理器的FSB时钟了，所以速度相比当时就会快非常多了，比如Intel i9-13900k的FSB是100MHz，也就是说，它每隔10ns就会检查一次中断引脚的电平了。

为了进行中断控制，PIC中还有三个非常重要的，可以被读写的，8-Bit寄存器：

  • Interrupt request regsiter (IRR)：它存储着所有的当前已经触发的中断信号，一个bit一个信号，越高的bit，优先级也越高。
  • Interrupt service register (ISR)：它存储着当前CPU上正在处理的中断信号。
  • Interrupt mask register (IMR)：它存储着哪些中断信号被启用的状态，1代表启用，0代表禁用。被禁用的中断信号将不会被传递给CPU。

通过它们，PIC就可以来对中断触发进行控制了。

这里为了帮助大家更好的建立一个直观的印象，这是一个当时给Intel 8088 CPU使用的8259A：

(Source: Intel 8259 Wikipedia)

这是从当年Intel 8259A的datasheet中找出来的的框图，我们可以很清晰的看见其中断引脚和数据通道，和DIP28的封装：

(Source: Intel 8259A datasheet)

当然随着时间的发展，现在我们已经无法在主板上找到一个单独的中断控制器的芯片了，这个芯片已经被集成进了南桥，和（部分集成进了）后来的PCH（平台路径控制器，Platform Controller Hub）了。

2.2. 中断向量化

太好了！有了PIC之后，处理器就可以通过两根引脚来接收所有的设备中断了！但是……太惨了！只有两根功能如此简单引脚，我们怎么知道中断是谁发的啊？

当然，我们可以直接一把梭，大力出奇迹！在ISR（中断服务例程）里面一通轮询不就完了？这就是我们说的非向量化的中断处理流程了。在这种模式下，ISR基本逻辑如下：

1
2
3
4
5
6
7
8
9
if (is_interrupted(device_a)) {
    call_service_routine_a();
}

if (is_interrupted(device_b)) {
    call_service_routine_b();
}

// ...

这缺点不要太明显……这速度也太慢了，而且要怎么扩展啊？所以我们来重构吧！一般遇到这种代码，我们都会把他变成一个数组，通过一个下标来找到对应的函数直接调用，于是向量化中断（vectored interrupting）就出现了！

所以向量化中断主要做了两件事情：

  1. 把所有的中断服务例程放在一个结构体数组中，这就是中断描述符表（IDT，Interrupt Descriptor Table，或者叫中断向量表，IVT，Interrupt Vector Table）。
  2. 给每个设备或者中断会被赋予一个id，当中断被触发后，我们可以通过某种方式拿到这个id，将其作为中断向量表的下标，找到对应的ISR进行调用，这个id就是中断向量号（IVN，Interrupt Vector Number）。

可是，老问题又出现了，我们去哪里找中断描述符表和中断向量号呢？他们具体又长什么样子呢？

2.2.1. 中断描述符表（Interrupt Descriptor Table）

在x86/x64平台上，中断描述符表的地址被保存在一个叫IDTR（Interrupt Descriptor Table Register）的寄存器中，这个寄存器有48位，高32位是中断描述符表的起始地址（在x64中是64位），低16位是中断描述符表的大小。用C语言来表示的话，就是这样的：

1
2
3
4
struct idtr {
    uint16_t limit;
    uint32_t base; // uint64_t in x64
} __attribute__((packed));

当CPU收到中断时，会通过IDTR来找到中断描述符表，然后通过中断向量号来找到对应的中断服务例程。而由于IDTR的引入，我们可以把中断描述符表放在任意的内存地址中，而不是像之前那样只能放在内核空间的某个地方。这也让中断描述符表的使用变得更加灵活了。

在系统启动之后，中断描述符会被处理器默认设置为Base = 0x00000000，Limit = 0xFFFF，然后启动过程中，BIOS会重新对其进行一次映射，将BIOS的默认例程映射到中断描述符表中，接下来OS会再次对其进行初始化，将OS的ISR写入其中，当全部完成后，中断描述符表就被初始化完成了。

这里是一个x86平台的中断描述符表的示意图：

(Source: Real-Time Embedded Systems, Design Principles and Engineering Practices, Chapter 4.7 Case Study: x86)

2.2.2. 中断描述符（Interrupt Descriptor）

2.2.2.1. x86平台下的中断描述符

中断描述符表中的每一项都是一个中断描述符，它包含了中断服务例程的地址，以及一些其他的信息。x86平台下的中断描述符，大小为8个字节，用c语言来表示如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
struct idt_entry {
    uint16_t base_lo; // 中断服务例程的低16位，task gate没有这个字段
    uint16_t sel;     // 段选择子
    uint8_t  always0; // 保留字段，必须为0
    union {
        uint8_t  flags;   // 中断描述符标志
        struct {
            uint8_t type : 3;             // 中断门类型
            uint8_t size : 1;             // 中断门大小，0 = 16-bit, 1 = 32-bit
            uint8_t descriptor_type : 1;  // 描述符类型，0 = 系统描述符，1 = 代码或数据描述符，
                                          // 对于中断描述符来说，这个字段必须为0
            uint8_t dpl : 2;              // 描述符特权级（Descriptor Privilege Level）
            uint8_t p : 1;                // Segment Present Flag
        };
    };
    uint16_t base_hi; // 中断服务例程的高16位，task gate没有这个字段
} __attribute__((packed));

而根据不同的中断类型，Intel的手册中定义了三种不同中断描述符，分别是：中断门（Interrupt Gate）描述符，陷阱门（Trap Gate）描述符，任务门（Task Gate）描述符。它们的结构和行为也有着些许的区别：

类型行为中断门类型中断门大小
中断门中断门用于处理中断，触发时会清除IF标记来禁止中断0b1100b1
陷阱门和中断门十分类似，但是不会清除IF标记来禁止中断0b1110b1
任务门任务门用于处理任务切换0b1010b0

(Source: Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1, Chapter 6.11 IDT Descriptors)

2.2.2.2. x64平台下的中断描述符

x64平台上会有些许不同，主要是地址的宽度变成了64位，所以中断描述符大小变成了16个字节，多了4个字节来存放高32位的地址，而且中断门类型和中断门大小的字段也变成了4位和1位，具体的结构如下：

(Source: Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1, Chapter 6.14.2 64-Bit Mode Stack Frame)

2.2.2.3. 中断特权级（DPL）

中断描述符中还需要注意的是中断的特权级（DPL），它的值可以是0、1、2、3，分别对应着Ring 0、Ring 1、Ring 2、Ring 3。这个特权级只对软件中断有效，比如int调用，CPU在接收到软件中断时，会对其进行检查：

  • 如果当前的特权级（CPL）比DPL高，也就是说现在的程序没有权限调用这个中断服务例程，这时候就会触发一个异常，异常号为13（#GP，General Protection）。
  • 如果当前的特权级（CPL）比DPL低，也就是说权限没有问题，但是上下文有问题，这时候CPU会进行调用栈切换，找到一个合适的栈来执行中断服务例程。
  • 如果当前的特权级（CPL）和DPL相等，也就是说权限没有问题，上下文也没有问题，CPU就会直接执行中断服务例程。

当然，每个中断描述符也有自己的优先级，x86平台上，Intel定义的优先级如下：

(Source: Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1, Chapter 6.9 PRIORITY AMONG SIMULTANEOUS EXCEPTIONS AND INTERRUPTS)

2.2.3. 中断向量号（Interrupt Vector Number）

有了中断描述符表，我们就可以把中断服务例程放在任意的内存地址中了，但是我们还需要一个东西来告诉CPU，中断服务例程（ISR）在哪里，这个东西就是中断向量号（IVN）。

中断向量号是一个8位的无符号整数，它的值是0-255，从上面的中断向量表的图中，我们可以看到，在x86系统中，中断向量号主要分为两个区域：

  • 0-31：这些是CPU保留的向量号，用于CPU内部的异常处理，这些中断的向量号都是每个系统中硬编码的，x86和arm平台上的中断向量号是不一样的。
  • 32-255：这些是外部中断可用的向量号，可以由BIOS或者OS来进行配置，提供每个设备对应的中断描述符。而当外部中断发生的时候，我们也需要获取对应的中断向量号，然后进行调用。

可是中断向量号要如何获取呢？别着急，我们不是刚刚提到了中断控制器（PIC）吗？还记得它有8个引脚连着总线吗，在CPU中断被触发之后，CPU就会自动的通过总线去问PIC拿IVN（中断向量号），这样问题就解决啦！

ARM的平台上也是非常的类似，有机会我们后面再聊。

3. 中断嵌套（Interrupt Nesting）和中断服务例程

之前我们提到一个问题，如果CPU在处理某个中断时，更高优先级的中断出现了怎么办？我们有两个选择：

  1. 我们可以在处理中断的过程中，全程禁止中断，这样就不会有更高优先级的中断进入了。
  2. 我们可以将当前的中断中断下来，然后去处理新的中断，这就是中断嵌套了。

方法一很简单，但是如果某些中断处理时间过长，就会导致系统性能猛烈下降，因为系统无法及时的处理更高优先级的中断，比如，键盘鼠标无法响应，这样就会导致系统的卡顿。所以很多时候，OS会选择方案二，也就是中断嵌套。

中断嵌套中需要注意的点就是如何安全的保存和恢复当前程序的上下文，而这没有什么魔法，无论是什么平台，解决方法都类似，而且简单粗暴 —— 如果有必要就禁止中断。

  1. 第一步，在中断发生后，CPU进入ISR之前，除了上面我们提到的一些权限检查的操作，为了保存上下文，CPU主要做了两件事情：1）（可选）禁止中断，避免其他的中断在上下文未保存完成前进入；2）将当前的指令寄存器（x86上的CS, EIP和arm上的R15）和极少数特别的状态寄存器（如x86上的EFLAGS和arm上的CPSR）保存到栈上（intel）或者其他寄存器（arm）上。
  2. 第二步，CPU将进入ISR（中断服务例程），此时中断服务例程将继续CPU未完成的动作，保存更多会被影响的寄存器到栈上，然后恢复中断，这也会使系统允许中断嵌套。
  3. 第三步，终于，我们可以开始执行ISR的主体逻辑了，在电平触发的中断中，这里也会通知设备中断完成，让其将中断线上的电平修改回去。
  4. 第四步，ISR主体执行完毕后，ISR需要再次停止中断，把之前保存的寄存器从栈上恢复出来，然后将控制返还给CPU（比如，调用x86下的iret指令）。
  5. 第五步，CPU会将保存的指令寄存器和状态寄存器恢复回来，并重新启用中断。

到此，中断服务例程调用完毕。整个过程中我们可以看到CPU是如何和ISR协同完成这个任务的，而也正因为如此，ISR的设计依赖于CPU的Contact，这也导致了第二步到第四步成为了所有ISR的模板，而它们也有了自己特有的名字：第二步叫做SOI（Start Of Interrupt），第四步叫做EOI（End Of Interrupt）。

对更多细节感兴趣的朋友，可以移步Intel的官方文档：Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1, Chapter 6.12, 6.14。

另外，我们应该保证中断服务例程足够的小，尽快的退出，因为即便是最低优先级的中断，也比用户态最高优先级的优先级高，如果中断无法结束，用户态的程序将永远得不到机会处理，比如，x11或者app可能完全无法绘制屏幕，用户态的网络程序无法响应网络请求等等。有兴趣的朋友可以搜索一下“中断风暴”，这里就不过多的展开了。

4. 中断链（Interrupt Chainning）和中断级联（Interrupt Cascading）

由于中断服务例程可以被覆盖，所以在使用中断的时候，我们通过使用新的例程覆盖老的例程的方法，来得到两种新的玩法：中断链和中断级联。这两个玩法的概念都很好理解，唯一需要注意的事情是，EOI最多只能被调用一次：

  • 中断链：在上层的中断服务例程的最后，跳转到下层的中断服务例程（避免重复的EOI调用），一般用于OS或设备的ISR调用被覆盖掉的默认ISR。

    (Source: Real-Time Embedded Systems, Design Principles and Engineering Practices, Chapter 4.5.3 ISR Chaining)

  • 中断级联：在上层的中断服务例程中，通过if else来进行判断，并跳转到下层的中断服务例程，但是只有最底层的ISR的EOI会被调用。

    (Source: Real-Time Embedded Systems, Design Principles and Engineering Practices, Chapter 4.5.4 ISR Cascading)

不过，这些在linux系统中都没有被使用，所以了解了就可以了，我们就不再过多的讨论了。

5. 中断信号

虽然中断信号听起来很简单，但是里面其实也有一些小的有意思的点，所以在我们做最后的总结之前，我们还是来仔细看看中断信号吧！

一般来说，中断信号分为两类：电平触发（也叫水平触发，level-sensitive）中断和边缘触发（edge-triggered）中断。它们的特点总结如下：

中断信号类型触发条件优点缺点
电平触发外部设备的中断线上的电平一直保持到中断服务例程处理完毕中断服务例程可以在中断发生后，不需要立即处理，可以等到合适的时候再处理，而不会丢失中断中断服务例程必须要通知设备取消中断，否则中断线上的电平将一直保持，这样会导致中断服务例程被重复调用，另外如果有设备出错无法取消中断，就会引起中断死循环
边缘触发外部设备的中断线上的电平只有在发生变化的时候才会触发中断可以减少设备出错带来的影响，因为中断线的电平不会一直保持中断服务例程必须要立即处理，否则会导致中断丢失

这里选择哪种类型的中断信号，是可以由设备本身来决定的，所以中断系统必须要能够兼容两种类型的中断信号。而我们知道外部设备都是通过PIC来连接CPU的，所以这也就意味着中断着PIC必须能够支持这两种信号，并且能够处理两个问题：

  1. 电平触发时，设备出错，无法取消中断，导致中断死循环
  2. 边缘触发，无法马上处理而导致的中断丢失

当然解决方法并不难，PIC中的IRR（Interrupt Request Register）会保存中断线上的电平，所以可以充当这个缓存寄存器，然后在中断服务例程中，通过读取缓冲寄存器来判断中断是否已经被处理，如果没有被处理，就再次触发中断，直到中断被处理为止。这样就能够解决这两个问题了。

6. NMI（Non-Maskable Interrupt）

NMI是一种特殊的中断，顾名思义，它的特点是不会被屏蔽。NMI一般是通过硬件电路来触发的，与INTR引脚（通过PIC进行屏蔽）不同，CPU上会有一个专门用于处理NMI请求的引脚，绕过PIC直接与触发NMI的设备相连，所以也相对不可控。另外NMI中断的优先级也相对较高，比如，比所有通过INTR来的外部硬件中断都要高。也正因为如此，NMI一般用于处理一些比较严重的错误，比如，CPU温度过高，供电出错，内存出错等等。

在x86上，NMI的中断向量号是hardcode的2，除了硬件触发以外，我们还可以通过调用int 2来进行软件触发，但是这种方式不会修改NMI引脚电平的状态，而且一般不会被使用。

关于所有中断的优先级，可以参照上面中断向量表中的图表，这里就不重复了。

7. x86中断处理流程小结

好的，到此我们对x86下参与中断的各个部件的工作原理都有了一个比较大概的认识了，那么我们就来总结一下x86中断处理流程吧！

首先，在x86系统上我们有4中不同的中断源，它们的中断流程类似，唯一不同的是中断向量号的获取方式：

  1. 外部中断：通过PIC来触发，中断向量号是通过PIC的ISR（Interrupt Service Register）来获取的
  2. NMI：通过硬件电路来触发，中断向量号是2，也可以由int 2来触发，通过操作数来获取
  3. 软件中断：通过int指令来触发，中断向量号是通过操作数来获取的
  4. 内部中断：所有的中断向量号都是hardcode在CPU中的，无需额外获取

然后，我们假设系统中某个设备A连接到了PIC的IRQ5上，内核已经初始化完成，系统运行在保护模式下，然后发生了中断，那么其整体中断的流程大致如下（软件部分这里不会过多涉及，主要是关注在硬件的部分）：

  1. 设备发起中断：设备A发起中断，将PIC上IRQ5引脚的电平拉高。
  2. PIC响应中断：PIC根据FSB的时钟对所有引脚的电平进行检测，发现IRQ5的电平变高后，会将其保存到IRR寄存器中，如果当前IMR寄存器没有禁用该引脚，没有更高优先级的中断（引脚号更高），且当前CPU没有处理中断，那么PIC就会将ISR寄存器的第5位设置为1，然后将CPU的INTR引脚拉高，通知CPU有新的中断发生。
  3. CPU响应中断：CPU收到INTR引脚的电平变化后，会等待当前正在执行的指令的完成，然后停止执行，准备中断处理。这个时候，CPU上CS:IP保存的地址是下一条指令的地址。
  4. CPU获取中断向量号：CPU通过系统总线向PIC获取存储在ISR寄存器中的中断向量号。
  5. CPU通知PIC中断响应：CPU通过INTA引脚通知PIC中断已经被响应，PIC会将IRR寄存器和ISR寄存器的第5位清零。
  6. PIC取消中断信号：PIC恢复INTR引脚的电平，这样CPU就可以继续接收新的中断了，这是为了支持中断嵌套。
  7. CPU读取中断描述符：CPU从IDTR寄存器中获取中断描述符表的地址，然后根据中断向量号来获取中断描述符，并通过GDTR寄存器找到GDT的基址和段描述符，最后结合IDT中的CS:IP，计算出ISR的最终地址。
  8. CPU进行特权级检查：CPU根据中断描述符中的特权级（DPL）来检查当前的特权级（CPL）是否满足中断描述符的要求，如果不满足，就会触发一个特权级异常并结束中断。
  9. CPU暂停接收中断信号：CPU根据当前中断描述符的类型，有选择的修改IF标记，暂停中断信号的接收，这是为了能安全的保存上下文。
  10. CPU保存当前的上下文：这里的上下文并不是完整的上下文，只是保存了当前的CS，EIP和EFLAGS寄存器。如果在步骤8中发现需要进行栈切换，那么这里还会保存SS和ESP寄存器。
  11. CPU跳转至中断服务例程：根据步骤7中计算出的ISR地址，CPU更新指令寄存器，跳转到中断服务例程。
  12. 中断服务例程开始（SOI）：开始阶段，中断服务例程会做两件事情，一个保存当前的进程更加完整的上下文，另一个是如果允许中断嵌套，则会开始恢复中断，但是不同的系统做的事情可能略有不同。
  13. 中断服务例程执行：这里就是执行中断服务例程的主逻辑了，另外，在linux内核中，为了保证中断响应速度，硬中断处理的代码会尽量的短，核心逻辑会被移入软中断中来实现，这里就不多展开了。
  14. 中断服务例程结束（EOI）：结束阶段，中断服务例程会做两件事情，首先再次禁止中断，保证上下文安全的恢复，然后从堆栈中恢复当前进程的上下文。
  15. CPU恢复上下文：中断服务例程的最后会调用iret指令，将控制流交还给CPU，CPU会从堆栈中恢复CS、EIP、EFLAGS寄存器，然后重置IF标记，恢复中断信号的接收。
  16. 结束：中断处理结束，此时CS和EIP指向的是中断前CPU执行的下一条指令，于是CPU可以恢复指令执行。

这就是x86系统下，中断的整个执行流程了。

8. 小结

好了，到此基本的x86中断处理流程就总结完毕了。当然随着计算机的发展，现代的x86系统已经基本不用8259的中断方式了，但是它的思想和类似的使用方法却是非常常见的，比如ARM的AIC，Intel的APIC Bypass模式，和Intel APIC中的Local APIC对中断的处理。不过这篇文章就先记录到这里，后面有时间再继续补充吧。

9. 参考资料

同系列文章：
原创文章，转载请标明出处：Soul Orbit
本文链接地址：漫谈中断（一）：PIC]]> <p>这段时间想把Linux的网络栈给理顺一下，然后发现在读书的时候，很多书对于中断的产生都是很快的带过了，解释的并不是非常的清楚。虽然这个原因很好理解 —— 这些书的重点在于内核如何处理，但是我总觉得这样的话，我的知识的拼图就少了很重要的一块，所以就单独看了看（硬件）中断这一部分。看完之后发现其实内容也挺多的，所以在这里小小的总结一下，正因如此，这篇博客会更加注重硬件的层面，至于软件上如何进行处理，大家可以参照对应的内核书籍，这里就不多说了。</p> <p>另外因为内容太多，所以这篇文章主要会借用x86/x64的架构来作为例子，arm的架构我们可以在后面的文章中再来讨论。</p> <p>好了，闲话少说，我们这就开始！</p> <h2 id="中断（Interrupt）">1. 中断（Interrupt）</h2> <p>所谓中断，顾名思义，就是一种可以打断处理器当前运行的程序，转而去运行其他的程序的方式。当某些特定事件（event）被触发，如外部设备完成特定操作，或者执行了未知的指令，或者访问了无法访问的内存，处理器就会触发一个中断请求（IRQ, Interrupt Request），来对其进行处理。通过这种方式，我们可以快速的对这些事件进行响应。</p> <p>中断理论上分为三类：<strong>外部中断（External Interrupt）</strong>，<strong>软件中断（Software Interrupt）<strong>和</strong>内部中断（Internal Interrupt）</strong>。不同的平台的分类经常有些许不同，但是大体都差不多，比如，intel就把它分类为：外部中断，可忽略的硬件中断，软件中断和异常。所以这里我们就不过多的对它们的叫法进行展开了，而是来依次看一看其内部的细节。</p> 测试，你写代码时最好的朋友（下篇） http://r12f.com/posts/make-tests-your-friends-final/ 2022-12-26T23:02:58.000Z 2022-12-27T07:02:58.000Z 我们终于来到了这个系列的最后一篇，在上一篇中，我们讨论了如何写出好的测试，如何利用数据驱动测试来降低测试的维护成本，提高程序和测试的可观察性，并且提高错误调试的速度。希望到了现在，你会开始觉得数据驱动测试相当方便，并跃跃欲试的想在自己的项目里面进行实践。

不过，如果我们仅仅到此为止，那就真的太浪费了。我们还只刚刚解锁了它的一半威力而已！我们这一篇就来讨论以下它的进阶版本，我称其为面向数据的测试，并且利用它做到线下测试即线上测试，从而实现测试的大统一！

1. 数据驱动测试（DDT）

首先，我们先来快速回顾一下数据驱动测试吧！

数据驱动测试，顾名思义，其特点就是将被测试程序的输入通过数据的方式进行存储，并在测试时依次循环执行，最后将被测试程序的输出与预先设置好的期望结果进行对比，从而达到测试的目的，流程大致如下：

data-driven-testing.png

使用数据驱动测试，优点就是使用方便，并且可以有效的降低代码量，但是其缺点也很明显：

  1. 测试数据庞大，维护复杂，但是我们在第二篇也通过生成基线的方式解决了该问题。通过这种方式，可以极大的减少人员成本。
  2. 随着测试的量越来越大，我们的测试数据集也会越来越大，特别是在大模块和服务的E2E的测试中，场景的状态会产生组合爆炸的问题，最终导致了一个新的问题：维护测试数据集的成本越来越高。
  3. 数据驱动测试对随机测试（fuzz test）不是非常友好，因为我们没有这些随机数据对应的参照结果，所以一般最后都只尝试捕获类似于崩溃这种的重大问题，而不能对具体的业务逻辑进行测试。

所以，这些问题有没有什么办法解决呢？

2. 测试即知识

另外我们再回头看看一个本质的问题：测试到底是什么？

在第一篇中，我们提到测试是强制的文档，而我们分离了测试数据之后，你会发现一件很直观的事情：测试的输入和输出变成了一个有强约束性的文档，它用一种统一的可读可维护的方式规定了在我们程序接受了某种输入的情况会产生怎样的输出，对系统造成什么样的影响。

比如，Go的example test就是一种非常接近的尝试，它通过在测试的结尾使用comment来描述输出，从而使测试文档化。

1
2
3
4
func ExampleReverse() {
    fmt.Println(stringutil.Reverse("hello"))
    // Output: olleh
}

我们如果回头看看第二篇中我们抽取出的测试数据，就会发现这和Go的做法异曲同工，唯一不同的是由于没有语言的支持，这个数据我们只好将其放在其他的文件里面。

而这个有着强约束力的文档，不正是我们的知识库么？而它也是接下来我们要做的一切事情的根基。

3. 面向数据的测试

现在我们就可以换个角度看待我们的测试了，既然在大模块和服务级别的测试中，状态会产生组合爆炸，那为什么不利用我们的知识库，结合我们的业务特点，总结出一套数据的规则，然后再利用这个规则对我们的程序进行测试呢？规则本身是无状态的，所以我们可以对其进行复用，这样不就解决场景组合爆炸的问题了吗？所以现在是时候引入面向数据的测试了！

为了实现面向数据的测试，我们需要做两件事情：

  1. 我们需要可以拿到被测试程序在任意时间的数据切片；
  2. 在数据驱动开发之上，引入基于规则的测试器，帮助我们解决状态组合爆炸的问题；

3.1. 数据切片与面向数据编程（DOP）

首先，我们来看看数据切片。这里我们还是拿在中篇中我们提到过的服务测试做例子，我们从其中抽取出来的测试状态如下：

1
2
3
4
5
6
struct StatesToTest
{
    ServiceInternalState ServiceInternalState;
    ServiceDownstreamStates StatesToDownstreamServices;
    MyServiceTrackedStats TrackedStats;
};

其展开后的状态用json表示如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
  "ServiceInternalState": {
    "Foo": 1,
    "Bar": 2,
  },
  "ServiceDownstreamStates": {
    "MyDownstreamService1": {
        "Foo": 1,
    },
    "MyDownstreamService2": {
        "Bar": 2,
    },
  },
  "TrackedStats": {
    "RequestCount": 1,
    "Service1RequestSent": 1,
    "Service2RequestSent": 1,
  }
}

在这个例子中，我们的数据切片包含了在这个时间点下当前服务的内部状态和其发给下游服务的状态，当然对于不同的情况我们可以对其进行一些改变，如：

  1. 我们的服务内部数据如果存在分片，那么我们可以只返回一个分片的内容。比如，针对用户数据的业务处理，只要不存在跨用户的数据处理，我们可以返回某特定用户的数据，而不是该服务中所有用户的数据。
  2. 我们同样可以保存当前最近一次处理过的上游服务发过来的原始请求的状态或者其他内部状态来进行更丰富的测试。

这也和现在很多微服务的设计思路不谋而合，比如，DDIA第六章数据分区中提到的请求路由，和微服务设计这本书中提到的服务即状态机，都是在某种程度上通过设计数据分片来设计最终的服务。

所以，这里我们可以借用面向数据编程的思想，将数据看作程序的第一公民来对待，并且在设计服务的初期就对服务和状态发现进行支持，这样，我们就可以非常方便的获取到我们需要的数据切片了。

3.2. 基于规则的测试器

接下来，我们来看看第二点：基于规则的测试器。

3.2.1. 总结规则，编写测试器

现在，我们拿到了数据切片，而我们主要的测试内容有两个：

  1. 判断传递给下游服务中的Foo和Bar是否和当前服务内部中的Foo和Bar相等
  2. TrackedStats中记录的请求数要等和发给下游服务的请求数一致

所以我们可以针对其抽取出三条规则，写成代码如下，非常简单：

1
2
3
4
5
6
7
8
9
10
11
12
void MyDownstreamService1RequestShouldMatchServiceInternalState(_In_ const StatesToTest& state) {
    Assert::AreEqual(state.ServiceInternalState.Foo, state.StateToDownstreamService1.MyDownstreamService1.Foo);
} 

void MyDownstreamService2RequestShouldMatchServiceInternalState(_In_ const StatesToTest& state) {
    Assert::AreEqual(state.ServiceInternalState.Bar, state.StateToDownstreamService2.MyDownstreamService1.Bar);
} 

void TrackedStatsShouldBeValid(_In_ const StatesToTest& state) {
    Assert::AreEqual(state.TrackedStats.RequestCount, state.TrackedStats.Service1RequestSent);
    Assert::AreEqual(state.TrackedStats.RequestCount, state.TrackedStats.Service2RequestSent);
}

3.2.2. 测试测试器

好了，现在虽然我们已经有了一些测试器，但是我们怎么知道他们工作的是否正常呢？别忘了我们已经积累好了一个庞大的知识库，所以只要将其代入之前的测试中就可以啦，代码看起来就是这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
TEST_METHOD(MyService_WhenReceivingValidRequest_DownstreamServicesShouldBeProgrammed)
{
    RunMyServiceStateHandlingTest(L"MyServiceTests\\ValidRequest-Input.json");
}

void RunMyServiceStateHandlingTest(_In_ const std::wstring& inputFilePath, _In_ const std::wstring& expectedStatesAfterUpdateFilePath)
{
    std::shared_ptr<MyService> service = CreateMyService();

    MyServiceRequest mockRequest;
    JsonConverter::FromJsonFile(inputFilePath, mockRequest);
    service->SendRequestSync(mockRequest);

    StatesToTest actualStatesAfterUpdate;
    actionStatesAfterUpdate.ServiceInternalState = service->GetInternalState();
    actionStatesAfterUpdate.StatesToDownstreamServices = service->GetStatesToDownStreamServices();
    actualStatesAfterUpdate.TrackedStats = service->GetStatsTracker()->GetTrackedStats();

    MyDownstreamService1RequestShouldMatchServiceInternalState(actualStatesAfterUpdate);
    MyDownstreamService2RequestShouldMatchServiceInternalState(actualStatesAfterUpdate);
    TrackedStatsShouldBeValid(actualStatesAfterUpdate);
}

这里也许你会好奇，这个和最开始我们的测试逐个数据写assert有什么区别呢？不也是写一堆assert么？这里其实有几个本质的区别：

  1. 至此，我们被测试的代码已经经过了一大轮的重构，并具备了获取数据切片的能力，而我们的所有测试都是基于一个完整的数据切片来完成的。
  2. 我们的测试是基于规则的，它只会去测试数据与数据之间的关系，而绝对不会去测试某个数据等于某个绝对值，比如0或者1，这样就避免的状态组合爆炸的问题。
  3. 我们需要测试的场景是多种多样的，但是规则是无状态的，而且大量的规则都是可以复用的，这样可以减少我们的测试代码量。

也许这些听着依然差别不大，所以下一节我们就来看看这些基于规则的测试器都能帮我们做些什么吧！

3.2.3. 程序逻辑本身也是规则测试器

另外，当我们将代码重构到了这一步，各种测试都能被通过测试数据稳定的复现的时候，其实我们会发现，我们需要测试的程序本身已经是一个很好的测试器了，所以虽然听起来有点荒谬，但是我们确实可以通过简单的对比新老版本代码的行为（数据切片）来达到测试的目的。

不过我们觉得荒谬也是有原因的，其主要问题就在于，这个说到底还是在用自己证明自己：

  1. 由于测试用的基线数据都是自动生成的，将程序本身作为规则测试器会比较容易因为粗心或者代码审查不严格而引入新的问题，所以这里更好的做法还是总结一套真正的规则进行测试。
  2. 对于预料之外，程序本身没有处理到的情况，我们的测试也覆盖不到。

所以最好还是自己提炼出真正的规则来，用以测试吧！

3.2.4. 使用测试器

3.2.4.1. 线下测试即线上测试

也许大家都经历过线上系统中一些老旧过时的状态导致各种线上事故频发的情况，特别是新服务升级，一些以前没有清理干净的状态就很容易导致问题，如果有一种方法能对所有的线上服务的状态进行测试就好了，而这正是基于规则的测试器大显身手的地方之一！

由于所有的测试器都是无状态的，仅仅和其输入有关，而且测试的是输入和输出的关联性，所以我们不仅仅可以用这些规则来做本地的测试，还可以对我们线上的服务进行不间断的在线测试，用以发现预料之外的情况发生。其流程也非常简单：

  1. 服务发现：找到我们系统中的所有服务并对每一个服务依次进行步骤2：
  2. 数据发现：找到我们系统中的所有数据，比如，如果是用户管理的服务，那就是每个用户的数据，如果是某个特定业务的服务，那就获取其对应的分片数据，然后获取其在特定时刻相关的数据切片，并对每一个切片进行步骤3：
  3. 测试发现：找到这个数据切片相关的所有测试，比如，如果是用户数据，那么我们可能可以找到这些测试：UserPasswordShouldBeEncrypted, UserEmailShouldBeValid, UserAgeShouldBeValid，等等。
  4. 测试执行：执行每个被发现的测试，并对其结果进行统计和上报。上报的内容至少需要包括，数据的id，数据的位置（原服务的信息），测试的名称，及其结果和具体的失败原因。如果可能，最好还能包括数据的具体内容，毕竟有些错误可能是短时的，过几分钟就消失了，而有了数据内容我们就能很容易的在本地进行重现。

为了执行线上测试，我们如果使用actor model控制每个数据分片，可以让每个actor自己在timer中执行。如果担心数据量过大导致占用服务资源太多，我们也写一个独立的测试服务，对所有的测试进行执行和调度，避免资源浪费。

一旦拥有了这个测试服务，我们做任何新的功能，都可以先将前置条件添加到相关的测试器中进行发布，确认了全网都没有任何问题之后再进行最终的服务发布，这样就可以大大降低服务发布的风险！

3.2.4.2. 抽象测试器

线上测试听上去非常的棒，但是中间我们会遇到一个小问题，那就是测试发现。如果和之前的代码一样都是一个一个的函数，可能管理起来会比较复杂。所以我们能可以对其进行一个小小的抽象，提取一个公共的基类，并且增加一个工厂方法以支持测试发现，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
class Validator {
public:
    virtual ~Validator() {}
    virtual void Validate(std::vector<ValidatorError>& errors) = 0;
}

class ValidatorFactory {
public:
    virtual ~ValidatorFactory() {}
    virtual ServiceType GetServiceType() const = 0;
    virtual ServiceDataType GetServiceDataType() const = 0;
    virtual Validator CreateValidator(const ServiceStateSnapshot& state) = 0;
}

当然，如果语言支持更高级的特性，我们可以将其进一步简化，如：python中的decorator，或者c#或java中的attribute，抑或是rust中的宏。但是基本思想是类似的。

3.2.4.3. 随机测试（Fuzz Test）和形式化证明

我们上面提到过，数据驱动测试对随机测试并不是很友好，因为我们没有任何先验数据进行参照，但是使用了规则测试器之后，我们便可以非常轻松的对随机的输入进行测试了。

另一方面，由于支持对任意的输入进行测试，我们还获得了对代码进行形式化证明的能力，并让形式化证明的系统为我们生成错误的测试用例，帮助我们查找系统中的问题。

data-oriented-test-fuzz-fv.png

3.3. 面向数据的测试总结

由于这是这个系列的最后一篇，所以我们来混着前面两篇的内容一起总结面向数据测试吧：

  1. 首先，写任何代码，不管大小，我们都要设计好接口和代码分界，然后针对代码分界进行测试，这样既保证了测试的完备，也能给代码重构留下一定的空间；
  2. 然后，对于小的模块和函数，我们可以应用数据驱动测试，将输入和输出分离出来成测试数据，保存成可读的文件格式，并将程序中会导致不稳定的代码进行分离和固定，做到稳定的测试和问题复现；
  3. 测试数据需要和代码一起提交以反映代码对系统带来的所有变化，而在程序逻辑变化之后，如果需要更新测试数据，我们可以利用新的程序重新生成测试数据，并将其作为新的基线；
  4. 测试时，我们不应该将代码覆盖率作为目标，而应该从数据和业务的角度考虑，将场景覆盖率作为最终的目标；
  5. 对于大模块和服务的设计，如果是管理数据的服务，我们应该从数据分片的角度出发对服务进行设计，将数据本身作为头等公民之一，并对服务和数据发现做好支持，并依次为依托进行测试；
  6. 在测试大模块和服务时，我们可以通过提炼规则测试器来避免数据驱动测试中状态组合爆炸的问题；
  7. 最后，我们还可以利用面向数据测试做到对随机测试和形式化证明的支持；

这里，我们也再来一张图，对面向数据测试进行一个归纳：

data-oriented-testing.png

4. 工欲善其事，必先利其器

最后，好的测试的辅助工具能让我们事半功倍。对于任何一个稍稍成熟一点的项目来说，好的工具都是必不可少的。

4.1. 日志（Log）与日志查看器（Log Viewer）

调试测试时，除了调试器以外，日志便是我们最好的帮手，特别是当调试多线程问题的时候，使用调试器调试经常会变得非常的困难。但是日志也有它自己的问题，就是量太大，很难抓住重点，所以我们需要一个好的日志查看器来帮助我们调试。

一个好的日志查看器，除了能进行日志查询和分级以外，最好还需要具备如下功能：

#1: 支持对任意字段的过滤，并至少能支持"or"和"and"语义

  • ProcMon便是一个很好的例子，它的日志中所有的字段都支持过滤，并且条件多种多样。
    ProcMon
  • 更好的是支持一种查询语言或者其子集（甚至只有where语句），比如，SQL和Kusto的KQL。

关于procmon，Mark Russinovich有一个非常有意思的talk，大家有兴趣可以去围观：Building 25+ years of SysInternals: Exploring ZoomIt | BRK200H。

#2: 支持日志高亮

#3: 支持场景（Scenario）分析

这个是为了帮助我们快速定位只和我们有关的日志。

  • 每个场景都有一个开头事件和一个结尾事件，我们可以通过一定的方法将其关联起来，比如线程ID，模块名，日志中解析出来的元数据等等。
  • 场景的支持能大大提高我们分析日志的速度，因为我们只需要查看和我们场景相关的日志即可。

支持场景分析的日志有很多，比如：

  • OpenTelemetry中的span，通过它我们可以将操作记录成树的形式，然后在其他的工具中方便的查看，从而帮助我们了解和分析系统中的热点，比如jaeger。
  • Windows Performance Analyzer（WPA）中的Region of Interest也是一个很好的例子。

当然让日志查看器变好用的方法还有很多，比如对服务端或离线日志的支持（下载相关日志本地二次查询以加快速度），对产品本身的理解和支持（比如显示服务部署位置，高亮关键场景，显示场景树用来关联相关场景和日志等等）。这里就不一一列举了，大家可以根据自己产品的需要来实现或选择合适的日志查看器。

4.2. 测试历史数据

我们都肯定遇到过一些不稳定的测试，不知道他们什么时候就会出错，很难重现。其中可能是上面提到的不稳定因素造成的，也有可能是不稳定的测试环境造成的。其中性能测试就是一个重灾区。性能测试的结果会受很多因素的影响，哪怕是在同一台机器上，比如系统繁忙程度，热启动冷启动，随机的GC等等等等。我们很多时候都不知道某一次速度慢是不是真正的问题。所以为了避免这些因素的影响，我们除了要运行多次测试看均值以外，收集每次测试的历史数据也是非常有帮助的。

这是Azure Pipeline中的对测试历史数据的支持：Test trends with historical data。我们不仅能看见每个测试是否出错，还能看这些测试每次花了多久，从趋势上判断是不是性能变差了。

4.3. 快捷命令

最后，我们还可以在代码库中加入各种快捷命令，帮助我们更快的进行调试。以下列举一些我们现在项目中的常用命令作为栗子：

  • ut-log: 使用日志查看器打开最近一次执行的测试的日志。
  • ut-d: 使用windbg加载指定的测试，加载多进程调试设置和异常捕获设置，并运行测试。这样是为了方便调试在Visual Studio很难调试的错误，比如，栈和堆的错误等等。
  • slv <log-path>: 使用日志查看器打开指定的日志

5. 总结

到此，我们最后来总结一下吧：

  1. 首先，我们讨论了传统的数据驱动开发和它的局限性；
  2. 接下来，我们重新审视了测试的意义，并且将我们分离出来的测试数据看作我们的知识库来辅助我们的开发；
  3. 然后，我们讨论了面向数据开发的方法，用以克服传统数据驱动开发的局限性；
  4. 最后，我们还简单的讨论了一下用于支持测试的工具，如：日志和一个好的日志查看器的标准，如何收集历史数据并帮助我们观察测试走向和应对不稳定的测试；如何通过快捷指令来帮助我们简化日常开发；

好的，至此这个系列终于完结啦，如果你看到了这里的话，真的非常感谢！也希望这个系列能对大家平时的开发工作能起到一些帮助。

同系列文章：
原创文章，转载请标明出处：Soul Orbit
本文链接地址：测试，你写代码时最好的朋友（下篇）]]> <p>我们终于来到了这个系列的最后一篇，在<a href="/posts/2021-01-31-make-tests-your-friends-continue/">上一篇中，我们讨论了如何写出好的测试，如何利用数据驱动测试来降低测试的维护成本，提高程序和测试的可观察性，并且提高错误调试的速度</a>。希望到了现在，你会开始觉得数据驱动测试相当方便，并跃跃欲试的想在自己的项目里面进行实践。</p> <p>不过，如果我们仅仅到此为止，那就真的太浪费了。我们还只刚刚解锁了它的一半威力而已！我们这一篇就来讨论以下它的进阶版本，我称其为面向数据的测试，并且利用它做到<strong>线下测试即线上测试</strong>，从而实现测试的大统一！</p> <h2 id="数据驱动测试（DDT）">1. 数据驱动测试（DDT）</h2> <p>首先，我们先来快速回顾一下<a href="https://en.wikipedia.org/wiki/Data-driven_testing">数据驱动测试</a>吧！</p> <p>数据驱动测试，顾名思义，其特点就是将被测试程序的输入通过数据的方式进行存储，并在测试时依次循环执行，最后将被测试程序的输出与预先设置好的期望结果进行对比，从而达到测试的目的，流程大致如下：</p> <!-- %%{init: {'theme':'forest', 'themeVariables': {'fontFamily': 'comic sans ms', 'edgeLabelBackground':'#FFFFFF'}}}%% flowchart LR DataFile -- Test data --\> TestDriver TestDriver -- Call with test input --\> Application Application -- Actual output --\> Validator DataFile -- Expected Output --\> Validator --> <p><img src="http://r12f-cdn.azureedge.net/r12f-assets/post_assets/2022-12-26-make-tests-your-friends-final/data-driven-testing.png" alt="data-driven-testing.png"></p> 《孙子兵法》读书笔记 http://r12f.com/posts/reading-time-the-art-of-war/ 2021-04-21T00:07:07.000Z 2021-04-21T00:07:07.000Z 我也不知道是为什么，就是突然很想看这本书，但是文言文真的好难啃啊，于是这几周就一直在读这一本书……

《孙子兵法》这本书很有意思，读完之后发现，其中最著名的几句话，也是对其误读最深的几句话，比如“兵者，诡道也”，比如“置之死地而后生”。本来是打算把这本书当作一本故事书读着玩的，结果哪里知道，这本书讲的全然不是什么诡道，特别的平实，满满的正能量，他教我们怎样做事，怎么管理企业和团队，怎么样评估风险控制预算，等等等等。真的没想到几千年前讲的东西，哪怕是到了现在都非常的实用。也许不管时代怎么变，科技怎么发展，人，终究还是人吧……

另外一个有意思的地方就是，其实《孙子兵法》有很多内容甚至核心思想也都不是其原创，而是更早的人发明了之后流传下来的。这个人便是黄帝身边的宰相，叫做风后。没错，就是《一人之下》里风后奇门的风后。除了因为风后是最早发明这些兵法的人，还因为风后留下来到现在著作《八阵图》和《握奇经》里面详细描述了如何运用八卦进行阵法布置，所以就有了《一人之下》里面的风后奇门的演绎了。

好了，让我们说回正题——《孙子兵法》吧。

1. 核心思想：先胜后战，以强胜弱

“胜兵先胜而后求战，败兵先战而后求胜。”——《形篇第四》

打胜仗的军队，总是先获得胜利地位，获得取胜条件之后，才投入战斗。而打败仗的军队，总是冲上去就打，企图在战斗中捕捉机会侥幸获胜。先胜后战，在取得压倒性优势的前提下作战，绝不心存侥幸，这就是《孙子兵法》的核心思想了。

作为一个兵法小白，《孙子兵法》是我读的第一本兵法，其核心思想是我觉得最奇妙的地方。全书都没有提到什么精妙的战术告诉我们如何以少胜多，以弱胜强，而是想尽办法求得“先胜”。说白了就是打得赢才打，打不赢就狗着，以强胜弱，虐菜什么的才是王道（这也太朴实了……）。因为这个原因，整本书讨论的重点便成为了：如何才能“先胜”！

于是，兵法十三篇，由《计篇》开始，以《用间篇》结束，“先胜”这个概念贯穿全书。

2. 战略运筹：关注基本面

2.1. 风险评估：五事七计

“夫未战而庙算胜者，得算多也；未战而庙算不胜者，得算少也。多算胜，少算不胜，而况于无算乎！吾以此观之，胜负见矣。”——《计篇第一》

无论做什么，最重要的事情，也是第一件要做的事情，就是要进行庙算。所谓庙，便是庙堂，算，就是评估。也就是说，事情还没开始准备做之前就要开始先做评估，在朝堂之上就要开始算，而不是等到了战场之上才开始。通过庙算，我们便能在做事情之前知道自己胜算几何。这也是孙子兵法开篇《计篇》讲的主要内容。这里的“计”不是三十六计里的计，而是计算，评估。

而庙算的方法便是五事七计，它是对敌我双方进行政治，实力等基本面的比较，而不牵涉具体的战术和行动。这是孙子兵法里技术含量最高的部分，也是整本书花了大篇章详细介绍的部分，至于“兵者，诡道也”的十二诡道，说白了就那么几招，你会，别人也会，没有什么太多的作用。只有基本面足够的硬，才是取得“先胜”和“全胜”的关键。

“故经之以五事，校之以计而索其情：一曰道，二曰天，三曰地，四曰将，五曰法。…… 凡此五者，将莫不闻，知之者胜，不知者不胜。故校之以计而索其情，曰：主孰有道？将孰有能？天地孰得？法令孰行？兵众孰强？士卒孰练？赏罚孰明？吾以此知胜负矣。”——《计篇第一》

我们首先来看五事。所谓五事，按先后顺序，道，天，地，将，法：

  1. 道：师出是否有名，上下是否同心；打个比方，我说我要做项目A，可是项目A完全没有任何人老板支持，也没有资源投入，这就是师出无名，没有道；
  2. 天：就是天时，气候，时令，也就是有没有在正确的时间做正确的事情；比如，开发到了最后稳定版本的阶段了，我们却在不停的加新功能，或者正式开发已经开始一阵了，我们却在不停的改设计，这就是违反天时；
  3. 地：就是地形，地势，在什么地方就做什么事情；比如，这个我说我要领导一个项目，可是这个项目完全不归我负责，而是已经安排好了一个组在做，而我偏偏强行去做，这就是没有地利；
  4. 将：就是领导和做事的人了，他们做事怎么样，靠谱吗？
  5. 法：就是法令，制度；制度是否正常执行，赏罚是否到位分明？一个人如果做的很好，那有没有给到他应得的奖励？一个人如果做的很差，那有没有在最后的绩效中反映出来？而不是大家一起吃大锅饭。

了解了五事，我们便可以开始七计，进行对比分析了。这个就很好理解了，也就是将五事的情况进行一一对比。这里就不再细说了。

“故知胜有五：知可以战与不可以战者胜；识众寡之用者胜；上下同欲者胜；以虞待不虞者胜；将能而君不御者胜。此五者，知胜之道也。”——《谋攻第三》

进行了五事七计，我们便可以在还没开始作战前就做到“知胜”。知胜五道和五事七计类似，比较有意思的一条是“将能而君不御者胜”，这一条很容易被误读，“君不御”不是说君“不能御”而是“不去御”。它不是说要我们一天到晚违抗老板们的命令，而是说做事的人很有能力，能自己做出正确的决定，而老板们也能放权，让手下的人大胆的干。读过《赋能：打造应对不确定性的敏捷团队》的朋友就知道，这样的团队是一个非常高效的赋能团队，有着超强的战斗力。

2.2. 成本管理：兵闻拙速，一战而定

“兵者，国之大事，死生之地，存亡之道，不可不察也。”——《计篇第一》

为什么整部兵法要以风险评估作为开篇，并且上来第一句话就是“死生之地，存亡之道”这么严肃呢？这便是第二篇《作战篇》讲的内容了 —— 成本。

“凡用兵之法，驰车千驷，革车千乘，带甲十万，千里馈粮。则内外之费，宾客之用，胶漆之材，车甲之奉，日费千金，然后十万之师举矣。”——《作战第二》

打仗是一件非常耗费资源的事情，所以才有“日费千金，然后十万之师举矣”的说法。公司也是一样，越是小的公司，越是初创公司，人员就越是精干，因为根本就没有资源来养闲人，每个人的作用都必须要发挥到最大才行。《重来》里面就提到过，37signals不到万不得已是绝对不会招人的，这都是因为经营公司日费千金。很多公司现金流稍稍一断，不几天就得宣布破产。著名的汉武大帝，便因为战争，挥霍无度，导致国库空虚，百姓苦不堪言，最后在其死前两年颁布了中国历史上第一个帝王的罪己书：《轮台诏》。所以，成本逼得我们不得不严肃的对待我们做事情的态度。

“故兵闻拙速，未睹巧之久也。夫兵久而国利者，未之有也。故不尽知用兵之害者，则不能尽知用兵之利也。…故兵贵胜，不贵久。故知兵之将，民之司命。国家安危之主也。”——《作战第二》

那到底应该如何控制成本呢？孙子给了一个非常直接的答案——“拙速”。扎扎实实的做事，踏踏实实积累，不要老想着用各种巧妙的方法偷懒。功夫都在平时，看上去最慢最笨的办法，也许反而是最快的办法。等到积累够了，实力强了，真的开始做事情了，便可以一战而定，不留后患！

举个工作中的实际栗子：某个项目，为了快速出成果，各种取巧，这里hack一点，那里hack一点，测试也不写，东西都还不确定能不能用，就开始催着上线，然后项目完工，该升职的升职，该跑路的跑路。而当用户开始真正使用时，这个服务就开始一天到晚出错，线上事故不断。而为了修正线上事故，小组里面开始涌现出各种救火英雄，大家都很感谢他们，纷纷为他们升值加薪。这个项目看上去一片和谐，大家干的热火朝天，然后突然，你发现项目成员开始纷纷离职，你满头不解，为什么？

当你凑近一点仔细一看，才发现，因为之前的hack把整个流程搞得乱七八糟，各种所谓的“短期方案”因为种种原因（比如，更多的依赖）都变的无法更改；你以为改了一个bug，结果导致了更多的事故，因为另一个bug和他正好负负抵消；各种遗留的待办事项导致各种问题，而随着时间的推移，有些待办事项反而变成了软件特性（feature）；而破窗一旦形成，后面就会越来越破。项目组里面越是想好好做事的成员，越是被这种风格折磨的苦不堪言，纷纷离职，劣币驱逐良币；项目看着很热闹，其实越来越糟。等反应过来的时候，才发现只能另外再起一个项目去替换老项目了，结果因为文化没变，一轮新的循环又开始了，而新老项目交替的过程中，兼容性和版本切换等等问题，让事情变得更加糟糕……

这便是一个经典的取巧的例子，不知道大家有没有经历过类似这样的项目，如果没有，我替你感到高兴。项目推翻重来意味着前面花的资源白花了，劳民伤财。我个人经历了一些，而为了挡住这些“高明”的解决方案，我不知道要顶多大的压力，作为一名普通一线小开发，为了这些事情和各个大老板吵架，其中一个最后甚至吵到了CVP的级别。

所以，打胜仗很重要，不要一直“打胜仗”有时候更重要，因为这代表着前面的债，还没有还完。“踏踏实实做事，每天进步一点“，这句话说起来简单，做起来却相当的难。

2.3. 善战的表现：无勇功

“故善战者之胜也，无智名，无勇功。” —— 《形篇第四》

如果我们应用孙子的方法，凡事进行五事七计，先胜后战，平时注意积累，尝试取得压倒性优势后再开始做事，一战而定，而不是心存侥幸，做了再说，最后问题连篇，最后得到的结果便是事情进行的顺顺利利，没有什么波澜曲折，然后不知不觉事情就做完了，然后开始下一个事情。你看不到他一天到晚救火，处处充当英雄，仿佛给他的事情永远都那么简单。这便是孙子说的善战之人的表现：“无智名，无勇功”。

《鶡冠子·卷下·世贤第十六》中有一个很著名的关于扁鹊的故事：说扁鹊一家三兄弟都是医生，一天魏文王问扁鹊，说：“你们一家谁医术最好？”扁鹊说：“大哥最好，二哥次之，我最差。”魏文王不解：“那么为什么你最出名呢？”，于是扁鹊说：“我长兄治病，是治病于病情发作之前。由于一般人不知道他是在事先就铲除了病因，所以他的名气无法传出去，只有我们家的人才知道。我中兄治病，是治病于病情初起之时。一般人以为他只能治轻微的小病，所以他的名气只及于本乡里。而我扁鹊治病，是治病于病情严重之时。一般人都看到我在经脉上穿针管来放血、在皮肤上敷药等大手术，所以以为我的医术高明，名气因此响遍全国。“

对比上面我们提到的例子，如果项目一开始就进行合理的设计，让整个流程变干净，并且与各个合作方进行沟通，达成一致，开发时做好测试，处理好边界情况，固定软件行为，最后也许前期花的时间多一点，但是之后便会顺顺利利，服务按时上线，后面也没有什么问题需要处理。大家觉得事情都很简单，不知不觉就完成了，于是开始做其他的项目。整个过程，没有什么让人拍案叫绝的天才的设计，没有什么英雄出现，也不需要什么英雄出现，大家只要各司其职便可以顺利完成项目。

这便是“无智名，无勇功”。

3. 团队建设

看完了基本面，我们再来看一看团队的建设。

3.1. 领导的自我修养：五德，五危，六败

首先，我们来看看孙子对领导们的要求和评估标准。这里最关键的便是五德，五危和六败。

“将者，智、信、仁、勇、严也。”——《计篇第一》

孙子列出了五个领导应该具备的品质，被称为五德，我们来一一看一下：

  1. 智：聪明。能在事情发生前就预见到，能制定正确的应对方案，并且能根据情况随机应变。
  2. 信：赏罚分明，说话算数。你团队里的人觉得他们的付出得到了对应的回报吗？不过可惜的是，现实中你不一定有这个的决定权，这怎么办呢？这就要靠一件事情了，就是做领导的心里面得想着团队里的人的利益，而且你得让他们知道你有想着。也许现在当下没肉吃，但是只要有我的一口便少不了你的一口。所以，信，更多的是一种人格魅力，能让人踏实的追随你。
  3. 仁：爱人悯物。善待团队里的人，爱惜手中的资源。
  4. 勇：当机立断，勇往直前。策略一旦定好了，便敢于按照策略来，而不是犹豫不决。
  5. 严：立威信。这就是所谓的气场了，你必须要手下的人知道，惩罚的措施会算数。古时候，打仗出师前，都会杀几个没什么用但是和皇上很亲的宠丞来祭旗，为什么呢？这就是用来立威的，说的就是，别把我的话不当话。

这五德缺一不可，而且不能过，所谓“专任智则贼，遍施仁则懦，固守信则愚，恃勇力则暴，令过严则残。五者兼备，各适其用，方可为将帅”。

“故战道必胜，主曰无战，必战可也；战道不胜，主曰必战，无战可也。故进不求名，退不避罪，唯人是保，而利合于主，国之宝也。” ——《地形第十》

古人说话很严谨，这里五德是有排序的。其中，“智”最为重要排名第一，它是做领导最重要的能力，而“勇”才排第四。所谓“将熊熊一窝”，做为老板如果有勇无谋，不能制定计划方案，那整个团队都会乱成一团。但是如果一个将领非常有能力，他便可以根据实际情况随机应变。如果有必胜把握的，哪怕老板说不需要，也能一并完成。但对于不可能搞定的事情，哪怕老板说一定要，也可以选择不做。不过违抗命令最后是要担责任的，所以必须要有理有据，毕竟我们最后还是要给老板交差的，交不了差是会出事的。

所以，什么是判断标准呢？这便是领导的职业道德了：“进不求名，退不避罪，唯人是保，而利合于主”。进退都不是为了自己，而是以真正的大局为准，这才是真正的忠臣。

这里孙子还提到了“退不避罪”，那么领导有那些“罪”呢？

”将有五危：必死，可杀也；必生，可虏也；忿速，可侮也；廉洁，可辱也；爱民，可烦也。凡此五者，将之过也，用兵之灾也。覆军杀将，必以五危，不可不察也。“——《九变第八》

首先，孙子说领导者有五种性格缺陷特别危险。五危之中有些与五德对应，要么是因为不够，要么是因为过了。

  1. 必死：不怕死，一味死拼。这是勇过了。
  2. 必生：贪生怕死，没有决心。这是勇不够。
  3. 忿速：愤怒急躁，经不起刺激。容易被激将，做出冲动的事情。
  4. 廉洁：爱惜名誉，受不得污辱。只要被人往他身上泼点脏水，便会被激将。为了维护自己的名誉，而不顾巨大的风险做一些事情。
  5. 爱民：过于善待别人。这是仁过了。要么会为掩护他们而烦劳（帮他们擦屁股），要么别人可以以他们为要挟或炮灰，让他于心不忍而替别人做事情。

“不必死，不必生，不忿速，不廉洁，不爱民”，说的直白一点，就是人至贱，则无敌。

“故兵有走者，有弛者，有陷者，有崩者，有乱者，有北者。凡此六者，非天之灾，将之过也。”——《地形第十》

除了五危以外，团队还有“走、驰、陷、崩、乱、北”六种必败的情况。而这六种情况，都不是天灾，而是将领的过错。

  • 走：“夫势均，以一击十，曰走”。明明团队不缺人手，偏偏把所有的活都让一两个人做，必然败走。
  • 弛：“卒强吏弱，曰弛”。手下做事的人很强，但是领导能力太弱，指挥不动，纪律松弛，叫做“驰”。所以领导不仅要有才能（智），还要有威望（严），要能驾驭的了手下的人。只有才能，没有威望，就只能当副手。
  • 陷：“吏强卒弱，曰陷“。领导其中一个责任就是团队建设，管理并训练手下的人，不是靠自己单打独斗。如果不能把团队训练好，到了真正做事的时候，就只会把自己陷进去了。
  • 崩：“大吏怒而不服，遇敌怼而自战，将不知其能，曰崩”。小将对大将不服、怨恨，于是自己擅自做出各种行动，而大将无法控制，这样的团队其实算是已经崩溃了，曰崩。
  • 乱：“将弱不严，教道不明，吏卒无常，陈兵纵横，曰乱“。将领能力不够，没有威望，教导下属没有方法，团队中没几个老员工，所有职位都是新人，谁也干不长，而且命令无法正常执行，手下的人做事横冲直撞，四处乱来。这就是乱了。
  • 北：“将不能料敌，以少合众，以弱击强，兵无选锋，曰北”。领导没有能力预判形势，用少数去打多数，用弱兵去打强敌，用兵也不懂得选择精锐，这就叫“北”。这里选择精锐十分重要，我们后面再作战指挥里面再来细说。

了解了五德，五危和六败，现在我们可以对比来看了。你现在的老板做的怎么样呢？如果你自己就是领导者，你做的怎么样呢？

3.2. 团队成员：兵非益多，谨养勿劳

“兵非益多也，惟无武进，足以并力，料敌，取人而已。”——《行军第九》

兵力不在于越多越好，而在于：

  • “无武进”：不要贸然行动。
  • “足以并力”：补足人手，集中兵力，也可以理解成上下同欲，齐心协力。
  • “料敌”：判明敌情。
  • “取人”：选拔人才并取得团队成员的信任和支持。

这里的关键，在于“取人”，有了人才，其他的都会有的。所以如何取人呢？曹操的注解是这样的：“厮养足也”。不要依赖外援，不要依赖空降，不要依赖联盟，每个人都有各自的优先级，靠得了一时，靠不了一世。所以，最可靠的就是自己亲手带出来的人，从内部选拔人才。这样又能团结团队，又能驾驭指挥，一举两得，大家都有肉吃，多好！

所以，减少无用社交，在自己的身上投资，强大自己的团队，比什么都靠谱。

”谨养而勿劳，并气积力。“——《九地第十一》

接着就是“养兵”，所谓“养兵千日，用兵一时”，这句话其实有好几重意思：

  1. 首先是养兵千日。平时正常的时候，要保持团队的精力。平时不是紧急的时刻，保持普通的开发节奏就好，这样等到紧急情况来临，才有额外的精力去处理。如果平时每天就996，再来个线上事故，是个人都崩溃了。
  2. 然后，养兵不是放着不用，而是要保持正常的训练，保持高昂的士气，随时准备着，随时都能出击，这才是养。要是平时懒懒散散，等到要用的时候发现什么都不会，这就不是养兵了。
  3. 最后便是用兵一时，这关键就是一时。每个人精力就那么多，用完了就没了，所以用兵一时，所以第一、精力要放在关键的地方，第二、做事情速度要快，兵贵速，不贵久。

4. 作战指挥

好的，现在我们知道了什么是好的战略，什么是好的领导，那么接下来就来看看最后在做事情的战术层面上我们应该怎么样做吧。

4.1. 如何取胜：知己待敌，先为不可胜

“故曰：知己知彼者，百战不殆。不知彼而知己，一胜一负。不知彼不知己，每战必殆。”——《谋攻第三》

“知己知彼”，应该是孙子兵法里最著名的一句话了，但是其实这简单的四个字里面文章很多。

“昔之善战者，先为不可胜，以待敌之可胜。不可胜在己，可胜在敌。故善战者，能为不可胜，不能使敌之必可胜。故曰：胜可知，而不可为。”—— 《形篇第四》

首先，知己知彼，知己在前，因为知己更为重要。这里真的不是过分解读，因为马上在之后的《形篇》中，孙子就提出了更详细的解释：“不可胜在己，可胜在敌”。彼，我们不一定可知，但是自己的实力，我们却肯定可以自己控制。所以让自己强大起来，才是真正的取胜的关键。诡道计谋，你会，别人也会，那些花架子也许能帮你一时，但不可能帮你一世。所以，知己知彼，最重要的还是知己。承认自己的弱小和不完美，然后改进它，提高它，日拱一卒，慢慢积累，让自己不可战胜，等到对方露出机会，我们便可一战而定。故曰：胜可知，而不可为。

“胜可知，而不可为”，除了告诉我们要知己以外，还有另外一层意思，就是要耐得住寂寞，等待时机。时机未到，不要乱动，其徐如林，不动如山。

然后，就是彼，也就是我们的对手，到底是谁？或者说我们到底要了解谁？工作中，我发现很多人经常搞错我们的对手。他不是我们的竞争对手，而是我们要解决的问题。比如你在开公司做产品，那么你的对手，其实应该是你的用户，或者说是你的用户的需求。知道竞争对手在干什么大部分时候其实都没有什么太大的用处，而了解你的用户到底想做什么，想要什么，如何才能更好的解决他们的实际问题才是王道，这才是你真正的核心竞争力。

4.2. 作战思想：全胜为上，上兵伐谋

“夫用兵之法，全国为上，破国次之；全军为上，破军次之；全旅为上，破旅次之；全卒为上，破卒次之；全伍为上，破伍次之。是故百战百胜，非善之善者也；不战而屈人之兵，善之善者也。故上兵伐谋，其次伐交，其次伐兵，其下攻城。”——《作战第二》

接下来，我们来看一下孙子作战的指导思想。

在庙算完成，我们“先胜”了之后，便可以开始真正的行动了。行动时，孙子的作战思想便是追求“全胜”。这里的“全胜”不仅仅是保全自己，还要保全对方。举一个最简单的栗子，你好不容易攻下了一座城池，然后发现这座城池已经被你打成了筛子，城也没有了，人也没有了，你说你花那么大力气把他打下来又有什么用？所以就有了接下来的“上兵伐谋，其次伐交，其次伐兵，其下攻城”。

所谓“上兵伐谋，有下用师。弃本逐末，圣人不为。”，这个思想其实并不是孙子提出的，它来源于《握奇经》，出现的非常的早。那什么叫做“伐谋”呢？

“伐谋”的意思是伐掉对手的谋，让对方直接放弃攻击的想法。这是在需求层面上进行作战，一旦成功，这就是降维打击。在这一步里，了解我们的对手到底是谁非常的重要。如果你还不是很清楚你的对手是谁，请移步上一节。

对于伐谋，兵法里面举的例子都过于直接，比如敌方派使臣过来试探，我方故意表现一些东西给敌方看，最后让敌方放弃进攻的想法。这些例子并不能非常好的帮助我们理解这个词，所以这里举一个更现实一点的栗子：假设某天，我们一个用户找到我们，说他们有一个看上去很特殊的需求，需要我们来支持，于是我们团队开始处理这件事情：

  1. 伐谋：我们和对方联系了之后，发现对方其实是想要实现一个特殊的需求，而这个需求来源于他们对他们正在使用的框架的错误理解，于是我们展示了正确的使用方法，让这个需求不复存在，于是用户进行了相应的修改，不仅工作量变少了，服务也变得更加健壮和合理。
  2. 伐交：我们和对方联系了之后，觉得对方可以使用另外一种实现方案来实现他们想要的需求，虽然可能在一些情况下效果没有那么的理想，但是对方觉得没有什么太多问题，可以接受，于是对方同意使用这种方法，并做出了对应的修改。
  3. 伐兵：我们和对方联系了之后，发现对方想要的需求实在过于复杂，于是在一番交涉之后，我们这边提出了一个可行的方案，可以满足对方的所有需求，对方同意了，于是我们开始开发，一个月之后开发完成，服务上线，对方虽然等的有点烦，但是还算能接受，所以得过且过了。
  4. 攻城：我们和对方联系了之后，发现对方想要的需求超级复杂，但是不得已，我们还是只能实现，于是经过了长达六个月的攻坚，终于将需求完成，服务上线。可是回头一看，对方因为实在无法承受六个月的损失，早已经等的不耐烦了，而早在两个月前已经转投了别的服务。

这就是为什么“上兵伐谋”了。

4.3. 成功是概率：应敌为势，避实击虚

“故善战者，致人而不致于人。”——《虚实第六》

作战之前还有一些事情需要了解：

  1. 胜败不仅仅是实力的问题，它也是一个概率的问题。
  2. 胜败导致的结果是不对等的，成功了，你可能获得一些奖励，但是如果失败了，可能后果很严重，比如永远的失去一些大客户，等等。

因为成功是概率，所以哪怕我们的决策再好，也会有失败或者结果不是很好的时候。所以不要过于结果导向，关键是我们要尽可能提高我们成功的概率，只要概率够高，少量的失败是没有问题的。而帮助我们提高概率的方法便是“致人而不致与人”。不过这句话说的简单，要做到却很难，这也是《虚实篇》在讨论的问题。

”故知战之地，知战之日，则可千里而会战。不知战地，不知战日，则左不能救右，右不能救左，前不能救后，后不能救前，而况远者数十里，近者数里乎？……故策之而知得失之计，作之而知动静之理，形之而知死生之地，角之而知有余不足之处。“——《虚实第六》

要做到“致人而不致与人”，我们必须要做到“知战之地，知战之日”，也就是了解自己的战场在哪，什么时候打这个仗。比如，你的项目到底要解决什么问题，如何解决，计划安排是什么样的？清楚了就可以安心开始干活了。但是如果不清楚这些就直接开始干活，那计划和人员安排都会乱做一团，最后只会导致项目失败。

所以，为了帮我们做到这点，孙子提出了四种方法：

  1. 策：策度敌情，分析敌我双方的计谋。这就是需求分析，了解我们的用户到底要什么。
  2. 作：戳对方一下，看对方怎么反应，这样便知道对方的虚实了。这就是作实验，看看到底那里不对，弄个简单的PoC，试一试能不能解决问题。
  3. 形：这是让对方显出自己的军形，比如上面提到的作就是其中的方法之一。而对于我们来说，我们可以通过其他方法，比如沟通，来让用户的真实意图显现出来。
  4. 角：就是比较。比较双方的实力，看看哪些地方有余力，哪些地方还欠缺。这样就可以做到准备充足，避实击虚，直击用户的痛点。

我们可以看到，这几条的关键都是要我们了解当前情况，所以凡事多琢磨，不要恐惧，多观察，多学习，多提问，学会了我们就知道了。

“十则围之，五则攻之，倍则分之，敌则能战之，少则能逃之，不若则能避之。”——《谋攻第三》

另外在工作中，我们总是会遇到一些特别难的问题，就算我们“知战之地，知战之日”，依然实力不够，怎么办呢？

孙子的方案是，不管对手如何，我们都应该保证以强胜弱，如果对手很强大，我们就应该将其兵力分开，然后找到弱的部分一口一口的吃掉。所以，遇到难题或者大的项目，想办法把他拆解成小项目，小问题，然后合理计划，一步一个脚印的去完成它。如果实在过于困难，大不了我们就避开他，想想有没有其他的解决方案。很多时候，方法过于复杂其实是因为我们选的方法根本不对，最后导致了它很复杂。

“夫兵形象水，水之形，避高而趋下；兵之形，避实而击虚。水因地而制流，兵因敌而制胜。故兵无常势，水无常形，能因敌变化而取胜者，谓之神。“——《虚实第六》

所以，对于虚实，最后孙子就总结了两点：

  1. “兵之形，避实而击虚”。攻击要攻击对方的弱点，我们做产品也要直击用户的痛点。
  2. “兵无常势”。要因敌为势。做事情没有固定的套路，用户的需求总是形形色色，不同服务的状态特点也各有不同，所以我们要根据当前的情况随机应变。

4.4. 组织管理：造势任势，奇正相生，兵必选锋

到了这一步，我们终于可以开始讨论作战的战术了。而关于战术，如何管理好我们的组织，便是这第一步，而孙子给了我们三板斧。

“故善战者，其势险，其节短。势如彍弩，节如发机。……故善战者，求之于势，不责于人，故能择人而任势。 ”——《兵势第五》

这第一招，就是先造势，再任势。

首先是“造势”。“势”的关键是“其势险，其节短”。积累的能量最大，而且释放的距离最短，因为这样就能准确命中并且杀伤力极强。这就像是猎豹捕猎一样，虽然猎豹跑得很快，但是在捕猎的时候也会潜行到猎物的身边，在尽可能近的地方发起进攻。而“造势”就是告诉我们，无论做什么都要做好充分的前期准备，把事情搞简单了再动手，比如，设计文档有写清楚吗？合作团队有做好沟通吗？这样，最后动手时才能简单有效，直击要害。这也再次反映了孙子的思想，“善战者，无勇功”，因为到了真正做事情的时候，事情已经变得很简单了。

造势对于做事来说非常关键，为什么呢？因为这样就能“不求于人”。也许你的手下不会都是精兵强将，但是有了势，就能弥补他们的短板，让大家都能干活，这样就能做到“不责于人”。而且说回来，如果真的是手下能力不行，那也是领导的原因，毕竟是人员配备也是领导安排的呀。

造好了势之后，便可以“任势”了。任势就简单了，关键就是要根据大家的能力，把正确的人放在正确的位置上，然后借着势的力量推动大家干活就行了。

“凡战者，以正合，以奇胜。故善出奇者，无穷如天地，不竭如江海。”——《兵势第五》

这第二招，就是奇正相生。

“以正合，以奇胜”，这句话是另一句被人误读最多的话了，比如我们都知道的成语“出奇制胜”，所以这一句话很容易被理解成“出其不意、攻其无备，靠奇袭获胜”，其实不然。

这句话最早也是出自风后的《握奇经》，讲的是如何排兵布阵，“虚实二垒，皆逐天文气候、向背山川利害，随时而行，以正合，以奇胜。天地以下，八重以列”。“奇”在这里读做“ji”，意思是多余的部分，也叫做“余奇”。这句话的意思是要根据实际情况安排人手，正兵安排好了之后，余下来的就是奇兵了，留到关键的时候再用。也就是说，奇兵是预备队，是自由人，是我们做任何事情都保留下来的那部分余力，是我们留在手里的底牌，有了他我们才能更方便的根据形势随机应变。

在仗打起来之后，根据形势变化，“奇”和“正”可以互相转换，当奇兵投入战场之后，也许主战场会迁移，之前的正兵会空闲下来，此时便发生了奇正转换，之前的奇兵变成了正兵，而正兵变成了奇兵，于是我们可以指挥新的奇兵进行游走，去配合攻击其他的点，而到那时也许就会发生下一个奇正转换。这就叫做奇正相生。

“奇正相生”的关键在于无论何时我们都需要分兵，而无论兵力多少，这里举几个栗子。

  • 霸王项羽，最后战败到了乌江边，手里只剩下了二十八骑。而即便这样，这二十八骑，也不是一起冲杀，而是分为两组，一正一奇，首尾相助。
  • 踢足球，控球的人便是正，而旁边配合的人都是奇，奇兵在场上穿插找机会，等到控球的传球了，奇正转换变发生了，如此反复，便是奇正相生，无穷无尽。
  • 工作中安排项目，在规划时间时，故意留出适当的空间，以备不时之需。如果有多个项目，则可以让他们偶尔互相帮助。但如果一开始正常开发时就把全组人逼到996，一旦出现特殊情况，项目就只能延期。

总之，手里一定要有底牌，要有余力。一旦机会出现，我们便可以把他打出去，这就叫出奇制胜。所以，真正的兵法从来不靠什么小聪明，那些所谓的计谋，我们会，别人也会，用的了一次，用不了第二次。所以不要想着贪巧求速，哪怕是出奇制胜的出处，也不过是告诉我们要保有余力，等待胜机。

“兵无选锋，曰北”——《地形第十》

这第三招，就是兵必选锋。

“选锋”，就是把最精锐的人挑选出来，组成先锋队，打头阵，打关键点。他们就像一把尖刀，刀刀致命。有了“选锋”，我们的团队才有兵锋，这对于团队管理来说非常重要：

  1. 兵锋是治气的关键。开始打仗时，因为未知，大多数人心中都会或多或少存在一些恐惧的心理，我方是不是太弱小，对手是不是太强大？所以开场打几个漂亮的大胜仗是非常重要的，这些仗不一定要多难，但是一定要漂亮，因为它可以极大的鼓舞我们的士气。真正的战场上的一般做法是攻几个小镇子，烧杀抢掠一番，弄一堆战利品回来，大家开开心。而我们做事的时候也可以效仿，弄个简单的PoC，然后说，你看，就这么简单，这就能用了！这样就能大大提高团队士气。
  2. 团队成员能力参差不齐，不能混在一起让他们一起做同一件事情。这样强的人觉得没有成就感和荣誉感，也就没有做事的欲望，因为做了你也不知道是他做的，而弱的人觉得反正有强的干活，每天摸摸鱼，事情同样也能完成，这样项目根本没有办法顺利进展。《黑客与画家》中提到了升职致富的两个必要条件：可测量性和可放大性。这里就是缺少了可测量性，导致了大锅饭的产生，让所有人都失去干活的动力。

这就是孙子管理团队的三板斧！

4.5. 临场决策：抓住重点，居安思危

“涂有所不由，军有所不击，城有所不攻，地有所不争，君命有所不受。……治兵不知九变之术，虽知五利，不能得人之用矣。”——《九变第八》

接下来，战术层面上，我们就需要合理的进行临场决策，虽然我们之前了解了很多原则，但是真正到了实际做事情的时候，形势不同情况不同，最后决策也应该做出相应的调整，这就是孙子兵法第八章的内容——“九变”。

读这一章的的时候千万注意别读死书，因为毕竟我们不打仗，别去纠结九变是哪九变，别去纠结工作里面怎么“圮地无舍，衢地合交”，而是主要去学习他的思想。那就是虽然我们做事情有计划，但是有些时候我们必须根据当下的情况做出适当的调整。这个世界存在太多未知的未知，如果永远都按照计划死死的来，说不定会撞的头破血流。

另外就是我们做事情，要抓住重点，懂得放弃和权衡利害。“涂有所不由，军有所不击”，做决策前静下心来想一想，你要的到底是什么。

最后注意一点，“九变”变的都是特殊情况，而不是常态。不是说有好路我偏不走，有好方法我偏不用。另外特别注意那句“君命有所不受”。和上面提到的一样，君命可以不受，但是是有代价的，出了问题，后果是很严重的，放在古代可能就军法处置了，放在现代也许年终奖金和升职加薪就没有了。所以，除非两害取其轻，依然是不受比较好，那你可以不受。不然，还是不要做的比较好。

“是故智者之虑，必杂于利害。杂于利，而务可信也；杂于害，而患可解也。”——《九变第八》

所以，我们到底如何做临场决策呢？孙子给出的答案就是“杂于利害”。

  • **“杂于利”，叫居安思危。**形势大好的时候，多想想不利的可能，把所有情况都考虑清楚了，我们做事情就会更有信心。
  • **“杂于害”，叫转害为利。**形势不好的时候，就多思考有利的部分，找寻解决困境的突破口，我们就可以解除自己的危机。

出事是必然的，只不过是时间问题，所以不管是顺境还是逆境，我们都要多多思考，有备无患。

“非利不动，非得不用，非危不战。主不可以怒而兴师，将不可以愠而致战；合于利则动，不合于利则止。怒可以复喜，愠可以复悦，亡国不可以复存，死者不可以复生。”——《火攻第十二》

临场决策还要注意客观，不要让情绪左右决策，也不要心存侥幸，因为情绪和侥幸都是一时的，而决策却影响深远。不参杂个人的因素，这样才能做出正确的判断。

“故用兵之法，无恃其不来，恃吾有以待也；无恃其不攻，恃吾有所不可攻也。”——《九变第八》

这样平时多思考各种的可能性，戒之于无形，防之于未然，我们就不用担心对方的进攻。因为不是对方不想进攻，而是我们让对方不敢进攻。虽然可胜在敌，但是不可胜在己。

4.6. 临阵执行：风林火山，法令严明

“其疾如风，其徐如林，侵掠如火，不动如山，难知如阴，动如雷震。”——《军争第七》

到了这一步，势也有了，机会也有了，战术层面到了最后执行上，攻击便是要催枯拉朽，借着势的力量，一鼓作气，迅速完成目标，这样士气才会高昂。防守便是要不动如山，不管对方如何试探，我自岿然不动，完全不予理会。

我们可以想象一下，如果一个简单的项目，最后做了两年还没有出什么结果，那必然项目里面的人各个都死气沉沉，毫无动力。但是，如果一路高歌猛进，每周都能看到大的进步，最后项目顺利完成，大家该拿钱拿钱，该升职升职，这样的团队必然士气高昂！同样的，如果已经到了开发冲刺阶段，产品却一天到晚给开发组塞新的需求，那么这个时候就应该马上拒绝，并告诉他去规划下一个版本。

“令素行以教其民，则民服；令不素行以教其民，则民不服。令素行者，与众相得也。”——《行军第九》

执行过程中另一个特别关键的事情就是法令。法令的关键便是严明，“严”就是有法必行，没有例外，“明”就是事先申明，人人明了。

所以，让法令生效的第一个关键点就是：令要“素行教民”。它的严肃性、权威性、稳定性，比法令的现实性更重要，一旦定下来了，就不能动不动就破例，而且身为领导要以身作则。一个服务出了问题，那么负责人就必须要上去调试修复，某个代码提交搞坏了代码库，那作者就必须要把代码库复原。不能说，今天我搞坏了，我是领导，我才不管呢，明天你搞坏了，你是小弟，你一定要修，这种法令自然没人服。

“卒未亲附而罚之，则不服；不服，则难用也。卒已亲附而罚不行，则不可用也。”——《行军第九》

另一个就是要注意分寸，恩威并施。一个新人刚来，弄坏了一个东西，按照规矩，这个东西他必须修，这个并没有什么问题。但是问题是他可能不懂要怎么修，所以前几次，你得教他，他会了他懂了，你才能放手，这时候的罚才有意义。

4.7. 奖赏开销：不知敌情，不仁之至

“凡兴师十万，出征千里，百姓之费，公家之奉，日费千金；内外骚动，怠于道路，不得操事者七十万家。相守数年，以争一日之胜，而爱爵禄百金，不知敌之情者，不仁之至也。”——《用间第十二》

最后，孙子在最后一篇《用间篇》中还提到了他对奖赏开销的金钱观：“不知敌情，不仁之至”。

孙子认为，相比整个军费而言，一些小的奖赏真的不算什么，完全不需要为此小气抠门。省下了一点点钱，却错过了关键敌情，延误了战机，因小失大，这就是不仁之至了。所以：

  • 项目开始时，不要吝啬那一点点钱招人，人不在多，人多了只会增加沟通成本，对项目不一定有好处，我们要的是精兵强将，因为兵锋是治气的关键，这些人才是带给团队士气的人。我之前有一个项目，就因为大老板想节省成本，非要将项目交给一个遥远的异地团队去完成。可是，这个团队的能力过于糟糕，一个本来一两个月就能完成的工作，做了两年都没有做完，而我也被长达两年的跨时区合作折磨的身心俱疲，一度想辞职走人。
  • 项目过程中，有一些能用钱直接解决的问题，也不要吝啬，只要合理，尽量解决。花钱是为了创造机会，排除困难，钱总是会来的，但是机会不常有，这种小钱花的值。别总想着把钱花在刀刃上，有时候你根本不知道刀刃在哪，不如分散投资，提高撞到刀刃的概率。我之前一个老板就是典型，当时我在做崩溃和内存分析，但是我的机器内存和硬盘不够，所以1:1的时候我就和老板提了出来。两天之后，老板找到我，说他自己掏了腰包帮我买了64G的内存和一块4T的硬盘，让我拿去用，而且这不属于公司，要是之后离职别忘了带走。遇到这种老板，你真的跟的心里踏实。
  • 项目最后，论功行赏，不要吝啬那一点点的奖金，这样大家才愿意继续跟着你干，因为有肉吃。

“五间之事，主必知之，知之必在于反间，故反间不可不厚也。”——《用间第十二》

如果你还是舍不得，这里还有一个帮你平衡心理的方法，那就是不要给人定价，而是要给你自己定价，给你的事定价。不是对方值钱，而是你的事情值钱。

5. 总结：学会认输

“故小敌之坚，大敌之擒也。”——《谋攻第三》

整本书读下来，我最大的感觉便是，孙子兵法的重点不是告诉我们各种打赢的策略，而是在教会我们：想打赢，首先要学会认输。从五事七计到五间之事，都是在告诉我们，要了解自己的不足，了解自己和对手的差距。没有准备好之前，不要贸然行动。实力不够，又死要面子，就必然成为被对手所擒。

所以，承认自己的弱小，正面自己的问题，这样自己才能继续进步，变的更加强大。

]]> <p>我也不知道是为什么，就是突然很想看这本书，但是文言文真的好难啃啊，于是这几周就一直在读这一本书……</p> <p><a href="https://zh.wikisource.org/wiki/%E5%AD%AB%E5%AD%90%E5%85%B5%E6%B3%95">《孙子兵法》</a>这本书很有意思，读完之后发现，其中最著名的几句话，也是对其误读最深的几句话，比如“兵者，诡道也”，比如“置之死地而后生”。本来是打算把这本书当作一本故事书读着玩的，结果哪里知道，这本书讲的全然不是什么诡道，特别的平实，满满的正能量，他教我们怎样做事，怎么管理企业和团队，怎么样评估风险控制预算，等等等等。真的没想到几千年前讲的东西，哪怕是到了现在都非常的实用。也许不管时代怎么变，科技怎么发展，人，终究还是人吧……</p> <p>另外一个有意思的地方就是，其实《孙子兵法》有很多内容甚至核心思想也都不是其原创，而是更早的人发明了之后流传下来的。这个人便是黄帝身边的宰相，叫做<a href="https://zh.wikipedia.org/wiki/%E9%A2%A8%E5%90%8E">风后</a>。没错，就是<a href="https://movie.douban.com/subject/26815153/">《一人之下》</a>里风后奇门的风后。除了因为风后是最早发明这些兵法的人，还因为风后留下来到现在著作《八阵图》和<a href="https://zh.wikisource.org/wiki/%E6%8F%A1%E5%A5%87%E7%B6%93">《握奇经》</a>里面详细描述了如何运用八卦进行阵法布置，所以就有了《一人之下》里面的风后奇门的演绎了。</p> <p>好了，让我们说回正题——《孙子兵法》吧。</p> 《重来3：跳出疯狂的忙碌》（It doesn't have to be crazy at work）读书笔记 http://r12f.com/posts/reading-time-it-doesnt-have-to-be-crazy-at-work/ 2021-03-03T03:51:01.000Z 2021-03-03T03:51:01.000Z 在现在这个遍地996福报的年代，人们的生活压力越来越大，沟通的便捷让工作几乎侵占了生活的各个角落，老板们周末在微信群里的胡言乱语，同事们随意发送的“有空吗”的垃圾信息，在家办公导致工作更加没有边界，这些都让我们的生活越来越疯狂。然后，2020年下半年，重来3出来了，给我们描绘了一个安居乐业的美丽新世界！**这本书的目标只有一个，那就是帮助我们打造一个冷静的公司，拒绝加班，拒绝没必要的压力。**虽然在这个军备竞赛的年代不知道什么时候才能真正做到，但是我们每个人都可以开始慢慢从点滴做起，毕竟每周40个小时的工作制是前人们拿性命换回来的，别就这样随手又还给了资本家。

1. 写在前面

虽然没有加班的世界确实很美好，但是这并不意味着大家可以任意摸鱼，也不意味着公司无所求的无限付出。为了实现这个美丽新世界，我们需要先来了解一下它的大前提，这些虽然在重来3里被一笔带过，但是作者其实是用了《重来1》和《重来2》两本书来解释的。

首先，**最重要的就是人，真正优秀的人！**重来2花了一整本书来介绍远程办公的可行性，其原理就是创建一个正向的反馈，因为远程办公带来的跨时空的便利性，所以公司可以不受约束的寻找最优秀的人才，而这些优秀的人也让远程办公变得更加可行。一旦正向反馈被创建起来，公司就能走向正轨，可是如果员工利用便利天天摸鱼，那很快公司就会完蛋。那我们要寻找什么样的员工呢？重来2中也给出了答案：

  • 能像承包商一样工作，独立，负责，自驱，能制定合理的时间表，定期展示阶段性成果，把往往很模糊的工作定义转变成清晰易懂的概念
  • 虽然不要求招进来就是技术明星，但是技术能力不能差，必须要能干活，做不好试用项目直接淘汰，毕竟37signals只要到任务重到忍无可忍了才会招人的
  • 人品好，团队的人必须要都喜欢
  • 优秀的沟通能力，同理，共情

然后，就是公司的运作和方向，这个也就是重来1中商业思维的核心，而其中很重要的一点就是如何面对对手。现在很多公司都在疯狂的搞军备竞赛，别人有的我也一定要有，但是却从来没想过为什么，用户到底要什么，有没有更好的方法。这样导致了对对手功能的盲从，把自己人累的半死不说，最后这种缺乏独特性的产品，也未免能带来多少真正的用户。在《创新者的窘境》中，克莱顿·克里斯坦森构建了一个失败理论框架，以解释为什么伟大的管理者作出的合理决策会导致企业的失败，而这个框架中很重要的一环就是“破坏性技术（Disruptive Technologies）”的出现，它是导致领先企业失败的重要原因。这和《重来1》中提到的观点一致，不要照搬，不要盲从，保持独特性，因为独特性是我们保持冷静却依然能和对手抗衡的基石。

了解了这两个前提，我们就可以再来看本书描述的“理想”世界了，然后你会发现这本书其实这一点都不理想，很务实。

2. 公司即产品，文化即践行

“他只是坐在那里，嘴里说：“做这个！做那个！”当然，什么都不会发生，光说不做是没有用的。

– 哈里·杜鲁门，《关于总统的权力》

和书中写的一样，这一切始于这个概念：你的公司是个产品。就像产品需要不断改良一样，公司也需要迭代才能不断进步。当我们把自己的公司当作产品来审视的时候，我们就会开始问自己各种各样的问题，比如，它的运作简单吗？效率高吗？有漏洞吗？一旦换一个角度，开始了疑问和思考，改进也就会随之而来。不要想着一蹴而就，慢慢调整，迭代地尝试出最适合我们自己的方式。

比如，我们组的轮值（oncall），一开始和其他组一样，是7x24，然后所有人都觉得压力过大，于是改为7x12，一次白天一次晚上，然后变成7x12，但是分两批，自愿白天和自愿晚上，并且值夜班的人可以享受不处理sev3和做RCA的待遇，最后随着人员增加，改成了1x24，虽然一个月会轮值一次，但是每一次压力都小了很多。除了频率，报警的级别我们也调整了很多次，很多报警都改为了只在上班时间发，尽可能的保证大家能睡个好觉。当然，现在我们组的状态也不一定是最佳的方法，有兴趣的小伙伴可以参考G家的《SRE》，为oncall压力建立量化模型，然后进行管理。

有了产品的概念，我们就可以开始着手调整公司了。而公司里面最重要的事情之一就是建立企业文化。

很多人都有一个误区，认为企业的文化是通过聚餐建立的，这个错的就非常离谱了。没错，我承认偶尔聚餐确实能帮助大家保持私交，但也就仅此而已。文化不是我们嘴上说说就能形成的，而是要靠至上而下的践行。未加理会的行为会渐渐变成被批准的行为，而**不断重复的行为会渐渐成为习惯，最后形成常态，也就是所谓的文化。**所以，日常做好自己的每件事情，就是帮助建立好文化的最好的办法。

比如，我们说我们要搭建这个世界上最稳定的系统，然后不写测试，什么都往外面发，所有人也就会跟着有样学样，但是如果我们保持谨慎，重视测试，对团队坚持这个要求，慢慢的，即便我们没有这个口号，写测试也会变成我们团队的文化。同理，不加班也是。如果你身为老板，却不能以身作则，每天表现的和工作狂一样，那手下的员工也只能有样学样，也就根本没法在公司里倡导合理的工作时间、充足的休息和健康的工作方式。你怎么说不重要，怎么做才重要。

好了，“公司即产品，文化即践行”，这两个概念是整本书的理论基础，没有它们也就没有了改变公司的可能。

3. 建立反馈渠道

调整企业就是调试产品，第一步也是最重要的一步，就是信息收集。所谓“bug调三天，修改一两行”，调试一个透明的系统都何况如此，收集员工对于企业的真实意见的难度便可想而知了。所谓忠言逆耳，在领导面前，大家或多或少的都会“谨言慎行”，怕一不小心就惹得领导对自己怀恨在心，耽误自己的前途。所以这里主动沟通和保持真正开放的文化就变得相当重要。

“我办公室的门永远开着”，这句话估计不少人都听过或者说过，它听着很动听，但是其实却是将坦诚交流的责任推给了员工。刚读到这个结论的时候，我也觉得很惊讶，但是对照自己以前的经验，这句话换来的回答也确实几乎都是“谢谢老板，我没有什么问题”，这完全起不到我们想要的作用。而老板们真正应该做的事情有两个：第一个是开口去问，而且专挑最为尴尬的问题去问，直戳痛点的去问，这些问题你如果不去问，你永远都不会知道答案；第二个就是建立“实话实说是安全的”的沟通环境，有合理的反馈就应该思考并切实的进行改善，不要辜负了员工对你的信任，尽快地建立正向循环。这样慢慢的，实话就会越来越多。

我以前呆过一个项目组在这一方面尤为擅长，其中一个常用的方法叫做“吐槽大会”。每隔两周或一个月，我们组会组织一个半个小时的会，邀请所有组员对项目进行吐槽，从老板开始，有什么不爽的，觉得SB的，大家尽可能的畅所欲言。这里老板的吐槽尤为重要，如果老板的吐槽不痛不痒，那么所有的槽点都会不痛不痒，但是如果老板带头猛烈炮轰，接下来就是全员炮轰，一个比一个凶，非常过瘾。然后会议最后五分钟，我们会将所有的炮轰的点进行一个总结，把能改善的点挑出来，然后所有人，包括老板自己，每人领一两个活（尤其是老板，请领最难的那几个），在接下来的两周找时间进行改善。这样通过一轮一轮的迭代，让小组的节奏保持在一个大家都舒服的位置上。

这里需要再次强调，这个舒服不是用来给大家摸鱼的，虽然我们不提倡加班，但是同样也不提倡无所事事的混吃混喝。

另一个比较好的方式是公司层面上的年度匿名反馈，通过调查问卷的方式收集员工对公司的满意度，从而了解当前的状态。这个问卷调查有一个特别重要的一点就是保持匿名，如果有方法可以反推出是谁在某一项中打了低分，那么这个问卷就完全失去了意义，这也是问什么要在公司层面上来操作。因为人多，所以我们无法猜测这些分数的来源，另外，这也能帮助我们排除那些“所有东西都太完美了”的噪音反馈。

当有了反馈渠道之后，我们就可以进行决策并付诸实践了。

4. “我快忙疯了”

相信这句话很多人都说过，被工作压榨的喘不过气的感觉着实难受，这个主要原因有两个：一是工作时间被各种或真实或虚拟的东西干扰，被切割得七零八碎；二是不惜任何代价追求成长，这种不健康的执念促使人们设下不切实际的期望，把他们压迫得疲惫不堪。这里我们就一个一个问题来解决。

5. 专注，专注，再专注

“种种想让生活变得轻松的努力，反而给人带来无穷的麻烦 …… 我们以为自己省下了时间；然而，我们其实是把生活的步调加速成过去的10倍快，于是我们整天忙忙碌碌、焦躁不安。”

– 尤瓦尔·赫拉利，《人类简史：从动物到上帝》

也许你早已发现上班的时候越来越难完成工作了，工作大多反倒是在清晨，深夜和周末完成的。没完没了的消息，邮件和会议，把你上班的时间切割的七零八碎。刚做了5分钟事情，就来一个消息：“在吗？”；过不了多久又来一个电话，我们有一个紧急的东西要讨论，能来参加一下吗？然后，下一个预先安排的会议过不久又要开始了，抓紧时间再干10分钟。于是在这样一个环境里，我们工作时间越来越长，睡得越来越晚，并不是因为工作量增加了，而是我们根本没办法在上班时间完成我们的工作。

要做出改变，保持冷静，我们就必须要保护员工最脆弱也最稀有的东西：时间和注意力，也就是尽可能的减少干扰。而其最重要的方法，就是要打破员工之间的依赖。

首先，我们需要在结构上保证团队的高效率。这里37signals的解决方法是使用两名程序员加一名设计师的三人小组进行开发，这个带来了很多好处：

  • 因为小组间做的项目是独立的，所以它从结构上减少了小组间的依赖；
  • 三人小组也降低了小组内的沟通成本，小组内的状态很容易进行同步；
  • 奇数团队还让投票永远都不会有平局，所以也很少出现做不了决定，需要更多人参与讨论拍板的情况；而当小组出现争议的时候，我们可以考虑使用“我不同意，但我会配合你”的方式进行合作，我们都不是神，谁也不知道市场到底会喜欢那种方案，如果真的争议很大，那么可以先配合做一个版本，让市场来告诉我们答案；
  • 三人小组还让成员间很容易互相熟悉，并建立高度的信任。书中提出了一个很有意思的概念：“信用电池”，电量高，合作就顺畅，电量太低，你看对方的眼光就会非常苛刻。当大家初次见面时，电量都是50%，根据你是否能兑现承诺的事情，每次打交道时，这个电池要么充电，要么耗电，一旦电量耗尽，对方做的任何小事都会让你不胜其烦，而唯有做一些与以前不同的事情才能改善其状态。用书中的原话说：“最糟糕的做法就是假装你们之间的别扭感不重要，假装工作上的事都是“对事不对人”。这简直是愚蠢无知！事都是人做的啊，情绪必定会影响工作。”
  • 在此基础上37signals还继续追求个人的工作独立，让每个人都能按照自己的节奏全速前进，所以效率也就大大提高；

然后，我们要将同步依赖变为异步依赖，比如：即时消息，电话，和会议等实时通信手段。处理它们需要我们立刻回应，容不得等待，于是就造成了同步依赖，这也是导致我们时间碎片化和压力的罪魁祸首。

  • 减少会议：软件工程算人月，所以开会浪费的时间是所有人时间加起来的总和。所以比如，每日例会真的有必要吗？如果大家都自觉的话，完全可以将自己的进度通过日报的形式写在一个固定的位置，每周或每月发送项目进度简报就可以了。另外一些简单的发发邮件就能确认的问题，真的有必要使用会议来讨论吗？共享日历让这个问题变得更糟，因为会议邀请没人好意思拒绝。
  • 减少群聊：群聊比会议更糟，因为它没有议程，永远没有尽头，但却好像每件事情都很紧急，让每个人都保持这高度紧张的状态，生怕错过了什么重要信息。而真正重要的事情就更应该写下来，想清楚，而不是给大家发一些未经思考的垃圾信息。而利用文档合作也更好的帮我们打破了讨论的同步依赖，让更多有价值的思考浮现出来。
  • 问问题前，想清楚问题的优先级：不要把自己想得太重要，我们的问题十之八九都可以等，也应该等，没有压力的事情就不要人为的来创造压力，少用这些同步依赖的通讯手段，给自己也给对方留出足够长的，不受打扰的时间，让大家可以高质量的完成工作。
  • 答疑时间（Office Hour）：每个项目中总是会有一些特别有经验的专家，大家都有很多问题要问他，如果每个人都随意的给他发消息，这会导致这个生产力最高的人变得毫无生产力可言。这个时候，我们可以为这些人定期在一个固定的时间设置答疑时间，帮大家解答问题。这样既保证了团队的效率，也保证了这些专家们的专注。
  • 图书馆原则：开放式办公室简直就是近几年最大的骗局之一，它除了能让公司在有限的空间之内塞下更多的办公桌以外，带来的全是负面的影响，让我们缺乏安静，私密的空间来认真思考问题。为了缓解这一个问题，我们对待办公室需要和对待图书馆一样。进了图书馆，大家都知道要做什么，尊重他人，保持安静，耳语交流，有必要讨论的时候请找会议室。

当然更加极端一点，我们可以考虑去除依赖：真的没有办法放手让员工去做一个事情吗？

在打破完依赖关系之后，对于每个员工自己而言，有两个事情也非常重要：

  • 首先是提高效率，合理的安排事情的优先级，做真正重要的事情。很多一开始我们认为必须做的事情，也许放一放就变得毫无必要了。而这个重要的选择，我们往往都做得很糟糕。
  • 另外保持舒适区很重要，令人成为大师的往往是深度，而不是广度。对自己负责的部分，我们需要时间去潜心深挖，学懂，吃透。这也是我们保持冷静的必要条件。

看到这里，也许老板们会说，这样放羊的话，我怎么知道我的员工没有在乘机摸鱼呢？其实方法非常简单：

  • 相信他们。是的，就是这么简单，相信他们。我们招进来的员工都是优秀的，所以员工的状态应当是不言自明的：我正在努力工作，请尊重我的时间和注意力。
  • 单纯的用项目进展来衡量每个人的工作，而这也是老板们该做的工作。如果员工做不好工作，那老板就该另请高明。（注意我的用词，我用的进展，而不是结果。由于未来的不可知，单纯的结果导向是非常可怕的。）

最后，用书上的话来说，希望大家“能体验到那种静谧的、笃定的、因专注而生的快乐”。

6. 冷静的公司

第二个问题便是不惜任何代价追求成长，这个主要就是公司的文化氛围导致的了。要解决这个问题，我们需要将我们的公司变成一个冷静的公司。

保持冷静最重要的事情，就是设置合理的预期，这里不仅仅是对项目，也是对人，更是对自己的心态。我们这里一个一个来说。

6.1. 冷静的心态

首先，自己的心态一定要保持冷静。别被毒鸡汤影响了，一天到晚想着怎么改变世界，怎么彻底打败竞争对手，怎么才能不被竞争对手抄袭，这些除了给自己无用的压力以外，改变不了任何事情。所以，不如保持冷静，踏踏实实的做事，单纯的做好每件事，过好每一天，在这个世界当一个和平的参与者就好。

6.2. 冷静的招人

保持团队冷静另一个非常重要的点，就是招对的人。因为如果人招的不好，最后要么只能让他走人，或者忍受这个不合适的人员，无论如何，团队中都会有人会因为这件事情背负压力，所以招人一定要小心。而招人其实只有一个标准：现在的人品和工作能力。成绩不重要（偏科），简历不重要（自学成才），过去做的好不好也不重要（成长才是关键）。也许他在之前的公司是一个明星员工，但是并不代表他在这里也能做的很好，因为不是所有的技能和经验都可以迁移，也许他在之前的组做的不好，但也许是之前的工作完全不适合他。

6.3. 冷静的项目管理

“任何企图在项目伊始就规划所有的可能需求都会落败，并以客观的延误告终。”

– Gerhard Pahl，W. Beitz，《Engineering Design: A Systematic Approach》

然后，一个冷静的团队需要冷静的项目管理。这里的项目管理不仅仅是简单的时间安排，而是从上至下整个项目的管理文化。

最重要的就是产品的目标观：追求更好，但不设置虚假的目标，只是简单的更好的服务顾客。相信很多人都经历过每年为了完成老板们拍脑袋想出来的KPI，不停地冲刺的痛苦（比如用户量）。特别到了年底，为了这几个目标，更加是不择手段，强行推送，绑定安装，无所不用其极。这其实除了伤害用户以外，没有任何作用。产品没做好，今天强行安装了，明天用户就给卸载了，最后还落下一个骂名。然后，更无聊的是，好不容易完成了这一年的目标，第二年，老板又会拍脑袋想出一个新的目标，然后大家接着继续疯狂。这些人为的目标都是压力的源泉，面对目标，我们要知足常乐，目标合理就好。另外，比如用户量这种目标，除了满足我们小小的虚荣心以外，根本无法给用户带来真正的好处，这岂不是缘木求鱼？很多企业其实已经发现了这一点，并且将KPI变成了OKR，使用场景和真实的可分解可量化的目标来进行规划。毕竟产品做好了，我们才有能留下用户的能力。

接下来是操作层面上的方法论，主要有三点，都是帮助团队保持冷静的好方法。

第一点就是不要做过于长期的规划。这是因为，我们真的对此不擅长。丹尼尔•卡尼曼在《思考，快与慢》中提出，我们在决策时，经常会忽略掉以前的经验，而只关注未来要做的事情（“这个事情很简单，两天就做完了”，其实上一次类似的任务做了一个月），而且为了思维的连贯性，我们以为我们了解过去，但是其实我们只是了解一个我们为过去编造的故事。当然这还不是糟糕的，更糟的是预测未来。纳西姆•塔勒布在《随机漫步的傻瓜》中指出，这个世界缺乏定常性，黑天鹅事件随时可能发生，我们没有办法使用过去的经验预测未来，也就是说，这个世界上存在所谓的未知的未知（任务看着很简单，结果发现和想象的完全不一样）。这两大原因导致了我们对长期项目的估计和规划错到离谱。我们早点承认这个事情，就早点从这种无谓的挣扎中解脱出来。当然，也正是因为这个原因，在我们没有深入了解对方工作的时候，就永远不要认为它简单而做出错误的估计。

对此，37signals的解决办法非常直接，就是干脆不做长期规划，以6周为一个开发周期进行迭代，只规划这6周的任务和目标。这不代表放弃远见和长期目标，而是说，所有的大目标都需要能被分解，并小步完成，而如果中间出现意外，也能灵活的调整和转向。这是一种“曳光弹”的开发模式，而不仅仅是软件开发，这个模式很多地方都在用，比如美剧和日本动漫。

第二点就是关注核心需求，勇于对需求说不。

关注核心需求，除了我们听腻了的专注在真正重要的事情上以外，书中还有两个比较有意思的地方：

  1. 核心不仅仅是功能，还有文化和理想。比如37signals为了保证小客户的利益，保证团队不被大客户左右，就毅然放弃了按用量付费，而是统一收费，不给大客户当“贵宾”的机会，而这也让他们团队更好的保持冷静。
  2. 老板们请以身作则，不要想到一茬是一茬，时不时就“随便建议一下”，你的随便建议非常有可能就被你的组员当作最高优先级来处理，最近疲於奔命。

勇于对需求说不，也是帮助我们专注核心和保持冷静的一个重要手段。

  • 首先，把一个稳定的东西弄坏，往往比改进它更容易。你有没有遇到过你的用户在想办法回滚到老版本的情况？处理线上事故时，你是不是经常听到有人问“有什么东西变了吗？”。
  • 其次，做事情一定要保存一些实力，《孙子兵法》说，“以正合，以奇胜”。千万不能让自己透支。承诺是债务，因为它给了用户一个使用未来版本的错觉，所以拖延的越久，代价和压力就越大。
  • 最后，没有确定的未来才有无限的可能，而一旦答应了某件事，就相当于拒绝了其他所有的可能性。

所以在答应某件事情前，请三思。但这不代表可以无视用户的反馈和建议，尊重用户，认真倾听，但是仔细选择要做的事。

第三点就是冷静的项目安排。

我们的截止日期是稳定的，公平的。在这个稳定的时间周期里，可以变化的就只有任务的规模，所以问题就在于做哪些任务了？这种方法被书中成为“预算式的项目管理”，因为时间固定，我们无法提出任何不切实际的期望，工作量也无法膨胀，在筛选任务时，我们也会聚焦在真正重要的事情上。

然而，我们一般用的方法都是“预估式的项目管理”，偏偏我们对此不怎么擅长，最后又由于截止日期的原因，让我们忽略问题本身的复杂度，要求员工不计一切的完成它，最后带来无穷的压力，把整个团队都搞垮。

也许你会好奇，那要是做到一半，有新的想法，怎么办？要是错过了这一班火车，当然就是搭下一班啦！越是到一个开发周期的后期，任务就越是要聚焦。有点子是好事，但是在项目过程中发散，就必然导致任务量的增加，最后弄出一大堆烂尾项目，这会非常影响团队士气。虽然我们说关注核心需求，完成比完美更加重要，但这不是我们交出潦草作品的理由。做事情不要天马行空，要有始有终。

另外，我们还要控制好项目节奏，比如：

  • 别在周五发布新版本，除非你想每个周末都加班。周末加班很可怕，因为只要一个周末没休息，我们就相当于要连续工作12天（7+5）。我们现在的组就是在周一发布版本，团队压力确实降低了不少。
  • 主动掌控变化。比如，小步快走加上合理的风险控制，这样如果出错了，我们随时都能回头。又比如，特别大的版本升级，我们可以把选择权交还给用户，老用户可以选择永远用老版本，“更好”不一定真的更好，有些时候“熟悉”更加重要。
  • 不要拍脑袋想结论，拖延项目周期，给自己增添不必要的烦恼。产品好不好，让数据和真实的用户说话，发布出去，迭代、改进，发布，然后学习。
  • 将生活的节奏带入工作。一成不变的项目节奏，有时候给人的感觉更糟。用相同的方式、相同的步调，做着相同的事情，时间一长，人就会变得沉闷僵滞。其实生活是分时令的，我们可以用工作时长、任务难度，甚至专门的福利来强调季节更替的感觉，为项目添加活力。
  • 不要过分相信所谓的最佳实践，规模不同，事情不同，一切都会不一样。“甲之蜜糖，乙之砒霜”，我们要找到适合自己的节奏。

6.4. 主动控制流言蜚语

每个团队都会有一些伤心的时候，比如员工离职。无论是主动离职，还是被解雇了，这个时候如果不保持信息透明，团队中就会产生大量的流言蜚语，而它们一般都会真实情况更糟糕，让团队充满了恐惧，焦虑和疑问。所以，员工离职的时候，一封告别信是肯定要发的，并且尽量把离职原因说明清楚。如果仍然不足，那么他的老板就应该继续跟进，把缺乏的事实补齐。特别是对于被解雇的员工，用事实避免流言，不要留下任何悬而未决的疑问。

6.5. 盈利才是底气

最后，盈利才是硬道理。只有盈利了，大家的心态才能真正的冷静下来；只有盈利了，我们才有自由的思考和探索的时间和空间，才能真正掌握自己的命运。

7. 工作与生活的平衡

最后，我们要自己主动的保持工作与生活的平衡。那什么是真正的平衡呢？书中给出的答案是：“如果工作可以心安理得地把下午5点后的时光据为己有，那么生活也应该可以占据下午5点前的时间。要记住，平衡，就是有给出也有拿取。”

这里，你只需为自己的时间负责，并确保团队成员知道你那天不在就行了。重要的不是打卡上下班，而是最后的成果。当然也许真的这么做的时候，你会觉得愧疚，但是请记住：“我们不是一家人”，任何宣扬“我们都是一家人”的公司都是在耍流氓，企图利用“家庭”这个概念让我们为了公司进行单向的牺牲，而冷落真正的家庭。一个优秀的企业应该做我们家庭的后盾，而不是企图通过顶替我们的家庭来压榨我们。

薪资也是工作生活平衡的一个重要部分，毕竟工作就会为了赚钱好好生活的。在37signals里面，薪资非常的共产主义，因为没有人混吃混喝，所以大锅饭完全可行。级别相同，角色相同，就同工同酬。没有薪资谈判，没有绩效奖金，因为奖金减少了反而还让人觉得被降薪了。最后，如果今年收入增长了，就拿出年度增长的25%分给所有人。就这么简单粗暴，但是离职率却出奇的低。

然后，我们来说一说什么才是真正的福利 —— **让员工受益，而公司不受益的福利才是真正的福利。**大家可以拿着这个标准来检查一下自己公司的福利，有多少是没有私心的，有多少是为了帮助大家放下工作，去过更健康、更有趣的生活的？免费的早晚餐，甚至是夜宵？游戏机室？零食吧？甚至还有供人睡觉的房间和洗衣房？这些福利都透露着各种小心机，目的就是为了让你无法离开办公室。

然后，让员工得到合理的休息也非常的重要，别一天到晚的拼命工作，保持好充足的睡眠，长时间的工作虽然会让你感觉做了很多事情，但是它会让你缺乏创意，脾气暴躁，而精疲力尽时的工作成果必然不佳。所以充实地好好干上一天活，日复一日，这就足够了。

当然，休息也就包含了度假，一个员工度假的时候，请不要给他发送工作消息。度假的目的就是为了彻底的离开工作状态啊，如果休假中还要处理工作，甚至随时会被叫回来，那还算什么休假啊？最后，假期被毁，反而会让人更加疲惫。另外还要警惕所谓的无限假期，因为没有一个标准，最后就根本没有人会休假，或者像休假最少的人看齐。

8. 写在最后

创业容易守业难，100个创业公司，一开始大家都很好，但是只要一年就剩不下几个了，雇人，防守，成本飙升，越到后面路越难，所以别把自己的能量在一开始就消耗殆尽。保持冷静，让自己能走的更远。

最后，我们来总结一下什么是冷静吧。书中是这么说的。

冷静，意味着保护人们的时间与注意力。
冷静，意味着每周工作40小时。
冷静，意味着制定合理的目标。
冷静，意味着充足的休息时间。
冷静，意味着有意识地维持较小规模。
冷静，意味着看得见的地平线。
冷静，意味着把会议视作最后的沟通手段，不到万不得已的时候就不用。
冷静，意味着非实时沟通优先，实时次之。
冷静，意味着更加独立，减少依赖。
冷静，意味着为了长远利益而采取可持续的行动。
冷静，意味着赢利能力。

书中有一个观点特别实在：公司是一系列选择的结果，每一天都是一个新机会，你可以做出不同以往的全新选择。如果你没有权力在公司范围内做出改变，那就找到自己力所能及的范围。你总是有选择的——改变你自己，改变你的期望，改变你和他人互动的方式，改变你的沟通方式，开始保护自己的时间。

最后的最后，希望你也能拥有一个冷静的工作环境，并享受这份冷静给你带来的快乐。

]]> <p>在现在这个遍地996福报的年代，人们的生活压力越来越大，沟通的便捷让工作几乎侵占了生活的各个角落，老板们周末在微信群里的胡言乱语，同事们随意发送的“有空吗”的垃圾信息，在家办公导致工作更加没有边界，这些都让我们的生活越来越疯狂。然后，2020年下半年，重来3出来了，给我们描绘了一个安居乐业的美丽新世界！**这本书的目标只有一个，那就是帮助我们打造一个冷静的公司，拒绝加班，拒绝没必要的压力。**虽然在这个军备竞赛的年代不知道什么时候才能真正做到，但是我们每个人都可以开始慢慢从点滴做起，毕竟每周40个小时的工作制是前人们拿性命换回来的，别就这样随手又还给了资本家。</p> <h2 id="写在前面">1. 写在前面</h2> <p>虽然没有加班的世界确实很美好，但是这并不意味着大家可以任意摸鱼，也不意味着公司无所求的无限付出。为了实现这个美丽新世界，我们需要先来了解一下它的大前提，这些虽然在重来3里被一笔带过，但是作者其实是用了<a href="/posts/reading-time-rework/">《重来1》</a>和<a href="/posts/reading-time-remote/">《重来2》</a>两本书来解释的。</p> <p>首先，**最重要的就是人，真正优秀的人！**重来2花了一整本书来介绍远程办公的可行性，其原理就是创建一个正向的反馈，因为远程办公带来的跨时空的便利性，所以公司可以不受约束的寻找最优秀的人才，而这些优秀的人也让远程办公变得更加可行。一旦正向反馈被创建起来，公司就能走向正轨，可是如果员工利用便利天天摸鱼，那很快公司就会完蛋。那我们要寻找什么样的员工呢？重来2中也给出了答案：</p>