3 處理器卸載

　　所支持的隊列卸載水平與實現有關。例如，有些SoC可能提供鎖定機制，但并不管理隊列的全部狀態。理想情況下，開發人員想要一個支持不同配置的靈活系統，能直接與軟件整合，并盡可能減少為適應SoC而做的軟件修改。一個虛擬化機制可能很有效；但是，如果要與傳統編程模型有大的變化，則移植應用代碼會增加系統成本，延遲上市時間。

　　實現隊列的方式也會影響到系統的性能。例如，隊列的位置影響著哪些處理器可以訪問這些隊列。有些隊列必須以內存類型存在，在整個芯片上分布，或者被捆綁到某個資源上。動態分配的隊列使開發人員擁有某種靈活性，能恰當地將隊列劃分給應用和資源。對于采用多只多核SoC的系統，如擁有通過一個系統總線（如PCIe）管理隊列的能力，則資源的共享不僅能在同一SoC的不同核心之間，而且能在不同SoC之間。例如，一個處理簇可以共享單個轉發數據庫。另外，一個多SoC系統可能擁有一個單一的深層數據包檢查引擎，而運行在不同SoC上的應用必須訪問該引擎。這種多芯片的資源共享能夠實現更進一步的系統資源虛擬化。

　　多芯片架構中最大的設計挑戰之一是用某種方式的分區工作，以將資源需求平均地分配給所有處理器。在基于軟件的虛擬化中，這個過程可能非常耗時，為設計人員增加了負擔，包括高效管理空閑內存池的挑戰。另外，軟件的任何修改都可能為資源需求帶來變化，這就需要開發人員重新劃分系統分區。非對稱和對稱多處理器架構都有很多這類問題。

　　采用基于硬件的虛擬化時，大多數分區管理任務放在硬件上，而操作系統則處理少量剩余任務。由于采用這種抽象分區，開發人員于做系統修改時，無需對系統做手工的重新分區。這種方案亦卸載了應用與操作系統的一些任務，如管理空閑的內存池。

　　4 帶寬保證

　　對一個資源的控制亦擴展了一只處理器可以接受的最大分配限度，解決了接收端的處理瓶頸問題。例如，對于很多通信、音視頻、數據采集以及測試與測量應用，接收處理器都有預期或可以處理的最大傳輸數據速率。在這些情況下，即使外設擁有更多的能力（因為其它處理器當前未使用它們的分配額），應用也不希望隊列以更快的速率刷新，因為這種刷新可能超出接收處理器的能力，造成數據損失。

　　很多開發人員在設計時會采用最差情況方法；他們要確認有足夠的容量支持最差情況的負載。但是，在典型工作條件下，這種方法無法用到全部的資源容量。例如，一個典型的輪轉仲裁算法僅支持最低的配額。如果系統對某個資源有多達10個請求方，則每個請求方總是可以期望擁有至少10%的帶寬。然而，如果僅有一個請求方活動，則該請求方可以獲得100%的帶寬。

　　虛擬與透明的資源分配方法意味著一個應用并不知道自己可能獲得多少帶寬。對于接收端存在瓶頸的應用，為某個資源設定最大配額的能力對系統的穩定非常重要。這個最大值使開發人員能夠控制每個應用的資源帶寬（無論采用了何種分配算法），以防止淹沒接收端的處理器，并且防止了數據損失。開發人員還擁有用標準機制去管理擁塞的選擇，如IEEE 802.1Qav或802.1Qau。

　　5 系統穩定性

　　一個應用有時可能會嘗試使用某個并不具備訪問權的資源。程序中的錯誤可能造成這種情況的出現，此時只有部分刷新的應用在使用中，或者當代碼或數據內存出現被覆蓋情況時。必須防止一個應用干擾到其它應用，即：寫入到其它應用的內存空間；或對性能產生負面影響，例如，獲取對某個共享資源的控制。在基于軟件的資源共享實現中，一個損壞的應用可能忽視自己的帶寬配額，而去獨占一個共享資源。同樣，如果掌控虛擬化的處理器損壞，則隊列機制就會失效，使整個系統宕機。

　　基于硬件的隊列管理能在系統的各個部件之間提供保護。最基本的故障隔離方式是阻止對分配給其它應用的內存與資源帶寬的訪問。為了使虛擬化資源對應用完全透明，隊列和流量管理器必須只對損壞的應用采取行動。換句話說，必須要將應用與其它應用的活動屏蔽開來，并且要適應其它應用的故障，以維持穩定性。就其特性而言，專用隊列可隔離故障，防止其它處理器和應用受到影響。這類隊列還有利于有效的錯誤恢復；專用隊列可以完全地清除錯誤，而不會使其它應用的數據受到損失。

　　一個隊列與流量管理控制器可以實現對非法資源訪問的多級響應。最簡單的響應是阻止訪問，并給應用生成一個警報，通常是通過一個中斷。這個警報告訴應用，它試圖做了一些不應做的事。第二種方法是由開發人員記錄下使用的違背情況，幫助在現場查錯。隊列與流量控制器亦必須能夠通過觸發一個復位，并重新初始化一個可能損壞的應用，逐步升級其響應。理想情況下，開發人員可以創建一個控制此響應的策略。例如，開發人員可以設定一個閾值，如果某個應用做了三次非法訪問，就認為它是一個已損壞的應用，必須重新啟動。