4. 多Socket系统的CXL拓扑结构
聊到多Socket系统里的CXL拓扑，很多人的第一反应是「不就是把CXL接到CPU上嘛」。嗯，这么说没错，但实际项目里你会碰到各种让人挠头的连线方式。我个人习惯把拓扑分成三类来理解——直连拓扑、交换拓扑和层次拓扑。每类背后的性能特征和调试手段都不一样。
4.1 三种基础拓扑
先看一张我自己常用的分类图，帮你建立整体认知：
4.2 直连拓扑——最简单也最容易被忽略
直连拓扑，说白了就是每个CPU Socket直接拉一根x16的CXL链路到设备。我一个项目里遇到过，客户把加速卡直连在Socket 0上，然后抱怨Socket 1上的应用访问延迟高——这不废话么，中间得绕QPI/UPI啊。
- 优点：延迟最低，没有中间跳数，单设备吞吐是满的。
- 缺点：扩展性差，每个Socket能挂的设备数量受限于物理CXL端口数。
- 典型场景：对称双路系统中的本地加速器。
4.3 交换拓扑——弹性但引入额外跳数
当设备数超过CPU直连能力时，就得用CXL交换机了。有点像PCIe交换机的思路，但CXL.cache的coherency语义让事情更复杂。
我曾经帮一个客户排查过CXL交换网络的性能抖动。结果发现是交换机内端口到端口的延迟不对称——有的端口走内部crossbar近，有的远。解决办法？把时延敏感的设备挂在优先级高的端口上。
| 拓扑类型 | 延迟增量（典型值） | 带宽共享 | 调试要点 |
|---|---|---|---|
| 直连 | 基线 | 独占 | NUMA绑定 |
| 交换 | +100~300 ns | 共享 | 端口优先级、队列深度 |
| 层次 | +200~600 ns | 级联共享 | 全局地址映射 |
4.4 层次拓扑——大型系统的命门
大型多路服务器（比如8路以上）几乎都用层次拓扑。主Socket作为根节点，下面是从Socket，再下面是CXL设备。数据从设备到主Socket可能要穿越2~3级CXL链路。
为什么要这么搞？说白了是为了节省物理线缆和端口。你想想看，8个Socket每个直连8个设备，那得64条CXL链路，实际很难布线。
我遇到的一个真实案例：在4路服务器里用了层次拓扑，某个从Socket下的NVMe CXL设备总是超时。排查发现是主Socket发回的snoop响应要在中间级排队。最后通过调整各级CXL控制器的重排序缓冲区深度解决了。
# 查看当前CXL交换机端口统计（示例命令，基于假设的工具cxlctl）
cxlctl port stats --switch 0 --port all
# 输出示例：
# Port 0: tx_packets 123456, rx_packets 123450, drop 0, latency_avg 142ns
# Port 1: tx_packets 98765, rx_packets 98760, drop 2, latency_avg 287ns
# 注意Port1的drop和延迟偏高，需要进一步检查4.5 多Socket的地址映射与NUMA影响
CXL.cache的coherency域默认是全局的——每个Socket都能看到其他Socket下CXL设备的内存。但实际性能取决于地址是如何切分的。
1. 将CXL设备内存的物理地址区间固定在主Socket的地址窗口内，让从Socket通过UPI转发访问（间接路径）。
2. 或者让每个Socket的CXL设备暴露独立地址区间，本地Socket直接访问（直接路径）。
3. 混合模式：部分地址区间本地直连，部分跨Socket共享。
我个人倾向方案2，因为它最符合NUMA的直觉。但注意，如果设备需要被所有Socket共享（比如大容量内存池），那就得用方案1或3了。
4.6 拓扑选择流程
当你拿到一个多Socket CXL项目，可以按下面步骤来选拓扑：
- 数一下有多少个CPU Socket，每个Socket有几个空闲CXL端口。
- 统计需要挂载的CXL设备数量、带宽需求、时延敏感度。
- 如果设备数 ≤ 端口总数，且时延敏感 -> 直连拓扑。
- 如果设备数 > 端口总数，但总带宽可共享 -> 交换拓扑。
- 如果Socket数 ≥ 4，且需要大规模扩展 -> 层次拓扑。
- 最后用模拟器或者原型板跑一下冲突压力测试，重点看snoop延迟和带宽争抢。