1.ECU整合趨勢和虛擬化的力量

隨著信息娛樂和 ADAS 等新功能被添加到汽車中，每輛車中安裝的 ECU 數(shù)量也在增長。越來越多的 ECU 會產(chǎn)生一些不良副作用：設(shè)備管理復(fù)雜、重量和功耗只是其中的一部分。

為了阻止這種趨勢，汽車行業(yè)正在尋求從獨立的面向功能的方法轉(zhuǎn)變?yōu)榧煞椒?，其中單個 ECU 提供多種功能。

圖 1：ECU 整合旨在從單功能 ECU 方法（左）轉(zhuǎn)向多功能 ECU（右）

在嘗試向多功能 ECU 遷移時，會出現(xiàn)新的挑戰(zhàn)：每個功能可能需要在不同的操作系統(tǒng)上運行，并且 CPU、內(nèi)存和外圍設(shè)備等硬件資源必須在它們之間共享。此外，需要確保功能之間的隔離和“不受干擾”。

幸運的是，這正是虛擬化技術(shù)幫助提供基礎(chǔ)架構(gòu)的地方，該基礎(chǔ)架構(gòu)允許多個“客戶”操作系統(tǒng)（也稱為虛擬機或 VM）以安全、獨立和隔離的方式執(zhí)行。

2. 汽車以太網(wǎng)

ECU 中實現(xiàn)的功能變得越來越復(fù)雜，需要靈活的互連和更高的數(shù)據(jù)傳輸速率。汽車以太網(wǎng)正在成為車載網(wǎng)絡(luò)解決方案的首選。以太網(wǎng)具有巨大的未來潛力，因為它提供了帶寬、輕型布線（例如非屏蔽單雙絞線）、龐大的生態(tài)系統(tǒng)和可靠的軟件基礎(chǔ)設(shè)施。此外，交換式以太網(wǎng)提供了極大的可擴展性，時間敏感網(wǎng)絡(luò) （TSN） 擴展提供了改進的同步、低延遲和可靠性。

當多功能 ECU 使用虛擬化來運行多個操作系統(tǒng)時，一種常見的解決方案是處理各種 VM，就好像它們連接到同一個物理以太網(wǎng)網(wǎng)絡(luò)一樣。

如果只有一個以太網(wǎng)接口，則管理程序提供了在 VM 之間共享接口的機制，并且通常在軟件中實現(xiàn)虛擬網(wǎng)絡(luò)交換機。由于這種軟件實現(xiàn)會產(chǎn)生開銷，因此硬件制造商正在為其設(shè)備添加硬件輔助虛擬化功能，以便在無需管理程序干預(yù)的情況下實現(xiàn)共享。

在這篇博客中，我們描述了一個概念驗證 （POC），我們在其中比較了讓兩個 VM 共享一個集成硬件交換機和一個軟件交換機的好處。

三、硬件說明

此 POC 基于車載計算機 3 板 （VC3），配備 Renesas R-Car H3 SoC 和 TSN 以太網(wǎng)交換機 （R-Switch2）。以太網(wǎng)交換機在通過 PCIe 連接到 R-Car 的 FPGA 上實現(xiàn)。

R-Switch2 有四個外部端口（1G-T1 連接器）和一個內(nèi)部端口（命名為 CPU 端口或 tsngw）暴露給 R-Car SoC 中的 CPU。R-Switch2 和 CPU 之間的接口允許在 R-Car 上運行的操作系統(tǒng)成為以太網(wǎng)幀的來源或目的地。

R-Switch2 和 CPU 之間的數(shù)據(jù)通過多個隊列進行交換。每個隊列由一個描述符列表表示，這些描述符駐留在主內(nèi)存中，由運行在 CPU 上的軟件設(shè)置：

RX 隊列中的描述符告訴 R-Switch2 硬件應(yīng)將 CPU 的傳入以太網(wǎng)幀復(fù)制到主存儲器的哪個位置

TX 隊列中的描述符告訴 R-Switch2 硬件 CPU 將其希望發(fā)送的幀放置在何處，以便硬件知道應(yīng)該從主存儲器中的哪個位置獲取數(shù)據(jù)

如果在 CPU 上運行管理程序，則可以將隊列分配給特定的客戶操作系統(tǒng)以進行獨立的數(shù)據(jù)處理。

四、軟件說明

對于這個概念證明，選擇 Xen v4.14 作為管理程序。開發(fā)了額外的前端和后端驅(qū)動程序來共享 R-Switch2 硬件，作為典型 Xen 橋接網(wǎng)絡(luò)的替代方案（更多信息在這里）。Xen（也稱為域）上運行著兩個客戶操作系統(tǒng)：

dom0：一個特權(quán)域，可以直接訪問大多數(shù) R-Car 外圍設(shè)備和 R-Switch

domU：無特權(quán)的域，不能直接訪問任何特定的硬件設(shè)備。但是，domU 可以訪問兩個 R-Switch2 隊列（一個 RX 和一個 TX）

下面的圖 2 顯示了這種配置。

圖 2 此 POC 的軟件配置

前端和后端驅(qū)動程序之間的通信僅用于以下情況：

在初始化時，前端發(fā)送請求以保留兩個 R-Switch2 隊列（1 TX 和 1 RX）

在運行時，前端使用此通信通道通過后端通知 R-Switch2 硬件 TX 隊列已準備好進行處理。每當 domU 的 RX 隊列中有新數(shù)據(jù)可用時，后端也使用它來通知前端

請注意，在為 domU 設(shè)置隊列所需的初始握手之后，前端驅(qū)動程序只需直接訪問由 R-Switch2 硬件處理的相同隊列即可傳輸和接收幀，而來自 dom0 端的干預(yù)最少。與其他用于虛擬機的 SW 網(wǎng)絡(luò)解決方案相比，這是一個優(yōu)勢，其中 domU 的幀通常與后端驅(qū)動程序共享，并由 dom0 中的網(wǎng)絡(luò)堆棧重新路由。

例如，當 domU 想要通過網(wǎng)絡(luò)傳輸一些幀時，使用共享 R-Switch2 解決方案所涉及的步驟如下（如圖 3 所示）：

domU 將數(shù)據(jù)寫入自己的 TX 隊列

domU 通知 R-Switch2 硬件（通過后端）隊列已準備好進行處理

R-Switch2 硬件直接從 domU 隊列中獲取數(shù)據(jù)

圖 3 來自 domU 的數(shù)據(jù)包傳輸示例（R-Switch2 共享）

另一方面，當使用 Xen 橋接網(wǎng)絡(luò)時，從 domU 傳輸幀所涉及的步驟是（參見圖 4）：

domU 將要傳輸?shù)臄?shù)據(jù)寫入內(nèi)存

內(nèi)存與 dom0 中的后端共享

后端將數(shù)據(jù)包轉(zhuǎn)發(fā)到 Xen Bridge

數(shù)據(jù)包通過 dom0 網(wǎng)絡(luò)堆棧路由，最終到達網(wǎng)絡(luò)接口驅(qū)動程序

驅(qū)動程序?qū)?shù)據(jù)包的數(shù)據(jù)復(fù)制到 NIC 隊列中

網(wǎng)卡從內(nèi)存中訪問數(shù)據(jù)

圖 4 來自 domU（Xen 橋接網(wǎng)絡(luò)）的數(shù)據(jù)包傳輸示例

5.性能與比較

系統(tǒng)的性能是通過生成來自/到 domU 的恒定比特率 UDP 流并同時測量 dom0 和 domU 上的 CPU 負載來測量的。

即使網(wǎng)絡(luò)幀是從 domU 傳輸/接收的，我們也測量 dom0 的 CPU 使用率的原因是，我們希望在軟件中實現(xiàn)虛擬交換機的情況下看到更高的負載，因為 domU 數(shù)據(jù)包需要重新路由通過 dom0 的網(wǎng)絡(luò)堆棧。

然后將此 POC 中實施的解決方案與 Xen 橋接網(wǎng)絡(luò)進行比較，這是一種常見的軟件解決方案，可實現(xiàn)虛擬交換機并允許在同一網(wǎng)絡(luò)上連接多個虛擬機。

結(jié)果如圖 5 和圖 6 所示，證實了我們的假設(shè)。使用 R-Switch2 共享方案時，dom0 CPU 負載比 Xen Bridged 網(wǎng)絡(luò)低約 50%，而 domU CPU 負載幾乎相同。

圖 5 domU 接收測試期間的 CPU 負載（1 Gbps 的恒定數(shù)據(jù)速率）

圖 6 domU 傳輸測試期間的 CPU 負載（600 Mbps 的恒定數(shù)據(jù)速率）

R-Switch2 情況下的剩余 dom0 CPU 負載是由來自/到 domU 的事件通知引起的，即當有新的傳入數(shù)據(jù)可用時，dom0 通知 domU，或者 dom0 將來自 domU 的請求轉(zhuǎn)發(fā)給 R-Switch2 HW 以開始處理 TX隊列。

對于像 Xen Bridge 這樣的基于軟件的交換機，dom0 有額外的任務(wù)來路由 domU 數(shù)據(jù)包，這可能成為系統(tǒng)的瓶頸。在我們的解決方案中，domU 數(shù)據(jù)包的路由由集成網(wǎng)絡(luò)交換機在硬件中完成，從而釋放 CPU 資源并提高兩個域之間的隔離度。

六，結(jié)論

集成的硬件交換機可以簡化軟件交換機甚至是冗余的，從而為應(yīng)用程序處理而不是內(nèi)務(wù)管理任務(wù)釋放資源。評估表明，使用硬件輔助虛擬化可節(jié)省超過 50% 的寶貴 CPU 資源。事實證明，瑞薩 R-Switch2 支持多個接收和傳輸隊列在通過虛擬化整合 ECU 的環(huán)境中具有明顯優(yōu)勢。此功能與對 L2 和 L3 路由和 TSN 擴展的硬件支持一起，使其成為實現(xiàn)未來 ECU 的完美選擇。

審核編輯：郭婷