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 的完美選擇。

審核編輯：郭婷