本系列的第1部分討論了影響系統(tǒng)級(jí)密碼性能的硬件和軟件變量?，F(xiàn)在，在第2部分中，我們將重點(diǎn)介紹兩種用于測(cè)量高級(jí)后備加速器性能的方法：1）驅(qū)動(dòng)器級(jí)加速器測(cè)試以識(shí)別加速器或SoC內(nèi)存帶寬約束，以及2）應(yīng)用程序/協(xié)議堆棧級(jí)測(cè)試，其中包括完整的數(shù)據(jù)包入口到出口路徑。點(diǎn)擊領(lǐng)取嵌入式物聯(lián)網(wǎng)學(xué)習(xí)路線

加速器測(cè)量方法論

測(cè)量后備加速器性能的最常見方法是駕駛員水平基準(zhǔn)。在此測(cè)試中，一組測(cè)試數(shù)據(jù)被加載到承載加速器的SoC的主存儲(chǔ)器中。

在SoC的CPU上運(yùn)行的軟件會(huì)創(chuàng)建描述符，否則會(huì)導(dǎo)致加速器對(duì)測(cè)試數(shù)據(jù)執(zhí)行加密操作。使用計(jì)時(shí)器，驅(qū)動(dòng)程序級(jí)別測(cè)試通過將處理的字節(jié)數(shù)除以花費(fèi)的時(shí)間來計(jì)算加速器的吞吐量。

盡管這看起來很簡(jiǎn)單，但是本文第1部分中描述的許多變量仍然可以影響結(jié)果。在評(píng)估（或創(chuàng)建）驅(qū)動(dòng)程序級(jí)別基準(zhǔn)時(shí)，評(píng)估者需要考慮以下事項(xiàng)：

數(shù)據(jù)大小。該測(cè)試是否加密一小塊或大塊數(shù)據(jù)？數(shù)據(jù)大小越小，加速器的內(nèi)存延遲，描述符大小和執(zhí)行操作必須獲取的其他“非數(shù)據(jù)”上下文以及計(jì)時(shí)器精度對(duì)結(jié)果的影響就越大。

了解內(nèi)存延遲和讀取上下文和數(shù)據(jù)的DMA開銷很重要，但是在測(cè)量對(duì)一小塊數(shù)據(jù)的單個(gè)操作的性能時(shí)，計(jì)時(shí)器分辨率可能是主要變量。

迭代。在較小的數(shù)據(jù)大小測(cè)量中包括加速器DMA開銷和內(nèi)存延遲，同時(shí)將計(jì)時(shí)器分辨率降低為變量的一種好方法是構(gòu)造測(cè)試，以使計(jì)時(shí)器在迭代1之前啟動(dòng)，在第n次交互之后停止，其中n相當(dāng)大數(shù)。

飛思卡爾通常使用50,000次迭代測(cè)試來測(cè)量驅(qū)動(dòng)程序級(jí)別的性能。迭代可以引入其他變量，例如緩存，預(yù)工作，中斷和檢查。

1.緩存。 測(cè)試是否使用相同的密鑰和上下文重復(fù)n次對(duì)相同的數(shù)據(jù)進(jìn)行加密？還是用n個(gè)唯一密鑰加密n個(gè)唯一的數(shù)據(jù)塊？假設(shè)加速器在SoC的緩存一致性方案內(nèi)運(yùn)行（如果沒有，請(qǐng)盡情玩！），重復(fù)加密相同的數(shù)據(jù)可能導(dǎo)致從片上緩存存儲(chǔ)器而不是主存儲(chǔ)器讀取數(shù)據(jù)。飛思卡爾的驅(qū)動(dòng)程序基準(zhǔn)測(cè)試在5萬(wàn)個(gè)唯一的數(shù)據(jù)塊上重復(fù)使用相同的密鑰，從而在單個(gè)隧道數(shù)據(jù)包處理場(chǎng)景中模仿了加速器的行為。

2.前期工作和中斷。 如果高級(jí)加速器迭代地加密50K唯一數(shù)據(jù)塊，則意味著軟件將構(gòu)建并啟動(dòng)50K唯一描述符。兩個(gè)主要變量，尤其是在小數(shù)據(jù)包大小時(shí)，是：軟件何時(shí)構(gòu)建描述符，何時(shí)將其分發(fā)給加速器？

優(yōu)化的基準(zhǔn)測(cè)試方案是讓軟件在創(chuàng)建測(cè)試數(shù)據(jù)的同時(shí)構(gòu)建所有這些描述符，然后在計(jì)時(shí)器啟動(dòng)后立即將所有描述符分派給加速器。

軟件不會(huì)通過輪詢或中斷來監(jiān)視各個(gè)描述符的完成情況。它等待來自最終描述符的中斷，并在中斷服務(wù)程序中停止計(jì)時(shí)器。

第二種方法“在描述符n完成之后構(gòu)建并分發(fā)描述符n + 1”，它更能代表實(shí)際的數(shù)據(jù)包處理方案?！傲⒓捶峙伞狈椒ㄌ峁┑臄?shù)據(jù)量較小，性能比“描述符n完成后構(gòu)建并分派描述符n + 1”大約好四倍。

與參考驅(qū)動(dòng)程序一起提供的飛思卡爾驅(qū)動(dòng)程序性能測(cè)試證明了后一種方法。這更代表了將驅(qū)動(dòng)程序集成到包處理應(yīng)用程序中。

3.檢查。 驅(qū)動(dòng)程序級(jí)別測(cè)試可能會(huì)檢查每個(gè)描述符的輸出，或者可能會(huì)假定輸出始終良好。如果測(cè)試檢查輸出，則可以在計(jì)時(shí)器運(yùn)行時(shí)進(jìn)行這些檢查，或者可以等待直到最終作業(yè)完成，然后返回并檢查預(yù)期結(jié)果。在駕駛員測(cè)試中進(jìn)行的檢查越多，結(jié)果就越少反映出加速器的原始性能。

算法或密碼套件。 數(shù)據(jù)大小和迭代方法是主要變量，但是驅(qū)動(dòng)程序基準(zhǔn)測(cè)試更多地關(guān)注真實(shí)的硬件性能，則在衡量的性能方面，越占優(yōu)勢(shì)的算法或密碼套件就變得越發(fā)重要。

一些算法，甚至是算法模式，都具有比其他算法更高的原始性能。單遍解密+消息完整性檢查可能比單遍加密+消息完整性生成更快。

下面的圖1提供了使用“在描述符n完成之后構(gòu)建和分配描述符n + 1”方法以及使用“一次性全部分配”方法的單個(gè)AES-HMAC-SHA-1基準(zhǔn)對(duì)密碼套件的比較。點(diǎn)擊領(lǐng)取嵌入式物聯(lián)網(wǎng)學(xué)習(xí)路線

圖1：驅(qū)動(dòng)程序基準(zhǔn)

圖1顯示，在較小的數(shù)據(jù)包大小下，所有“描述符n完成后構(gòu)建和分配描述符n + 1”的結(jié)果幾乎相同，因?yàn)槊枋龇麡?gòu)建，調(diào)度和監(jiān)視描述符完成的軟件開銷淹沒了算法特定的性能差異。加速器。

僅在較大的數(shù)據(jù)大小時(shí)，硬件算法性能差異才成為可觀察的變量。單個(gè)AES-HMAC-SHA-1測(cè)試（其中所有描述符都是預(yù)先構(gòu)建的，并以加速器可以接受它們的最大速率進(jìn)行分發(fā)）進(jìn)行測(cè)試，在小數(shù)據(jù)量情況下，性能提高了大約四倍。但是，通過1KB數(shù)據(jù)大小，硬件的原始性能是主要變量。

對(duì)于供應(yīng)商提供的基準(zhǔn)代碼的用戶來說，在將結(jié)果與另一供應(yīng)商的基準(zhǔn)代碼進(jìn)行比較之前，了解基準(zhǔn)代碼的確切功能非常重要。

在更現(xiàn)實(shí)的用例中，不同的供應(yīng)商可能具有不同的理念來顯示幾乎原始的加速器性能與加速器性能。

SoC測(cè)量方法

加速器基準(zhǔn)測(cè)試強(qiáng)調(diào)加速器的性能及其通往系統(tǒng)內(nèi)存的路徑。SoC基準(zhǔn)測(cè)試強(qiáng)調(diào)處理路徑中所有元素的性能，包括網(wǎng)絡(luò)接口，CPU，加速器和內(nèi)存子系統(tǒng)。對(duì)于諸如PowerQUICC系列中的面向網(wǎng)絡(luò)的SoC，重要的加密基準(zhǔn)是IPsec數(shù)據(jù)包處理。

本文的第1部分描述了加密算法與完整安全協(xié)議（例如IPsec）之間的區(qū)別，以及軟件變量（例如IPsec協(xié)議棧效率）和利用硬件加速的API的質(zhì)量。

本節(jié)介紹了用于在同一設(shè)備上創(chuàng)建不同IPsec堆棧的規(guī)范化比較以及在不同設(shè)備上創(chuàng)建同一IPsec堆棧的比較的方法。

網(wǎng)絡(luò)測(cè)試環(huán)境

RFC2544“網(wǎng)絡(luò)互連設(shè)備的基準(zhǔn)測(cè)試方法”描述了一系列用于網(wǎng)絡(luò)系統(tǒng)標(biāo)準(zhǔn)化測(cè)試的方法。盡管RFC沒有專門討論IPsec，但它引入了許多重要的測(cè)試概念。

測(cè)試系統(tǒng)IPsec性能的最合乎邏輯的方法-被測(cè)設(shè)備（DUT）-可以將其連接到網(wǎng)絡(luò)測(cè)試儀，如下圖2所示。巧合的是，這種情況也是下面的RFC2544中的圖2。

圖2：IPsec測(cè)試選項(xiàng)1點(diǎn)擊領(lǐng)取嵌入式物聯(lián)網(wǎng)學(xué)習(xí)路線

使用此選項(xiàng)，測(cè)試儀將生成IPsec數(shù)據(jù)包，并將其發(fā)送到DUT，然后由DUT解密并將其發(fā)送回去。該過程也可以反向運(yùn)行，以便也可以測(cè)量DUT在加密過程中的性能。

盡管這可能是衡量DUT的IPsec性能的最合乎邏輯的方法，但是由于支持高IPsec數(shù)據(jù)速率的網(wǎng)絡(luò)測(cè)試儀的成本，這種設(shè)置很少使用。

盡管這種情況將來可能會(huì)改變，但具有加密加速功能的高級(jí)網(wǎng)絡(luò)SoC通常具有比聲稱要測(cè)量它們的網(wǎng)絡(luò)測(cè)試設(shè)備更高的IPsec性能。下面的圖3（在RFC2544中也是圖3）顯示了測(cè)試IPsec的更好選擇。

圖3：IPsec測(cè)試選項(xiàng)2

在選項(xiàng)2中，在網(wǎng)關(guān)到網(wǎng)關(guān)配置中測(cè)試了IPsec。

1.網(wǎng)絡(luò)測(cè)試儀將明文IP數(shù)據(jù)包從端口1傳輸?shù)紻UT 1（標(biāo)記為Home）。

2. DUT 1 IPsec對(duì)數(shù)據(jù)包進(jìn)行加密，然后將其發(fā)送到DUT 2（標(biāo)記為Office）。3. DUT 2解密數(shù)據(jù)包，然后

4.將其轉(zhuǎn)發(fā)回網(wǎng)絡(luò)測(cè)試的端口2，從而使測(cè)試儀能夠測(cè)量收到的數(shù)據(jù)包速率。

此過程可以雙向運(yùn)行，以便網(wǎng)絡(luò)測(cè)試器的每個(gè)端口發(fā)送和接收明文數(shù)據(jù)包，如前面的圖2所示。許多網(wǎng)絡(luò)測(cè)試人員能夠生成高速率的純文本IP流量，從而使更多的用戶可以重新創(chuàng)建使用此方法測(cè)得的基準(zhǔn)。

由于所有數(shù)據(jù)包均已加密和解密，因此IPsec性能被報(bào)告為這兩個(gè)操作中較慢的。還應(yīng)注意，性能是根據(jù)明文數(shù)據(jù)包衡量的。

根據(jù)數(shù)據(jù)包大小，兩個(gè)DUT之間的加密隧道內(nèi)部測(cè)得的Mbps可能是網(wǎng)絡(luò)測(cè)試儀報(bào)告的Mbps的近兩倍。隧道內(nèi)部數(shù)據(jù)包大小的增加還導(dǎo)致DUT之間的1 Gbps以太網(wǎng)鏈路以大約950 Mbps的速度飽和，而不是非加密以太網(wǎng)鏈路的大約990 Mbps。

IPsec測(cè)試的變化源

使用測(cè)量選項(xiàng)2，涵蓋影響IPsec基準(zhǔn)的所有潛在變量超出了這兩個(gè)部分的范圍。但是，有兩個(gè)值得一提的相關(guān)測(cè)試選項(xiàng)：注入速率和可接受的丟失率。

注入速率是網(wǎng)絡(luò)測(cè)試儀向DUT發(fā)送明文數(shù)據(jù)包的速率?？梢詫y(cè)試儀配置為淹沒DUT（對(duì)于所有數(shù)據(jù)包大小，均以100％的線速傳輸），或者緩慢啟動(dòng)并逐漸增加注入速率，直到DUT開始丟棄數(shù)據(jù)包。

泛洪測(cè)試通常會(huì)產(chǎn)生比零丟失更好的IPsec基準(zhǔn)，但是泛洪基準(zhǔn)對(duì)用戶的用處不大，因?yàn)榇蠖鄶?shù)系統(tǒng)旨在實(shí)現(xiàn)給定的性能目標(biāo)而不會(huì)丟棄大量數(shù)據(jù)包。那些零損失小包在地板上嗎？

RFC2544沒有可接受的丟失率的概念。零丟失測(cè)試意味著性能由DUT在一定時(shí)間間隔（通常為30-60秒）內(nèi)轉(zhuǎn)發(fā)數(shù)據(jù)包而不丟失任何數(shù)據(jù)包的速率定義。網(wǎng)絡(luò)設(shè)備供應(yīng)商在測(cè)試其最終系統(tǒng)時(shí)通常會(huì)忽略RFC2544的這一部分。

眾所周知，獨(dú)立的測(cè)試實(shí)驗(yàn)室（例如Tolly Group）使用可接受的丟包率<.001％來測(cè)量IPsec“零丟失”性能。=“” both =“” equipment =“”和=“” Embedded = “”處理器=“”供應(yīng)商=“” have =“” =“ =” seen =“” to =“” report =“” loss =“”匯率=“” as =“” high =“” as =“” .1 =“” percent =“” as =“” zero =“” loss。=“”>

可接受的損失率對(duì)性能有重大影響。飛思卡爾報(bào)告了使用絕對(duì)零損耗和<.001％，=“” with =“” the =“”> <。001％=“” results =“”通常=“” 25 =“”的零損失IPsec結(jié)果。 percent =“” better =“”勝于=“” the =“”絕對(duì)=“”零=“”結(jié)果。=“”>

較高的可接受損失率會(huì)進(jìn)一步改善結(jié)果。因?yàn)閷?duì)于報(bào)告為零損失的基準(zhǔn)，沒有公認(rèn)的可接受的損失率定義，因此在比較兩個(gè)供應(yīng)商提供的基準(zhǔn)之前，準(zhǔn)買家需要做一些額外的作業(yè)。

特定結(jié)果

現(xiàn)在，我們已經(jīng)定義了變體和測(cè)試方法的硬件和軟件來源，以幫助產(chǎn)生標(biāo)準(zhǔn)化的結(jié)果，本文現(xiàn)在著眼于飛思卡爾PowerQUICC處理器上的特定IPsec測(cè)量，以及這些結(jié)果如何說明前面討論的一些概念。

如本系列該部分中的PowerQUICC性能圖所示，系統(tǒng)性能受到CPU（對(duì)于小數(shù)據(jù)包）和Freescale集成安全引擎（SEC）對(duì)大數(shù)據(jù)包的限制，而內(nèi)存總線性能同樣會(huì)影響所有數(shù)據(jù)包大小的吞吐量。

競(jìng)爭(zhēng)對(duì)手產(chǎn)品的公開性能曲線表明，它們的設(shè)備具有相同的基本原理，而PowerQUICC的出色I(xiàn)Psec性能（尤其是與優(yōu)化的IPsec堆棧（如Mocana的NanoSec）搭配使用）是由更高性能的CPU組合而成的，效率更高單通加密加速核心以及更寬，更快，有效的流水線總線。

所有性能圖均使用Smartbits SMB600作為數(shù)據(jù)包生成器和數(shù)據(jù)包計(jì)數(shù)器進(jìn)行測(cè)量。Smartbits Terametrics模塊以最大速率生成純凈的IPv4數(shù)據(jù)包，并將其傳輸?shù)絇owerQUICC板1的以太網(wǎng)端口之一。

PowerQUICC板1將數(shù)據(jù)包歸類為IPsec會(huì)話，并使用3DES-HMAC-SHA-1執(zhí)行ESP隧道封裝，然后再將其轉(zhuǎn)發(fā)到PowerQUICC板2的以太網(wǎng)端口之一。

PowerQUICC板2將數(shù)據(jù)包分類為屬于要在板2上終止的IPsec ESP會(huì)話，并在將清除的IPv4數(shù)據(jù)包轉(zhuǎn)發(fā)回Smartbits機(jī)器之前對(duì)數(shù)據(jù)包進(jìn)行解封裝/解密。

除非另有說明，否則所有顯示的性能數(shù)字均反映每個(gè)PowerQUICC設(shè)備的合計(jì)雙向IPsec數(shù)據(jù)包轉(zhuǎn)發(fā)速率。選擇3DES-HMAC-SHA-1作為此測(cè)量的密碼套件，因?yàn)樗匀皇亲畛Ｓ玫腎Psec密碼套件。

對(duì)于SEC和其他加密加速器而言，這也是最壞情況的算法組合。在PowerQUICC中，除了最大的數(shù)據(jù)包外，3DES-HMAC-SHA-1和AES-HMAC-SHA-1之間的系統(tǒng)級(jí)性能差異可以忽略不計(jì)。

PowerQUICC II Pro平臺(tái)上的基準(zhǔn)測(cè)試

PowerQUICC II Pro MPC83xx系列集成通信處理器代表PowerQUICC產(chǎn)品線的低端產(chǎn)品。這些設(shè)備使用頻率高達(dá)667 MHz的e300 Power Architecture處理器內(nèi)核。

MPC83xx系列的某些成員使用SEC內(nèi)核的簡(jiǎn)化功能版本（加速3DES，AES，HMAC MD5和SHA-1）；其他的則具有功能齊全的SEC，它們還可以加速公鑰，ARC-4和隨機(jī)數(shù)的生成。

測(cè)量配置1。 下方的圖4中顯示的是第一個(gè)配置，其中包含MPC8313E PowerQUICC II Pro集成通信處理器，32位e300 Power Architecture內(nèi)核，SEC 2.2和以下配置參數(shù)：

MPC8313E RDB

e300內(nèi)核（333 MHz），DDR（333 MHz數(shù)據(jù)速率）和SEC（166 MHz）

OS：Linux 2.6.21

IPsec堆棧：StrongSwan，OpenSwan，Mocana NanoSec，均運(yùn)行3DES-HMAC-SHA-1

該圖表顯示Mocana NanoSec IPsec堆棧（//mocana.com/NanoSec.html）在所有數(shù)據(jù)包大小下均具有更高的吞吐量。Mocana相對(duì)于OpenSwan的性能優(yōu)勢(shì)相對(duì)穩(wěn)定，為1.7倍，而StrongSwan的優(yōu)勢(shì)始于1.6倍，但隨著數(shù)據(jù)包大小的增加而增長(zhǎng)至2.2倍。

OpenSwan和Mocana均異步運(yùn)行，而StrongSwan一次處理一個(gè)數(shù)據(jù)包，并等待SEC完成處理后再繼續(xù)。在較小的數(shù)據(jù)包大小時(shí)，StrongSwan的效率更高，并且由于輪詢操作而避免了SEC中斷，因此它的性能略優(yōu)于OpenSwan，但在中等數(shù)據(jù)包大小時(shí)，OpenSwan會(huì)超過StrongSwan。

圖4. MPC8313E IPsec性能點(diǎn)擊領(lǐng)取嵌入式物聯(lián)網(wǎng)學(xué)習(xí)路線

測(cè)量配置＃2 。下面的圖5顯示了一個(gè)包含MPC8323E的測(cè)量配置平臺(tái)的安全性能，該平臺(tái)基于32位e300 Power Architecture內(nèi)核和SEC 2.2，具有以下參數(shù)：

MPC8323E RDB

e300內(nèi)核（333 MHz），DDR（266 MHz數(shù)據(jù)速率）和SEC（133 MHz）

OS：Linux 2.6.20.6

IPsec堆棧：NetKey，StrongSwan，OpenSwan，Mocana NanoSec，均運(yùn)行3DES-HMAC-SHA-1

圖5. MPC8323E IPsec性能

該圖完整比較了最流行的開源IPsec堆棧和在同一Linux內(nèi)核版本上運(yùn)行的Mocana堆棧。比較中包括具有硬件和軟件加密功能的Netkey性能。

與配置1中的MPC8313E一樣，在所有數(shù)據(jù)包大小下，Mocana NanoSec IPsec堆棧都具有最高的吞吐量。同樣，在最小的數(shù)據(jù)包大小下，StrongSwan略勝于OpenSwan，但隨后落后于SEC的同步API阻止了處理器執(zhí)行其他工作。

在中小型數(shù)據(jù)包大小上，與OpenSwan相比，Mocana的優(yōu)勢(shì)約為1.9倍。但是，在較大的數(shù)據(jù)包大小下，Mocana達(dá)到了200 Mbps的鏈路限制（使用兩個(gè)10/100快速以太網(wǎng)接口進(jìn)行雙向測(cè)試），從而使OpenSwan看起來可以縮小差距。

在執(zhí)行軟件加密時(shí)，NetKey比OpenSwan效率更高。但是，Native Linux Crypto API與SEC的雙通道，同步接口產(chǎn)生了如此高的開銷，以至于具有硬件加速功能的NetKey比其他堆棧慢，甚至比具有較小數(shù)據(jù)包大小的具有軟件加密的NetKey還要慢。

測(cè)量配置＃3 。下圖6所示為包含具有32位e300 Power Architecture內(nèi)核的MPC8349A和SEC 2.4以及以下參數(shù)的配置的安全性測(cè)量性能：

MPC8349EA MDS

e300內(nèi)核（666 MHz），DDR（333 MHz數(shù)據(jù)速率）和SEC（166 MHz）

OS：Linux 2.6.11

IPsec堆棧：StrongSwan，OpenSwan，Mocana，均運(yùn)行3DES-HMAC-SHA-1

該圖表將StrongSwan和OpenSwan與Mocana進(jìn)行了比較。Mocana在所有數(shù)據(jù)包大小下均提供最高的吞吐量。與第二好的實(shí)施方案（在這種情況下為OpenSwan）相比，Mocana的性能優(yōu)勢(shì)約為1.3倍。

圖6. MPC8349EA IPsec性能

測(cè)量配置＃4 。下面的圖7中顯示了MPC8360E的安全性能，其中包含32位e300 Power Architecture內(nèi)核和SEC 2.4。這些是參數(shù)：

MPC8360EA MDS

e300內(nèi)核（666 MHz），DDR（333 MHz數(shù)據(jù)速率），QUICC Engine（500 MHz）和SEC（166 MHz）

OS：Linux 2.6.22

IPsec堆棧：StrongSwan（單向），Mocana（雙向）運(yùn)行3DES-HMAC-SHA-1

該圖表將StrongSwan與Mocana進(jìn)行了比較，并提供了CPU利用率信息。對(duì)于此特定設(shè)備，StrongSwan在最小的數(shù)據(jù)包大小上略勝于Mocana。這可能是由于測(cè)量差異（單向測(cè)試與雙向測(cè)試）引起的。

對(duì)于IPv4轉(zhuǎn)發(fā)，在64字節(jié)時(shí)的單向性能為142 Mbps與114 Mbps。這表明，如果雙向測(cè)量StrongSwan IPsec性能，則Mocana的性能將優(yōu)于StrongSwan，這與其他設(shè)備上的測(cè)量結(jié)果一致。

另一個(gè)不尋常的數(shù)據(jù)點(diǎn)是Mocana CPU利用率為1456字節(jié)。CPU利用率應(yīng)該繼續(xù)下降。CPU利用率是計(jì)算得出的數(shù)字，并且CRC或其他以太網(wǎng)錯(cuò)誤可能超過.001％，從而降低了測(cè)量的吞吐量。由于在處理IPsec之后丟棄了以太網(wǎng)幀，因此CPU似乎比實(shí)際完成了更多的工作。

圖7. MPC8360E IPsec性能

測(cè)量配置＃5 。下面的圖8中顯示了MPC8379E PowerQUICC II Pro集成通信處理器的安全性能，該處理器包含32位e300 Power Architecture內(nèi)核和SEC 3.0。這些是參數(shù)：

MPC8379E RDB

e300內(nèi)核為666 MHz，DDR為333 MHz數(shù)據(jù)速率，SEC為110?? MHz

操作系統(tǒng)：Linux 2.6.23

IPsec堆棧：OpenSwan，Mocana，均運(yùn)行3DES-HMAC-SHA-1

該圖表顯示Mocana NanoSec IPsec堆棧在所有數(shù)據(jù)包大小下均具有更高的吞吐量。Mocana在OpenBwan上的性能優(yōu)勢(shì)約為64B時(shí)的1.4倍。在SEC開始成為性能限制器之前，此增量相對(duì)恒定，此時(shí)OCF彌補(bǔ)了這一差距。

圖8. MPC8379E IPsec性能點(diǎn)擊領(lǐng)取嵌入式物聯(lián)網(wǎng)學(xué)習(xí)路線

請(qǐng)注意，為了對(duì)OpenSwan和Mocana進(jìn)行真正的“蘋果到蘋果”比較，使用了MPC8379RDB板，該板目前將SEC頻率限制為110 MHz（與大多數(shù)其他83xx產(chǎn)品的166 MHz相比）。

在沒有SEC頻率限制的情況下，在另一塊板上測(cè)量的OpenSwan數(shù)據(jù)顯示，在所有數(shù)據(jù)包大小中，MPC8379E IPsec性能比圖中結(jié)果提高了約13％，在大數(shù)據(jù)包大小時(shí)達(dá)到了約560 Mbps。可以合理地假設(shè)，如果SEC以166 MHz運(yùn)行，那么在所有數(shù)據(jù)包大小下Mocana的結(jié)果也會(huì)好13％。

使用PowerQUICC III MBC 85xx系列進(jìn)行

測(cè)量PowerQUICC III MPC85xx系列集成通信處理器代表PowerQUICC產(chǎn)品線的中高端。這些設(shè)備使用帶有前端L2緩存的e500 Power Architecture處理器內(nèi)核。e500內(nèi)核的工作頻率高達(dá)1.5 GHz。MPC85xx系列的所有成員都使用功能齊全的SEC。

測(cè)量配置1。 下面的圖9中顯示了MPC8544E和MPC8533E PowerQUICC III集成通信處理器的安全性能，這些處理器包含32位e500 Power Architecture內(nèi)核和SEC 2.1。這些是參數(shù)：

MPC8544E CDS

e500內(nèi)核為800 MHz，DDR為400 MHz數(shù)據(jù)速率，SEC為133 MHz

OS：Linux 2.6.23

IPsec堆棧：Mocana，運(yùn)行3DES-HMAC-SHA-1

可用于MPC8544E的唯一IPsec結(jié)果來自Mocana，用于其商業(yè)NanoSec IPsec實(shí)現(xiàn)。請(qǐng)注意，MPC8544E中SEC的運(yùn)行頻率（相對(duì)于CPU）要低于其他85xx器件，因此，由于SEC飽和而導(dǎo)致的CPU利用率的降低要比其他器件更早開始。

圖9. MPC8544E IPsec性能

測(cè)量配置2。 下面的圖10顯示了MPC8555E和MPC8541E PowerQUICC III集成通信處理器的安全性能，這些處理器包含32位e500 Power Architecture內(nèi)核和SEC 2.0。這些是參數(shù)：

MPC8555E CDS

e500內(nèi)核（833 MHz），DDR（333 MHz數(shù)據(jù)速率）和SEC（166 MHz）

OS：StrongSwan Linux 2.4，Mocana Linux 2.6.11

IPsec堆棧：StrongSwan，Mocana，均運(yùn)行3DES-HMAC-SHA-1

該圖表將StrongSwan與Mocana進(jìn)行了比較，并提供了CPU利用率信息。對(duì)于此特定設(shè)備，Mocana NanoSec在所有數(shù)據(jù)包大小方面均優(yōu)于StrongSwan。Mocana CPU利用率隨著數(shù)據(jù)包大小的增加而穩(wěn)步下降，而StrongSwan由于其同步的輪詢操作模式而在所有數(shù)據(jù)包大小下都消耗了100％的CPU。

圖10. MPC8555E IPsec性能

測(cè)量配置＃3。 下面的圖11顯示了MPC8548E PowerQUICC III集成通信處理器的安全性能，該處理器包含32位e500 Power Architecture內(nèi)核和SEC 2.1。這些是參數(shù)：

MPC8548E CDS

e500內(nèi)核為1.33 GHz，DDR為533 MHz數(shù)據(jù)速率，SEC 2.1為266 MHz

OS：Linux 2.6.11

IPsec堆棧：Mocana，運(yùn)行3DES-HMAC-SHA-1

該圖表將OpenSwan與Mocana進(jìn)行了比較，并添加了有關(guān)CPU利用率的信息。Mocana NanoSec在所有數(shù)據(jù)包大小下均提供最高的吞吐量，并開始以390字節(jié)的速度使SEC飽和。

隨著數(shù)據(jù)包大小的增加，CPU利用率繼續(xù)下降，并且在1456字節(jié)時(shí)，Mocana達(dá)到1057 Mbps，CPU利用率為38％。OpenSwan具有類似的配置文件；但是，它直到1024字節(jié)才使SEC飽和，并消耗了69％的CPU，同時(shí)在1456字節(jié)下達(dá)到了1057 Gbps。

圖11. MPC8548E IPsec性能

結(jié)束語(yǔ)

如本文中描述的示例配置所示，嵌入式通信處理器的安全性能在很大程度上取決于中小數(shù)據(jù)包大小的CPU的性能，而對(duì)于大數(shù)據(jù)包大小的加密硬件/內(nèi)存總線的限制更大。

雖然此處通過各種PowerQUICC處理器家族成員的性能曲線說明了這一點(diǎn)，但對(duì)于使用通用CPU和后備加密加速功能的所有嵌入式通信處理器而言，都是如此。

使用更多類似NPU的處理引擎可以實(shí)現(xiàn)更高的性能；但是，這樣做通常會(huì)導(dǎo)致靈活性降低，無(wú)論是絕對(duì)可編程性還是工具鏈支持。