问题意识
CXL是一种开放标准，用于共享内存管理，需要软件支持才能实现其功能。
CXL Fabric需要一个平台来管理状态和命令集，并且需要进一步开发以适应碎片化的硬件生态系统的需求。
关于Jrlabs，Jackrabbit Labs是一家专注于内存 fabrics的公司，其使命是通过软件推动下一代数据中心的发展。公司由行业资深人士Grant Mackey领导，他在Western Digital工作期间成为自愿开源努力的先驱者，并且是开源软件的热衷支持者、消费者和贡献者。Jackrabbit Labs在构建和启用世界上一些最大且最关键计算基础设施方面拥有丰富的经验，无论是在扩展开源部署到数万个节点，还是在超大规模存储部署到E字节方面，公司始终处于客户端、云、解耦合、分布式和高性能计算的前沿。
为什么CXL需要开源软件？
新兴的硬件生态系统（如规范、计算、交换机等）与碎片化的软件生态系统（包含CLI、GUI、API等）之间存在不兼容性，导致技术采用缓慢。通过采用开源的标准化软件栈（包含管理API、管理库、SwitchOS等），可以促进技术统一，提高CXL的采用速度。
CXL规范包含一个FMAPI，但并不是编排工具！
• FMAPI只是一个用于在网络上完成操作的API，而不是用于管理状态的工具。 • 随着主要版本更新，命令集数量迅速增加，参考图中右侧表格。CXL 3.1相较于CXL 2.0提供了更多命令集支持（例如多头设备、DCD管理等）。
注意：后面将介绍Jack基于开源软件工具链构建FMAPI管理工具。
CTL Tools操作界面及CXL交换机工作原理示意图。
左侧图解：
• Host（主机）通过CXL Switch（交换机）连接多个CXL设备。 • 一旦主机获得某个CXL设备的所有权，通过CXL规范机制，Fabric无法收回这个设备。右侧图解：
• 主机A和主机B连接到CXL Switch，通过Fabric Daemon和OS/kernel进行通信。 • 用户应用在主机上操作，发送资源附加请求并接收确认/确认附加资源。 • Fabric Orchestrator（Fabric编排器）用于协调设备连接，包括资源确认和请求确认，以实现设备的在线管理。底部说明：需要超出CXL规范的编排来实现可组合的内存系统，而不是静态分配的内存拓扑。
对CXL SwitchOS的理解首先来看看以太网交换设备，
• 受管理的以太网交换机运行SwitchOS • 例如：SONiC、Cumulus、FBOSS、EOS、NX-OS • 通过带内/带外以太网链路进行管理 • 硬件抽象层（HAL） • 可以在低端BMC或更大的x86处理器上运行 • SONiC = Debian + 以太网管理容器 • 通常有CLI shell、Web API和GUI再来看看CXL交换设备，
• CXL交换设备等同于以太网交换机 • 将运行SwitchOS来管理CXL设备 • “Fabric Manager”存在于此SwitchOS中（或作为更大编排系统的软件代理） • 具有适用于CXL交换硅片的硬件抽象层（HAL） • 外部接口可以是REST、以太网上的GUI或CXL链路上的带内协议展示了CXL交换设备和以太网交换设备的结构对比。两者都运行SwitchOS进行管理，并包含硬件抽象层（HAL）。以太网交换设备支持多种网络操作系统（如SONiC和Cumulus），而CXL交换设备则通过SwitchOS管理CXL设备，并集成“Fabric Manager”以便进行资源编排。CXL交换设备的接口支持REST和GUI等方式，以实现灵活的管理和控制。
与集群调度器和资源管理器的交互
资源调度器不想知道像CXL这样的内存结构如何工作。
• 它们不关心Ultra/Ethernet/InfiniBand/NV或UALink。 • 它们希望操作系统或一个模块来处理这些内容，以便它们能够进行资源调度。注意：资源调度平台是更上一层的集中化调度中心，当前广泛用于大中型基础设施，平台层对CXL设备的调度需求需要借助统一的API，靠手动静态分配在云环境中的运维成本太大。
流程说明：
• 主机发出资源请求（如某个pod需要更多内存）。 • 请求通过Fabric Daemon和OS/kernel传递至CXL Switch。 • Fabric Orchestrator绑定请求的资源到特定的主机ID。图展示了在Kubernetes集群中如何通过控制平面与Fabric编排器协调来分配CXL设备资源。Kubernetes的控制平面（包括KubeCtl和kubescheduler）负责资源请求，Fabric Daemon和Fabric Orchestrator则负责在底层管理和分配硬件资源。这种架构支持Kubernetes中多个Kubelet节点之间的资源共享与动态调度，从而满足pod对内存和其他资源的需求。
注意：FMAPI的主要开发工作在于Fabric Daemon和Fabric Orchestrator这两层的通信机制。
总结回顾Challenges（挑战）：
• 共享内存软件生态系统的潜在碎片化将延缓采纳进程 • 缺乏在开放环境中的应用开发 • 缺乏可用于开发的模拟或真实平台Call to Action（行动号召）：
• 立即在QEMU中试验！QEMU支持更多的CXL功能（如CXL 3.0+）比当前的CPU硬件更多。 • 软件应用开发无需等待硬件（如交换机）可用。 • 评估哪些开源工具/库/API可在项目中使用。表格中是存储硬件厂商主导的CXL开发库，部分项目源代码已开源。
引用链接[1] Jackrabbit Labs: https://www.php.cn/link/eeb74a8ddfbb606f20020fd92e80aa0f
