ODP API 规范
ODP由三个各自独立又相关联的组件组成。首先，ODP是一个抽象的API规范，用于描述数据面应用程序的功能模型。 该规范涵盖了许多常见数据面应用程序的编程需求，如接收、操作、传输数据包，但是并不要求这些功能具体如何实现。 这是非常有意义的，正因为ODP API没有一个优选实施例，它们允许在支持ODP实现的各种平台上运行ODP，并进行各种创新开发。 为了实现这一目标，ODP API使用了抽象数据类型描述，其定义留给ODP的实现者。 例如，ODP数据包由类型为 odp_packet_t 的抽象句柄引用，与数据包相关的API会引用此类型的参数。 这就是为什么 odp_packet_t 不是ODP API的一部分，这是实现者的责任。
ODP API 特性
- 开源，开放贡献，BSD-3许可
- 供应商与平台中立
- 以应用为中心，涵盖数据面应用的功能需求
- 通过指定ODP的功能行为确保可移植性
- 由应用程序作者和平台实施者共同公开界定
- 架构可以有效在各种平台上实现
- 由Linaro集团赞助、管理和维护
ODP API 实现
其次，ODP由这个API规范的多个实现组成，每个实现都针对特定的目标平台进行定制。 ODP的具体实现确定每个ODP抽象类型在该平台上的标识方式及每个ODP API是如何实现的。 在某些平台上，ODP API将使用某些具有加速API功能的特殊执行来实现。 另一方面，硬件协处理器引擎可能会完全卸载API，以便CPU可以很少或者完全不参与执行。 但是，不论什么情况，应用程序都会看到相同的功能行为，而不依赖于给定平台选择如何实现它。 通过允许每个平台自由地确定如何以最佳方式实现每个API的指定功能行为，ODP运行应用程序充分利用每个平台的独特功能， 而不需要具有该平台的专业知识，或者关心如何最好的将应用程序调整到特定平台。 后一种考虑在网络功能虚拟化（NFV）环境中尤为重要，其中，应用将在其他人选择的目标平台上运行。
ODP 实现特性
通用实现并不适用于所有平台，支持多个实现使得ODP适应于平台之间的差异性。
任何人都可以根据自己的平台创建一个ODP实现
每个实现的开发和维护由拥有者决定
根据业务需求确定开源和闭源
具有独立的发布周期和服务流
允许在平台的ODP API实现上使用HW和SW的新特性
参考实现
为了轻松开始在新平台上实现ODP，ODP提供了许多实现方案，作为参考。 其中两个主要的实现是 odp-linux 和 odp-dpdk 。
- odp-linux
odp-linux 实现是仅依赖于Linux系统API的纯SW实现。作为ODP的功能模型，它能方便的将ODP引导到任何支持Linux内核的平台上。
- odp-dpdk
odp-dpdk 实现是使用DPDK作为SW加速器的纯SW实现。特别地，odp-dpdk为使用NIC的系统提供卓越的IO性能，这允许ODP应用程序充分利用 DPDK支持的各种NIC设备驱动程序。
-
odp参考实现特性
- 开源，开放贡献，BSD-3许可
- 提供ODP在新平台上的轻松引导
- 实施者可根据需要自由借用或定制代码
- 是否来自参考实现，实施者可以保留对其实现的完全控制。
ODP 验证套件
第三，为了保证不同ODP实现之间的一致性，ODP包含一个验证套件，用于验证ODP的任何给定实现是否忠实的提供每个API指定的功能行为。 作为单独的开源组件，应用程序编写者，系统集成商和平台提供商都可以使用验证套件来确认任何所谓ODP实现是否符合ODP API规范。
odp验证套件特性
- 与ODP API规范同步
- 由LNG维护和分配
- 开源，开放贡献，BSD-3许可
- 是确保所有ODP实现中的应用程序可移植性的关键
- 测试ODP实现是否符合ODP API的指定功能行为
- 用户和供应商可以随时运行，以验证ODP的实现
2.1. ODP API SPEC 版本
作为不断发展的标准，ODP API SPEC以增量版本发布，ODP相应的实现以及验证API一致性的验证套件与此版本号关联。 ODP版本号使用一个标准的三级数字（major.minor.fixlevel）进行指定，根据级别所表示的变化程度递增。
- fixlevel级别的增量表示规范的说明或其他不影响规范的语法或语义的次要更改。API规范中的这种变化预计将是罕见的。
- minor级别的增量代表引入新的API或功能功能，或者对其指定API的语法或功能行为的更改，因此可能需要应用程序源代码更改。 在规范的每个版本的发行说明中都对这些更改进行了详细的记录。
- major级别的增量代表了很大的结构性变化，这些变化最有可能需要一定程度的应用程序源代码更改，再次在该版本的发行说明中记录。
2.2. ODP 实现版本
ODP实现可以随意使用他们希望的任何发布命名/编号约定，只要清楚给定的版本实现了什么级别的ODP API。 推荐使用相同的三级编号方案，其中major和minor对应于ODP API相应级别，fixlevel表示与该API级别实现相关联的实现定义的服务级别。 LNG提供的ODP参考实现遵循这个原则。
2.3. ODP 测试套件版本
ODP验证测试套件遵循这些相同的命名规则。major和minor对应于套件验证的API级别，fixlevel代表该API级别的验证套件本身的服务级别。
2.4. ODP 设计目标
ODP组件结构有三个主要目标。
第一个是应用程序在各种平台上的可移植性。 这些平台在处理器指令集架构，应用处理核心数目和类型，内存组织以及平台特定的硬件加速和卸载功能都不一样。 ODP应用程序可以从一个一致实现方便转到另一个，最多只需要进行重新编译。
第二，ODP旨在允许数据面应用程序充分利用平台的特性，包括专门的硬件加速器，而无需专门的编程。 这是通过将API规范与其在各个平台上的实现分开来实现的。 由于每个平台以对该平台最佳的方式实现每个ODP API，所以应用程序自动获得这种优化的优点，而不需要显式编程。
第三，ODP旨在允许应用程序自动扩展以支持多核心架构。 这是使用基于事件的编程模型完成的，该模型允许将应用程序写入独立于可用于实现应用程序功能的处理核心数量。 结果是写入此模型的应用程序不需要重新设计，因为它支持从4到40核到400核心。
