1.ECU整合趋势和虚拟化的力量
随着信息娱乐和 ADAS 等新功能被添加到汽车中,每辆车中安装的 ECU 数量也在增长。越来越多的 ECU 会产生一些不良副作用:设备管理复杂、重量和功耗只是其中的一部分。
为了阻止这种趋势,汽车行业正在寻求从独立的面向功能的方法转变为集成方法,其中单个 ECU 提供多种功能。
图 1:ECU 整合旨在从单功能 ECU 方法(左)转向多功能 ECU(右)
在尝试向多功能 ECU 迁移时,会出现新的挑战:每个功能可能需要在不同的操作系统上运行,并且 CPU、内存和外围设备等硬件资源必须在它们之间共享。此外,需要确保功能之间的隔离和“不受干扰”。
幸运的是,这正是虚拟化技术帮助提供基础架构的地方,该基础架构允许多个“客户”操作系统(也称为虚拟机或 VM)以安全、独立和隔离的方式执行。
2. 汽车以太网
ECU 中实现的功能变得越来越复杂,需要灵活的互连和更高的数据传输速率。汽车以太网正在成为车载网络解决方案的首选。以太网具有巨大的未来潜力,因为它提供了带宽、轻型布线(例如非屏蔽单双绞线)、庞大的生态系统和可靠的软件基础设施。此外,交换式以太网提供了极大的可扩展性,时间敏感网络 (TSN) 扩展提供了改进的同步、低延迟和可靠性。
当多功能 ECU 使用虚拟化来运行多个操作系统时,一种常见的解决方案是处理各种 VM,就好像它们连接到同一个物理以太网网络一样。
如果只有一个以太网接口,则管理程序提供了在 VM 之间共享接口的机制,并且通常在软件中实现虚拟网络交换机。由于这种软件实现会产生开销,因此硬件制造商正在为其设备添加硬件辅助虚拟化功能,以便在无需管理程序干预的情况下实现共享。
在这篇博客中,我们描述了一个概念验证 (POC),我们在其中比较了让两个 VM 共享一个集成硬件交换机和一个软件交换机的好处。
三、硬件说明
此 POC 基于车载计算机 3 板 (VC3),配备 Renesas 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 硬件(通过后端)队列已准备好进行处理
R-Switch2 硬件直接从 domU 队列中获取数据
图 3 来自 domU 的数据包传输示例(R-Switch2 共享)
另一方面,当使用 Xen 桥接网络时,从 domU 传输帧所涉及的步骤是(参见图 4):
domU 将要传输的数据写入内存
内存与 dom0 中的后端共享
后端将数据包转发到 Xen Bridge
数据包通过 dom0 网络堆栈路由,最终到达网络接口驱动程序
驱动程序将数据包的数据复制到 NIC 队列中
网卡从内存中访问数据
图 4 来自 domU(Xen 桥接网络)的数据包传输示例
5.性能与比较
系统的性能是通过生成来自/到 domU 的恒定比特率 UDP 流并同时测量 dom0 和 domU 上的 CPU 负载来测量的。
即使网络帧是从 domU 传输/接收的,我们也测量 dom0 的 CPU 使用率的原因是,我们希望在软件中实现虚拟交换机的情况下看到更高的负载,因为 domU 数据包需要重新路由通过 dom0 的网络堆栈。
然后将此 POC 中实施的解决方案与 Xen 桥接网络进行比较,这是一种常见的软件解决方案,可实现虚拟交换机并允许在同一网络上连接多个虚拟机。
结果如图 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 的完美选择。
审核编辑:郭婷
-
cpu
+关注
关注
68文章
10855浏览量
211610 -
交换机
+关注
关注
21文章
2638浏览量
99551 -
应用程序
+关注
关注
37文章
3267浏览量
57684
发布评论请先 登录
相关推荐
评论