基于多核架構和多收發隊列的高速捕包模型研究

齊戰勝 林立友

廈門市美亞柏科信息股份有限公司北京分公司 北京 100025

0 引言

一個好的包捕獲系統應該盡可能少的丟包，實時捕獲流經系統的所有數據包，而且應該較少地占用CPU資源，使得系統擁有更多的時間來對數據包內容的進行處理。

在包捕獲硬件方面，當前市場上有很多千兆以太網報文處理網卡，如Endace 公司生產的DAG網卡、Liberouter及SCAMPI項目開發的COMBO網卡等。由于基于硬件的捕包方式價格比較昂貴，而且系統缺乏一定的靈活性，難以適應當今瞬息萬變的網絡發展現狀與具體的流量分析需求。

在包捕獲軟件方面，設計了很多優秀的包捕獲函數庫如Libpcap、nCap、DMA-Ring和PF_RING等。Libpcap是一個優秀的數據包捕獲函數庫，由網卡驅動、操作系統內核協議棧以及套接字接口三個部分組成，由于消耗了較高的CPU資源、引入了較高的包傳輸延時等問題，效率較低。為了提高包捕獲的效率，很多研究人員已經做了大量的工作，包括從操作系統和應用軟件兩個方面進行優化。在操作系統方面：由于很多網絡應用都有實時性的要求，增加了一些實時的內核來提高網絡的實時性；為了避免頻繁的中斷造成的中斷活鎖現象，Linux內核中引入了一些新的 API函數，簡稱NAPI(NewAPI)，通過在重負載的情況下采用輪詢的方式來提高包捕獲系統的性能。在應用軟件方面：一種方式是減少內存拷貝次數，Libpcap-mmap、nCap、DMA-RING和PF_RING都采用了這種方式；第二種方式是減少系統調用的次數。

綜合分析以上包捕獲技術，發現以上沒有任何一種包捕獲接口的速度能達到千兆線速的處理目標，即使它們的設計目標是這樣；第二，都是基于單核的系統來進行設計，沒有考慮到發揮多核平臺和多收發隊列網卡的優勢來增加系統的吞吐量。

本文在基于PCI-E總線的 Intel X86 多核平臺下，通過充分利用RPS和RFS的包分發技術、PF_RING的零拷貝技術和多核CPU的計算資源，解決了 Gbit 及其以上鏈路帶寬下的包捕獲問題。

1 包捕獲模型

多核處理器是指在一枚處理器中集成兩個或多個完整的計算引擎(內核)。操作系統通過在多個執行內核之間劃分任務，多核處理器可在特定的時鐘周期內執行更多的任務。

多隊列網卡是一種技術，最初是用來解決網絡 IO QoS問題的，后來隨著網絡IO的帶寬的不斷提升，單核CPU不能完全處滿足網卡的需求，通過多隊列網卡驅動的支持，將各個隊列通過中斷綁定到不同的核上，以滿足網卡的需求。常見的有Intel的 82575、82576、82599、82580，Boardcom的57711等。

為了充分利用多核處理器的計算資源和多隊列網卡的吞吐能力，本文提出了以下包捕獲模型，如圖1所示。

圖1 包捕獲模型

此模型中采用的是Intel 82576多隊列網卡，模型工作流程如下：

(1) 數據包到達網卡后，產生硬中斷，網卡RSS根據數據包的IP和端口計算出hash值，hash值跟中斷個數取模后，分成若干個接收隊列。

(2) 為了保證分發到每個包處理線程的數據鏈的完整性(一個鏈接上的上行和下行數據都分發到一個包處理線程)，所以這里需要利用RPS和RFS技術對數據包進行重新計算Hash值，然后取模分發到相應的CPU核心上。

(3) 改進后的PF_RING為每一個接收隊列創建一個虛擬的網絡接口，通過在內核注冊的函數接收RFS分發下來的數據包，然后送到相應的虛擬網絡接口。

(4) 用戶空間的包處理線程通過PF_RING的虛擬網絡接口讀取數據包并處理。

2 核心技術簡介

2.1 RSS技術

多隊列數據包分發技術接收方擴展 (RSS，Receive Side Scaling)。目前的NICs支持多個接收和傳輸隊列，即多隊列。接收的時候，一個網卡能夠發送不同的包到不同的隊列，為了在不同的CPU之間分散處理。NIC針對每一個包，通過一個過濾器來指定這個包屬于少數幾個流中的一個流。每個流中的數據包被控制在一個單獨的接收隊列中，而隊列輪回的被CPU進行處理。這種機制就叫做RSS。RSS的目標和其他控制技術目的都是為了提高數據吞吐性能。

RSS中的過濾器是一個基于L3和L4層頭部的hash函數。例如，基于IP地址和TCP端口的4元組的hash函數。最常見的RSS硬件實現中，使用了128個間接表，其中每個表存儲一個隊列號(注，網卡的隊列數比較少，比如igb是8個，bnx2是5個)。針對某個包而言，使用這個包計算出的hash值(hash是Toeplitz算法)的低7位先確定間接表，再從間接表中的值訪問隊列。

多隊列網卡的驅動提供了一個內核模塊參數，用來指定硬件隊列個數。一個典型的RSS配置中，最好的是一個CPU對應一個接收隊列。每個接收隊列有一個單獨的IRQ，即中斷號。NIC通過IRQ來通知CPU什么時候新的數據包到達了指定的隊列。有效的隊列到IRQ的映射是由/proc/interrupts來指定的。一些系統會運行 irqbalance服務，這個服務會動態的優化IRQ的親和性。

2.2 RPS技術

RPS(Receive Packet Steering) 邏輯上是一種以軟件的方式來實現RSS。在數據包被從網卡驅動傳向網絡協議棧時，RPS在底半環境(通過軟中斷來實現的，在硬中斷處理函數之后)中被調用。通過把數據包放在目標CPU的backlog隊列，并喚醒CPU來處理，之后隊列中數據包被發送到網絡協議棧進行處理。

RPS相比RSS有幾個好處：

(1) RPS能夠被任何NIC使用。

(2) 軟件過濾器能夠輕易的被添加，用來hash新的協議。

(3) 它不會增加硬件設備的中斷。

決定目標CPU的第一步是基于包的地址和端口(有的協議是2元組，有的協議是4元組)來計算hash值。這個值與這個包的流保持一致。這個hash值要么是由硬件來提供的，要么是由協議棧來計算的。每一個接收硬件隊列有一個相關的CPU列表，RPS可以將包放到這個隊列中進行處理。對于每一個接收到的包，指向這個列表的索引是通過流hash值對列表大小取模來計算的。被指向的 CPU是處理包的目標CPU，并且這個包被加到CPU的backlog隊列的尾部。經過底半處理后，IPI被發送到這個包所插到的那個CPU。IPI喚醒遠程CPU來處理backlog隊列，之后隊列中數據包被發送到網絡協議棧進行處理。

RPS要求內核編譯了CONFIG_RPS選項(SMP上默認是打開的)。盡管編譯到內核，直到被配置了才能啟用。對于某個接收隊列，RPS可以轉發流量到哪個 CPU，是由/sys/class/net/queues/rx-/rps_cpus來控制的。這個文件實現了CPU的位圖。默認，當值是0，RPS是無效的，數據包是由中斷的CPU來處理的。

2.3 RFS技術

RFS(Receive Flow Steering)，RPS只依靠hash來控制數據包，提供了好的負載平衡，但是它沒有考慮應用程序的位置(注：這個位置是指程序在哪個 cpu上執行)。RFS則考慮到了應用程序的位置。RFS的目標是通過指派應用線程正在運行的CPU來進行數據包處理，以此來增加數據緩存的命中率。RFS依靠RPS的機制插入數據包到指定CPU的backlog隊列，并喚醒那個CPU來執行。

RFS中，數據包并不會直接的通過數據包的hash值被轉發，但是hash值將會作為流查詢表的索引。這個表映射數據流與處理這個流的CPU。這個數據流的hash值(就是這個流中的數據包的 hash值)將被用來計算這個表的索引。流查詢表的每條記錄中所記錄的CPU是上次處理數據流的CPU。如果記錄中沒有CPU，那么數據包將會使用RPS來處理。多個記錄會指向相同的CPU。確實，當流很多而CPU很少時，很有可能一個應用線程處理多個不同hash值的數據流。

RFS需要內核編譯 CONFIG_RPS選項，直到明顯的配置，RFS才起作用。全局數據流表(rps_sock_flow_table)的總數可以通過下面的參數來設置：/proc/sys/net/core/rps_sock_flow_entries每個隊列的數據流表總數可以通過下面的參數來設置：/sys/class/net//queues/rx-/rps_flow_cnt。

2.4 線程綁定技術

通過調用 SetThreadAffinityMask，就能為各個線程設置親緣性屏蔽：

該函數中的 hThread參數用于指明要限制哪個線程，dwThreadAffinityMask用于指明該線程能夠在哪個CPU上運行。dwThreadAffinityMask必須是進程的親緣性屏蔽的相應子集。返回值是線程的前一個親緣性屏蔽。

例如，可能有一個包含4個線程的進程，它們在擁有4個CPU的計算機上運行。如果這些線程中的一個線程正在執行非常重要的操作，而你想增加某個CPU始終可供它使用的可能性，為此你對其他3個線程進行了限制，使它們不能在CPU 0上運行，而只能在CPU 1、2和3上運行。因此，若要將3個線程限制到CPU 1、2和3上去運行，可以這樣操作：

2.5 PF_RING技術及優化

2.5.1 PF_RING技術簡介

PF_RING是Luca研究出來的基于Linux內核級的高效數據包捕獲技術。PF_RING基本原理是將網卡接收的數據包存儲在一個環狀緩存，這也是為什么叫RING的原因，這個環狀緩存有兩個接口，一個供網卡向其中寫數據包，另一個為應用層程序提供讀取數據包的接口，讀取數據包的接口通過 mmap函數(將一個文件或其它對象映射進內存)實現的。圖2顯示了PF_RING的工作原理。

圖2 PF_RING

2.5.2 PF_RING技術優化

由于 PF_RING需要定制的網卡驅動的支持，并且PF_RING的虛擬網絡接口目前僅支持 DNA(Direct NIC Access)模式，所以為了適應本模型的需要，本文做了以下優化：

(1) 修改PF_RING定制的網卡驅動，開啟網卡多接收隊列的功能；

(2) 把PF_RING的DNA模塊的虛擬網絡接口功能移植到NAPI模式下。

3 性能分析

3.1 實驗環境搭建

圖3顯示了測試環境的部署情況。

圖3 測試環境

測試服務器，i3 CPU 2.93GHZ，4G內存，2塊Intel 82576千兆網卡，Red Hat Enterprise 6.0系統(內核已升級為2.6.39)，

網絡流量發生儀，基于 Intel IXP2400 的網絡處理器，用于產生測試的流量。

控制端是普通的PC機，用來控制流量的組織、發送和控制。

3.2 性能測試與分析

3.2.1 捕包性能測試與分析

控制端控制流量發生儀發送 1000Mbit，長度分別為128、512 和 1024 字節的數據包，在被測試主機上分別采用 Libpcap，PF_RING和本文捕包模型接收測試流量。圖4顯示了當丟包數為零時各個包捕獲方式可以接收的最大流速率。

圖4 吞吐率對比測試圖

分析圖4的結果可以得出：在 1024 字節、512字節和128字節，1000Mbit 的鏈路環境下，Multi-PF_RING和PF_RING 接收速率沒有什么區別。

3.2.2 CPU使用率測試與分析

CPU 空閑率是衡量包捕獲接口的重要指標，空閑率高的CPU 可以有更多的時間用來做與應用更加相關的工作，控制端控制流量發生儀發送 100Mbit 至 1000Mbit，字節長度為512字節的鏈路流量。

圖5 CPU使用率對比圖

分析圖 5結果可以得出：同等接收速率下，Multi-PF_RING的CPU使用率最低。即使在1000Mbit/s時，CPU仍然有 70%左右的空閑率，可以讓 CPU有足夠的計算資源對數據包進行處理。

3.3 功能測試與分析

控制端控制流量發生儀發送 IP 包頭地址輪轉變化的IP 包，在測試服務器端觀察 Multi-PF_RING接收數據包的情況，發現測試服務器接收的 IP 包與流量發生儀發送的 IP包內容一致，驗證了程序的正確性；每個核心收到的鏈路數據是完整的，驗證了程序對數據包的分發是符合應用邏輯的。

4 結束語

本文首先提出了一種基于多核架構和多收發隊列的包捕獲模型，然后對包捕獲模型中涉及的核心技術進行了詳細介紹和分析，并結合本模型捕包的需要對 PF_RING的接口進行了優化。實驗結果表明，本文設計的 Multi-PF_RING 模型在保持高吞吐量的同時，具有更低的CPU使用率，給CPU留出了足夠的資源進行數據包的處理，并且保證了同一鏈接的數據始終被分發到一個CPU核心上。本文的不足之處是沒有考慮負載均衡的情況，當鏈接數目較少或者同一鏈接數據超多的情況下，會造成個別CPU核心超負荷運轉而其它核心閑置的情況，后期會進一步研究負載均衡的問題。

[1]張顯,黎文偉.基于多核平臺的數據包捕獲方法性能評估[J].計算機應用研究.2011.

[2]孫江.基于多核處理器的普適性報文捕獲技術研究[D].解放軍信息工程大學.2011.

[3]笱程成.基于多核架構的高速 IP包捕獲技術研究[D].解放軍信息工程大學.2010.

[4]http：//www.ntop.org/products/pf_ring.

http：//code.google.com/p/kernel/wiki/NetScalingGuide.