本博文由Shyam Iyer和Ahmad Ali撰写。

当前的Linux 体系是多家供应商各自向Linux内核独立注入代码的结果。这些代码分别遵循各供应商的硬件策略，并由不同的维护人员提交到单独的子系统中。维护人员并没有对这些更改进行必要的协调，无序的并行开发导致现在出现了多种不同的用户空间接口和管理工具。每项实施都有各自的优点和缺点。但是，为了让系统管理员在执行基本任务时只需管理通用于各供应商的工具和接口，需要在Linux DCB体系中实现管理接口的标准化。

目前有两个供应商阵营，其中一个阵营要求采用netdev接口来推送/获取配置或检索统计信息。他们依赖基于的开源工具提供引擎。最初，此方法仅用于软件启动程序，没有与用于软件启动程序的基于的工具相集成。后来此方法得到纠正，允许通过Open-LLDP/及这些工具中对iSCSI App TLV的支持为iSCSI进行DCB配置。另外，此方法还与等系统级QoS解决方案相集成。帮助实现这一目的的特定工具为。

另一个供应商阵营要求采用供应商的特定工具来管理Linux上的DCB。他们主要是融合网络适配器()供应商和传统光纤通道供应商。值得赞扬的是，此类适配器的最初客户可在迁移至基于以太网的FCoE HBA后，如愿获得与光纤通道HBA相同的外观和风格。然而，这种融合也为同一适配器中融合的功能制造了不同的“用户-内核”接口。例如，典型的CNA供应商提供SCSI HBA接口来管理其FCoE和iSCSI功能，并提供netdev接口来管理其功能。这意味着，对于CNA而言，通过netdev接口来基于Open-LLDP管理DCB并不足够。从NIC接口(netdev)中观测到的DCB队列统计信息，可能与CNA的iSCSI功能或FCoE功能的相关统计信息并不相关。

netdev阵营争论道，DCB属于第2层以太网功能，而netdev接口最准确地描述了用于探测或配置基于以太网的适配器的管理索引。但现实情况是，以太网只是传输光纤通道、iSCSI或任何其他存储/互连协议的介质。在业内一个类似的构造发展变迁中，除了软件iSCSI启动程序外，Open-iSCSI工具还已经开始集成iSCSI卸载HBA的控制和管理方面。这使iSCSI配置和管理功能变得更加简单易用。此外，用户不需要重新学习特定于供应商的新工具。与此类似，如果允许以通用的用户空间工具执行简单的DCB配置，以协调交换机设置并提供基本统计信息，将可以有效简化Linux DCB管理工作。

对于固件中没有LLDP引擎的基于NIC的解决方案，Open-LLDP在主机操作系统中提供该引擎。任何在硬件中提供DCB基本功能的NIC都将从Open-LLDP的LLDP状态机中获益，进而变为一个功能完善的DCB适配器。这已帮助供应商快速提供基于DCB的适配器，并已标准化为许多传统NIC供应商的通用接口。此外，在Linux用户空间中运行LLDP时，还可以在体系结构方面让基于的虚拟化解决方案获益：一方面可以查询DCB配置；另一方面可使虚拟机QoS SLA与基于硬件的DCB QoS配置保持一致。

主机中的DCB管理工具应同时适用于仅NIC的DCB适配器和CNA。为实现此目的，一种方法是将DCB体系保留在操作系统中，但减少其对netdev的依赖。DCB设备类可以是netdev设备或SCSI设备，并且应支持通过相同或类似的API来查询或实施DCB配置。这种体系结构呈现了一个可回调NIC驱动程序和HBA驱动程序的核心DCB内核库。此核心DCB内核库应该可以通过Open-LLDP使用dcbnl套接字进行管理，这样可实现内核ABI的标准化，从而能够为所有适配器管理DCB。DCB还应该与虚拟机的QoS SLA无缝集成，并提供基于硬件的无损结构和其他QoS功能，例如基于VM的带宽保证。只有当管理接口对所有供应商都公开可用时，才能实现这一目的。总之，通过为NIC和CNA构建标准的Open-LLDP、dcbtool和其他基于主机的工具，可大幅简化Linux DCB管理工作，有效减轻系统管理员的负担。对于网络、存储和虚拟服务器管理员而言，DCB技术都具有许多值得称道的功能。

文章来源于DELL官网，更多精彩内容请访问DELL官方社区或DELL解决方案专区“