ECU 整合趋势和虚拟化的力量
随着信息娱乐和 ADAS 等新功能被添加到汽车中，每辆车上安装的 ECU 数量也在增加。ECU 数量的增加带来了一些不良的副作用：设备管理复杂、重量和功耗只是其中的一部分。
为了阻止这种趋势，汽车行业正在寻求从独立的功能导向方法转向集成方法，其中单个 ECU 提供多种功能。
图 1. ECU 整合旨在从单功能 ECU 方法（左）转向多功能 ECU（右）
在尝试迁移到多功能 ECU 时，出现了新的挑战：每个功能可能需要在不同的操作系统上运行，并且必须在它们之间共享 CPU、内存和外围设备等硬件资源。此外，需要确保功能之间的隔离和“不受干扰”。
幸运的是，虚拟化技术可以提供帮助，提供一种允许多个“客户”操作系统（也称为虚拟机或 VM）以安全、独立和隔离的方式执行的基础设施。
汽车以太网
ECU 中实现的功能变得越来越复杂，需要灵活的互连和更高的数据传输速率。汽车以太网正在成为车载网络解决方案的首选。以太网具有巨大的未来潜力，因为它提供带宽、轻量级电缆（例如，非屏蔽单双绞线）、庞大的生态系统和坚实的软件基础设施。此外，交换式以太网网络提供了出色的可扩展性，而时间敏感网络 (TSN) 扩展提供了更好的同步、低延迟和可靠性。
当多功能 ECU 使用虚拟化来运行多个操作系统时，一种常见的解决方案是将各种 VM 视为连接到同一个物理以太网网络。
如果只有一个以太网接口，则虚拟机管理程序会提供在 VM 之间共享接口的机制，并且通常在软件中实现虚拟网络交换机。由于这种软件实现会产生开销，因此硬件制造商正在向其设备添加硬件辅助虚拟化功能，以便在没有虚拟机管理程序干预的情况下实现共享。
在本博客中，我们描述了一个概念验证 (POC)，其中我们比较了两个虚拟机共享集成硬件交换机与软件交换机的好处。
硬件描述
此 POC 基于车载计算机 3 板 (VC3)，配备瑞萨电子 R-Car H3 SoC 和 TSN 以太网交换机 (R-Switch2)。以太网交换机在通过 PCIe 连接到 R-Car 的 FPGA 上实现。
R-Switch2 有四个外部端口（1G-T1 连接器）和一个内部端口（称为 CPU 端口或 tsngw），暴露给 R-Car SoC 中的 CPU。R-Switch2 和 CPU 之间的接口允许在 R-Car 上运行的操作系统成为以太网帧的源或目标。
R-Switch2 和 CPU 之间的数据通过多个队列交换。每个队列都由一个描述符列表表示，这些描述符驻留在主内存中，并由在 CPU 上运行的软件设置：
RX 队列中的描述符告诉 R-Switch2 硬件，CPU 的传入以太网帧应复制到主内存中的哪个位置
TX 队列中的描述符告诉 R-Switch2 硬件，CPU 已将其希望发送的帧放在何处，以便硬件知道应从主内存中的哪个位置获取数据
对于在 CPU 上运行的虚拟机管理程序，可以将队列分配给特定的客户操作系统以进行独立的数据处理。
软件说明
对于此概念验证，选择 Xen v4.14 作为虚拟机管理程序。开发了额外的前端和后端驱动程序来共享 R-Switch2 硬件，作为典型 Xen 桥接网络的替代方案（更多信息请点击此处）。Xen 上运行着两个客户操作系统（也称为域）：
dom0：一个特权域，可直接访问大多数 R-Car 外围设备和 R-Switch
domU：一个非特权域，不能直接访问任何特定硬件设备。但是，domU 可以访问两个 R-Switch2 队列（一个 RX 队列和一个 TX 队列）
下面的图 2 显示了此配置。
图 2. 此 POC 的软件配置
前端和后端驱动程序之间的通信仅在以下情况下使用：
在初始化时，前端发送请求以保留两个 R-Switch2 队列（1 个 TX 和 1 个 RX）
在运行时，前端使用此通信通道通过后端通知 R-Switch2 硬件 TX 队列已准备好处理。后端还会使用它来在 domU 的 RX 队列中每次有新数据可用时通知前端
请注意，在设置 domU 队列所需的初始握手之后，前端驱动程序只需直接访问由 R-Switch2 硬件处理的相同队列即可传输和接收帧，而无需 dom0 端的干预。与其他虚拟机的 SW 网络解决方案相比，这是一个优势，在这些解决方案中，domU 的帧通常与后端驱动程序共享并由 dom0 中的网络堆栈重新路由。
例如，当 domU 想要通过网络传输某些帧时，使用共享 R-Switch2 解决方案所涉及的步骤如下（如图 3 所示）：
domU 将数据写入其自己的 TX 队列
domU 通知 R-Switch2 HW（通过后端）该队列已准备好进行处理
R-Switch2 HW 直接从 domU 队列获取数据
图 3. 来自 domU 的数据包传输示例（R-Switch2 共享）
另一方面，当使用 Xen Bridged Network 时，从 domU 传输帧时所涉及的步骤如下（参见图 4）：
domU 将要传输的数据写入内存
内存与 dom0 中的后端共享
后端将数据包转发到 Xen Bridge
数据包通过 dom0 网络堆栈路由，最终路由到网络接口驱动程序
驱动程序将数据包的数据复制到 NIC 队列中
NIC 访问来自内存的数据
图 4. 来自 domU（Xen Bridged Network）的数据包传输示例
性能和比较
通过生成来自/到 domU 的恒定比特率 UDP 流并同时测量 dom0 和 domU 上的 CPU 负载来测量系统的性能。
即使网络帧是从 domU 发送/接收的，我们也要测量 dom0 的 CPU 使用率，原因是我们预计在软件中实现虚拟交换机的情况下会看到更高的负载，因为 domU 数据包需要由 dom0 的网络堆栈重新路由。
然后将此 POC 中实现的解决方案与 Xen Bridged Network 进行比较，后者是一种常见的 SW 解决方案，它实现了虚拟交换机并允许多个虚拟机连接到同一网络上。
结果如图 5 和图 6 所示，证实了我们的假设。使用 R-Switch2 共享解决方案时，dom0 CPU 负载与 Xen Bridged 网络相比低约 50%，而 domU CPU 负载几乎相同。
图 5. domU 接收测试期间的 CPU 负载（恒定数据速率为 1 Gbps）
图 6. domU 发送测试期间的 CPU 负载（恒定数据速率为 600 Mbps）
R-Switch2 情况下的剩余 dom0 CPU 负载是由来自/到 domU 的事件通知引起的，即 dom0 在有新传入数据可用时通知 domU，或者 dom0 将来自 domU 的请求转发到 R-Switch2 HW 以开始处理 TX 队列。
对于像 Xen Bridge 这样的基于软件的交换机，dom0 有额外的任务来路由 domU 数据包，这可能会成为系统的瓶颈。在我们的解决方案中，domU 数据包的路由由集成网络交换机在硬件中完成，从而释放了 CPU 资源并改善了两个域之间的隔离。
结论
集成硬件交换机可以简化甚至冗余软件交换机，从而释放资源用于应用程序处理而不是日常任务。评估表明，使用硬件辅助虚拟化可节省 50% 以上的宝贵 CPU 资源。瑞萨电子 R-Switch2 对多个接收和发送队列的支持在通过虚拟化进行 ECU 整合的背景下被证明具有明显的优势。此功能与对 L2 和 L3 路由和 TSN 扩展的硬件支持相结合，使其成为实现未来 ECU 的完美选择。
