5G行動系統中的高能效封包處理
全球電信商均在致力於尋找降低網路能耗的新機會。我們評估了一種頗具前景並可作為其他方法的補充方法，在封包處理節點中應用微睡眠（micro-sleep）。微睡眠可在任何閒置時間段內適時應用，並能夠在各種流量條件下實現節能。
全球電信商均在致力於尋找降低網路能耗的新機會。我們評估了一種頗具前景並可作為其他方法的補充方法，在封包處理節點中應用微睡眠（micro-sleep）。微睡眠可在任何閒置時間段內適時應用，並能夠在各種流量條件下實現節能。
提高行動通訊系統的能源效率，以及減少行動寬頻服務的能源消耗量有很多種方法。
在嘗試降低網路能耗過程中，電信商（CSP）可能會選擇升級到能耗比上一代產品更低的新硬體（HW）。另外還可以借助先進的向內擴展/向外擴展機制降低能耗，在流量較低時（如夜間）減少所使用的硬體數量。在這些情況下，可以透過關閉一些伺服器節省能源。
但不管採用何種節能機制，均須確保不會對抖動（jitter）和封包延遲等即時特性造成負面影響。同樣重要的是，我們必須知道，摩爾定律與每一代新硬體的節能效益之間的相關性已經下降。
我們的最新研究表明，CSP可以透過在封包處理節點應用微睡眠的方式讓資料中心節省更多能源。這種方法比現有方法具有更低的開銷和更低的延遲，並且能夠在高負載的情況下降低能源消耗，而不會降低應用程式性能。由於電源管理在通訊檔案庫中實現，因此很容易整合到現有應用程式中。
通訊網路中的封包處理
通訊網路中的封包處理需要使用不同的函數和演算法，以確保每個封包均可高效通過網路。其中涉及的步驟包括封包識別、檢查和操作等。
網路封包是封包交換網路中的基本元件，由三個主要部分組成：表頭、承載資料（payload）和表尾。表頭包含發送方位址、目的地址、封包長度和封包序號等資訊。負載資料包含所傳輸的資料——即影片、電子郵件或其他類型內容的一部分資料。表尾標記封包的結尾，也可以包括錯誤檢測和修正資訊。
不同封包處理功能和演算法從相當簡單到相對複雜不等。基本路由功能是簡單封包處理的一個很好例子。更複雜的封包處理功能則涉及到不同策略的應用、封包的計費和操作。
用戶層封包處理節點
儘管微睡眠可以應用於所有類型的封包處理，但我們的研究發現，它們在用戶層功能（UPF）中使用時效果顯著。
根據3GPP的定義，UPF是行動系統中將RAN連接到網路（或類似的資料網路）的用戶層封包處理節點[4]。簡而言之，UPF的主要目的是將封包轉發到網路或從網路轉發封包。這些通常要結合不同的流量優化功能才能完成，這些功能包括從純傳輸控制協議（TCP）優化到與智慧流量擁塞邏輯相結合的更高級影像優化。
UPF涉及多個複雜的處理功能，比如GPRS通道協議層（GPRS Tunneling Protocol User Plane）封裝和拆裝。其他UPF功能還包括存取控制、承載查詢（bearer lookup）、QoS映射和標記等。另外它也遵循保證位元速率和最大位元速率的規則。通過UPF的封包也要進行線上/離線計費，也就是應用不同的計費策略。
不同使用者設備如何處理封包的指令來自會話管理功能/策略控制功能。大多數情況下，不同使用者封包的處理是獨立發生的。所有封包處理函數和演算法都必須滿足系統對抖動和封包延遲等即時特性的要求。
核心（Kernel）封包處理
電腦中內建的本地網路支援是作為作業系統（OS）核心的一部分實現的，並使用POSIX（可攜式作業系統介面）通訊端（socket）作為其標準應用程式開發介面（API）。
在核心封包處理中，使用者模式應用程式使用POSIX通訊端API發送和接收封包，而核心驅動程式/調度程式處理與網路介面卡（NIC）的交互。如果網路沒有就緒（沒有封包到達），核心可以決定在等待時阻止該應用程式。
圖1的左側說明了核心封包處理的工作原理，「App」代表使用者模式應用程式。在這個模型中，作業系統知道閒置時間，並且可以執行作業系統電源管理節省電力。
圖1: 核心封包處理 vs 核心旁路封包處理
核心封包處理存在很多缺點。最主要的是，作業系統調用的高額開銷，以及需要將封包複製到核心空間（或從核心空間複製），讓其難以達到較高的網路速度和較高的封包速率。例如，在200Gbit乙太網上處理1,534位元組封包的時間為61ns。這相當於執行系統調用的執行時間，沒有留出足夠的時間執行封包處理本身。現今的網卡速度讓核心封包處理在最佳情況下也具有挑戰性，而在最糟情況下則無法實現。
核心的電源管理在高網速情況下可能會出現問題。作業系統核心根據核心利用率進行能源的監控和節約。這種機制速度很慢，無法跟上高速網路流量的快速變化，最終導致佇列堆積（queue buildups）、延遲，甚至封包丟棄（drop）。
核心旁路封包處理
核心旁路封包處理透過將封包處理直接轉移到用戶空間來消除核心執行開銷（overhead），如圖1右側所示。在這種情況下，作業系統可以將網路介面專門用於可從使用者空間（user-space）對硬體進行程式設計的資料層開發套件（DPDK）等應用程式。
使用DPDK時，直接在使用者空間記憶體中接收封包，無需核心交互，並且所有與網路相關的中斷均被禁用。確保經常檢查NIC的封包佇列和環形緩衝區是否有新封包的工作由應用程式完成。
為了避免封包丟棄和減少封包延遲，基於DPDK的應用程式設計為在忙碌等待模式下檢查封包環形緩衝區（ring buffer），並將所有核心分配給應用程式執行緒（thread）。這使得封包處理無需任何上下文切換（context switching）或硬體中斷，並且由於應用程式執行緒是核心的唯一用戶，對快取的污染最小。對將DPDK作為封包處理核心旁路的測量表明，數百萬個封包可以在單個核心中接收並透過管道傳輸到其他核心做進一步的封包處理。
核心旁路封包處理解決了如何在200GB乙太網路及更高速度下處理封包的問題，但封包接收的忙碌等待技術是有代價的。如果所有封包處理核心在忙碌等待模式下均100%被使用，則無法實現節能。
在核心旁路封包處理中，乙太網路封包直接傳輸到使用者模式（user mode）應用程式記憶體。電源管理需要在DPDK庫中的使用者空間中執行。需要注意的是，在更改核心頻率時，DPDK會與核心電源管理進行交互[1]。
利用DPDK進行高能源效率封包處理
更高的資料速率使得有必要將封包處理更改為使用具有專用核心、使用者模式執行和輪詢模式驅動程式（poll-mode driver）的DPDK，以此消除上下文切換和系統調用的高額開銷。但遺憾的是，這種解決方案無法做到現代硬體所能做到的那種節能程度。需要解決的問題主要有三個：
- 忙碌等待模式在等待工作時要消耗更多非必要的電力。
- 作業系統電源管理速度慢，導致無法利用封包之間的閒置時間以及處理高速介面的封包突發。
- DPDK中的忙碌等待模式總是讓核心看似100%被佔用，因此沒有任何資訊可以作為諸如在低流量期間縮減規模等電源管理決策的依據
為了解決這些問題，電源管理行動必須快速，直接從封包處理應用程式進行控制並在使用者模式下執行。兩項技術進展讓這些成為可能。首先，伺服器處理器現在支援直接從處於使用者模式的應用程式進入省電睡眠狀態。其次，最新版本DPDK庫包含了可在等待新的網路事件時對睡眠狀態加以利用的選項，從而避免了與忙碌等待迴圈相關的問題[1]。
使用者模式睡眠狀態
處理器存在進入睡眠狀態、等待事件和喚醒的具體指令。以前這些指令只能在管理員模式下的作業系統中使用，但現在這些指令的新版本已經可以安全用於實現使用者模式微睡眠狀態。新指令比舊指令速度快得多，並且可以在沒有作業系統支援的情況下執行。
最新指令允許使用者模式程式設置所要監視的事件（即，指定程式所等待的環形緩衝區的更新）、定義所允許的最長等待時間，然後進入睡眠狀態。當事件發生時（或最大等待時間過後），程式就會被喚醒並繼續執行。這樣在進入作業系統核心、進行上下文切換等時就不存在開銷。
用於設置所監視事件和進入睡眠狀態使用者模式指令的範例為用在Intel處理器上的UMONITOR和UMWAIT[2]以及用在AMD處理器上的MONITORX和MWAITX[3]。這些指令能夠在比以往更短的閒置時間段內實現能源節約。另外其還可以在更高的通訊速度下保持高效運行。
DPDK整合
DPDK檔案庫（library）最近增加了對最新使用者模式睡眠狀態機制的支援，可以在輪詢迴圈對DPDK描述子環（descriptor ring）或環（ring）進行忙碌等待中直接進入節能睡眠狀態。
如果描述子環（或環）的輪詢為空，則將建立一個事件監視器，在使用者模式睡眠狀態開始之前完成最終輪詢。相關更新（如與環中被監視位置相關的NIC或其他中央處理器（CPU）核心更新）將被處理器HW檢測到，然後喚醒CPU核心重新開始執行下一條指令，繼續進行輪詢。然後輪詢迴圈將會檢測更新。
圖2說明了如何將電源管理整合到DPDK中。在此設置中，網路設備在應用程式使用者模式記憶體中分配環形緩衝區和封包緩衝區，並在封包接收時使用新的封包緩衝區點更新環形緩衝區。當環形緩衝區為空（即到NIC的佇列為空）時，進入使用者模式睡眠狀態。當NIC更新環形緩衝區時，就會觸發喚醒。值得注意的是，所建議的電源管理不會影響到應用程式邏輯。
圖2: 如何將電源管理整合到DPDK中
可觀測性
處理器具有對執行時間和不同睡眠狀態時間的測量功能。使用者模式睡眠狀態讓該測量功能能夠測量CPU執行緒利用率，並且CPU執行緒利用率也可被觀察用於DPDK應用程式。CPU執行緒利用率還可作為其他類型電源管理（如頻率縮放）控制環路的輸入，而這些電源管理可以作為使用者模式睡眠狀態的補充，從而有可能進一步提高能源效率。
硬體移除
HW移除是一種將選定流的處理從處理器（慢速路徑）轉移到NIC（快速路徑）的技術。這種方法可以釋放CPU核心，並且由於更多的CPU核心有機會微睡眠，因此讓微睡眠技術發揮更大作用。硬體移除還可提高周邊元件互連匯流排（Peripheral Component Interconnect bus）的效率，並具有提高系統輸送量、效率和延遲等更多潛在好處。
處理器核心電壓/頻率縮放
降低CPU核心電壓和頻率是一種可在更長時間更低處理過程中獲得最佳效率的補充方法。由於降低電壓和頻率也就意味著更短的閒置時間，因此使用者模式睡眠狀態需要權衡利弊。
由於功耗與電壓的平方成正比增加，因此在封包速率下降一段時間後降低電壓和頻率是有利的。需要利用快速可靠的監控功能檢測所增加的封包速率，特別是檢測封包突發。檢測速度越快、越可靠，就可以越積極主動降低電壓和頻率，而不會因佇列堆積增加延遲、時序抖動和相關封包丟棄風險而造成負面影響和KPI降低。
DPDK提供了可以快速控制CPU核心電壓/頻率縮放的介面。在實施過程中，我們使用了DPDK中連帶控制環路的快速封包突發檢測，該控制環路用於保持即便發生最糟突發情況也能應對處理的性能餘量。存在餘量時，使用者模式等候狀態可以提供另一種節能方法，並且以在不影響能源效率的情況下避免對封包處理造成任何負面影響。
處理器非核心電壓/頻率縮放
非核心是指處理器實際核心之外的部分——即CPU核心（和其他功能）與處理器上與所有CPU共用和使用介面之間的互連。降低非核心電壓和頻率是對在核心中執行節能機制的補充。與在核心中一樣，在封包速率下降一段時間後降低電壓和頻率比較有利。
由於非核心由所有CPU核心共用，因此必須在包括DPDK外部核心在內所有核心和應用程式之間協調頻率需求，從而將非核心更改為比核心頻率變化更慢的機制。
實驗驗證和結果
我們通過兩組實驗室實驗對用戶平面微睡眠設計進行驗證。在第一組實驗中，我們生成一個被認為具有現實性的工作負載並將其應用於UPF應用程式。UPF測量表明，處理器能耗在低流量負載時從190W降至61W，在最大流量負載時從190W降至145W。除了對實際使用案例中的潛在節能源效率果進行量化外，我們的結果還證實了該節能方法在現有通訊應用程式中效果良好。
我們的第二組實驗使用了意在模擬極端條件的合成工作負載。實驗結果表明，該節能方法既穩定又高效，其影響即使在最糟情況下也可忽略不計。
應用於使用者面功能的高能源效率封包處理
在第一組實驗中，我們將基於DPDK的電源管理與微睡眠和頻率縮放應用於愛立信UPF應用程式。為了測量使用HW移除時的能源增益，將UPF設計為將封包流使用最高頻寬移除到網路設備。
我們使用了來自內部穩定性測試的流量組合作為流量模型，並且我們使用模擬周圍網元的外部流量生成器生成流量。結果在圖3中顯示。藍色條顯示了在閒置負載、50%最大流量負載以及100%流量負載下運行基於DPDK未修改的CPU功耗。綠色和紫色條顯示為使用未硬體移除的電源管理以及使用電源管理且硬體移除情況下運行相同流量負載時的能耗。
圖3: 在閒置負載、50%最大流量負載以及100%流量負載下運行基於DPDK未修改的CPU功耗
測量結果顯示，使用電源管理（圖3中最左側的綠色條）時，處理器在閒置負載時的功耗降低了68%。啟用電源管理時的50%負載和100%負載橫條圖顯示，即使流量負載增加，處理器功率也會降低。
透過完美平衡處理器負載讓沒有滿載的核心休眠並節省能源的難度很大。在我們的實驗中，在最大流量負載條件下可以節省10%的能源（圖3中最右側的綠色條）。這一結果根據應用程式和流量組合不同存在變動。
NIC硬體移除技術讓微睡眠技術獲得很大機會，從而在最大負載下可以整體節能24%（圖3中最右側的紫色長條圖）。使用HW移除節省的電力具體取決於每個應用程式利用HW移除節省處理器資源的能力。
綜合基準測試
對於我們提出的使用微睡眠和頻率縮放的電源管理解決方案，其目標在於既要對封包延遲的影響極低，同時又要對流量突發做出快速反應。例如，在低時延電源管理中，流量突發不能造成任何丟包問題。新的使用者模式睡眠狀態讓核心能夠在幾百奈秒內喚醒，並應把對總封包延遲的影響降到最低。
為了測量封包延遲和電源管理功能對流量突發的反應速度，我們進行了一項綜合基準測試，並盡可能降低了基準測試中應用程式接收網路流量時對於封包延遲的影響。這樣我們才能夠測量使用者模式睡眠狀態和頻率縮放對於封包延遲影響。綜合基準測試還可用於衡量系統在接收流量突發時能夠以多快的速度擴展性能。
綜合基準測試程式使用DPDK獲取乙太網路封包，交換媒體存取控制位址並將封包發送回原始來源。源頭設備則測量從發送封包到接收封包的時間（也稱往返延遲（RTD）），其中也包括封包丟棄。在網路設備佇列為空時使用使用者模式睡眠，並在網路流量增加/減少時觸發頻率縮放。
圖4顯示了在外部流量生成器上測得直到最後一秒的最大RTD。在低流量時，由於核心/非核心頻率降低，使用電源管理時的RTD略高（圖4下半部分的綠線）。當流量從27Mbit/s增加到190Gbit/s時，使用所執行的DPDK突發檢測器，核心/非核心頻率變為最大速度。在最大負載（190Gbit/s）下，封包延遲對電源管理的影響可以忽略不計。
圖4: 在外部流量生成器上測得直到最後一秒的最大RTD
我們的結果顯示，測得的最糟情況下的RTD或最大封包抖動沒有受到影響，但RTD值在低流量負載下略高一些。測量期間沒有發生丟包。
結論
我們的研究顯示，降低能耗的同時滿足延遲敏感型應用程式的需求並非不可能。最新一代伺服器處理器可通過直接從使用者模式的應用程式進入睡眠狀態實現快速節能轉換，並且不會影響抖動和封包延遲等重要的KPI。由於不存在進入作業系統核心的開銷，也沒有上下文切換，在使用者模式睡眠狀態期間，中央處理單元核心只需在封包到達時喚醒並繼續工作。由於電源管理是使用者模式封包處理庫的一部分，因此節能很容易在現有基於資料層開發套件的應用上進行集成和驗證。
將微睡眠、硬體移除和頻率縮放結合使用有可能獲得更為突出的節能源效率果。我們對愛立信用戶面功能的實驗表明，處理器能耗在低流量時從190W降低到61W，在最大流量時從190W降低到145W。我們還進行了綜合基準測試實驗，結果顯示我們提出的電源管理解決方案對最糟情況的往返延遲和最糟情況的封包延遲沒有可計量的顯著影響。
