DOCA 向后兼容性策略
NVIDIA DOCA™ SDK 使开发人员能够在 NVIDIA® BlueField® 网络平台之上快速创建应用程序和服务。
DOCA 软件包按季度发布节奏发布,以提供新功能、性能改进和关键错误修复。DOCA 兼容性允许用户更新最新的 DOCA 软件包(包括所有库、驱动程序和工具),而无需更新应用程序。
DOCA 版本遵循 语义化版本控制 方案。也就是说,DOCA 版本的形式为 X.Y.Z,并且在应用以下情况时,每个部分都会递增
主版本 – 当可能引入不兼容的 API 更改时
次版本 – 当以向后兼容的方式添加功能时
补丁版本 – 当提交向后兼容的错误修复时
企业级 SDK 的关键属性之一是向后兼容性。向后兼容的 API 允许使用 SDK 的应用程序开发人员通过保证他们的应用程序在更新到较新版本的 SDK 后仍能成功运行,从而使其投资获利。
DOCA SDK API 可能会经历以下生命周期阶段
实验性 – 标记为
DOCA_EXPERIMENTAL
的 API 是实验性 API,不保证在即将发布的版本中存在稳定 – 标记为
DOCA_STABLE
的 API 保证在当前主版本的整个生命周期内都得到支持已弃用 – 标记为
DOCA_DEPRECATED
的 API 将在即将发布的版本中从 DOCA SDK 的头文件中删除。如果 API 之前被标记为DOCA_STABLE
,则仅在即将发布的主版本中删除。已移除 – 存在于较旧的主版本中且现在不再支持的 API。如果此 API 之前被标记为
DOCA_STABLE
,则保留二进制表示形式以维持 二进制向后兼容性。
以下小节解释了不同的向后兼容性类型,包括语义版本如何映射到这些不同类型。
源兼容性
源兼容性保证使用给定 DOCA SDK 版本编写和编译的程序可以针对较新版本的 DOCA SDK 成功编译。
如 “DOCA SDK 版本控制” 部分所述,DOCA SDK 在次版本和补丁版本之间是源兼容的。但是,在主版本之间,API 可能会被更改、弃用或删除(请参阅 “DOCA SDK API 向后兼容性” 部分下的生命周期阶段)。因此,在较旧的主 DOCA SDK 版本上成功编译的应用程序可能需要进行更改才能针对较新的主版本进行编译。
二进制兼容性
二进制兼容性保证动态链接到给定 DOCA SDK 库 (*.so
) 的程序可以成功链接到较新版本的 DOCA SDK 库。
DOCA SDK API 具有版本化的 C 风格应用程序二进制接口 (ABI),可保证跨次版本和主版本的二进制兼容性。这意味着将系统上安装的 DOCA SDK 软件包升级到较新版本始终支持现有应用程序及其功能。
行为兼容性
行为兼容性(即,语义兼容性)保证在给定相同输入的情况下,函数或组件将产生相同的输出。因此,使用给定 DOCA SDK 开发、编译、链接和测试的应用程序,并依赖于 SDK 的行为,可以成功地使用较新版本的 DOCA SDK 运行,因为该行为将是兼容的(错误修复除外)。
某些 DOCA SDK 组件包括跨远程实体的交互(主机到 BlueField、BlueField 到 BlueField 或主机到主机)。也就是说,在主机服务器上运行的进程与在 BlueField 网络平台 Arm 处理器上运行的进程之间的通信通道。由于使用 DOCA 的应用程序可能部署在大型集群中并在不同的时间表上升级,因此 DOCA SDK 保证维护彼此协议兼容的不同 DOCA SDK 版本。这允许在整个过程中执行 DOCA SDK 应用程序的滚动升级的灵活性,同时保持操作(具有不同 SDK 版本的节点保持通信)。
DOCA 以元软件包格式分发,可以是用于安装在 BlueField 网络平台 Arm 处理器上的 *.bfb
文件,也可以是用于安装在托管 BlueField 网络平台的服务器上的 DOCA-for-host 软件包(*.rpm
或 *.deb
)。此软件包包括不同的库、工具、可执行文件、固件和示例应用程序。
DOCA SDK 的开发和测试旨在与元软件包中包含的所有组件一起工作。如果这些组件中的任何一个独立升级,则不保证 DOCA SDK 能够正常工作。因此,将 DOCA 更新到较新版本需要更新包含所有组件的元软件包。