本發(fā)明涉及計算機通信技術，尤其涉及一種多核CPU(Central Processing Unit，中央處理器)的負載均衡方法及裝置。

背景技術：

對于路由器、網關等設備，報文的轉發(fā)通過中央處理器(CPU，Central Processing Unit)完成，因此，這類設備的報文轉發(fā)性能受CPU的處理能力制約，而對于多核CPU，如何發(fā)揮多核效率，均衡多核之間的負載，是提升性能的關鍵。

如圖1所示，Linux操作系統(tǒng)的內核協(xié)議棧報文的處理流程包括：當一個CPU核(比如CPU0、CPU1)收到接口產生的硬件中斷后，先關閉本CPU核的接口硬件中斷，然后觸發(fā)本CPU核的軟中斷，然后輪詢處理報文。其中，從收到硬件中斷起，至發(fā)包完成，都由同一個CPU核處理。目前許多多核CPU，硬件中斷都是接口級的(即一個硬件中斷號綁定一個接口，中斷信號同一時刻送至一個CPU核)，即同一時刻，只有一個CPU核處理報文。這就造成了多核CPU不能完整發(fā)揮多核效率。

針對上述問題，目前常用的解決方案包括：

方案一、一個CPU核專用于處理報文轉發(fā)，其他CPU核處理其他應用；

方案二、按照接口，將不同接口綁定不同的CPU核，這樣每個CPU核都能處理報文又不產生沖突；

方案三、一個CPU核在收到中斷后，指定其他CPU核處理報文。

雖然上述三個方案都能在一定程度上平衡多核的負載，但是，對于方案一，由于路由器等設備的主要負載為報文轉發(fā)，其余應用占用的CPU利用率較低，因此，方案一相較于單核CPU提升的性能有限；對于方案二，雖然每個CPU核都能處理報文轉發(fā)，但由于每個接口接收的報文流量不同(比如，下行流量一般遠大于上行流量)，因此，方案二也不能完全平衡多核之間的負載；對于方案三，需要進行軟件分流，會產生CPU額外開銷，而且在進行數據流保序時，會存在更大的CPU額外開銷。

技術實現要素：

以下是對本文詳細描述的主題的概述。本概述并非是為了限制權利要求的保護范圍。

本發(fā)明實施例提供一種多核CPU的負載均衡方法及裝置，能夠有效均衡多核負載，提高設備的轉發(fā)性能，而且不引入CPU額外開銷即能實現數據流保序功能。

本發(fā)明實施例提供一種多核CPU的負載均衡方法，應用于通信設備，所述通信設備包括硬件分流模塊、接收端口以及至少兩個CPU核，其中，每個接收端口配置為與至少兩個CPU核綁定，與同一個接收端口綁定的CPU核配置為分別綁定所述接收端口的一個或多個接收隊列；

所述負載均衡方法包括：

針對每個接收端口，硬件分流模塊根據分流規(guī)則將報文分類，并根據所述接收端口的接收隊列與報文類型的分配關系，將所述報文轉發(fā)至與所述報文所屬的報文類型存在分配關系的接收隊列；

所述接收端口接收到所述報文后，產生硬件中斷，并將所述硬件中斷同時上報給與所述接收端口綁定的所有CPU核；

接收到所述硬件中斷的每個CPU核在軟中斷處理過程中，從與本CPU核綁定的接收隊列讀取報文。

在示例性實施方式中，所述硬件分流模塊可以至少包括CPU芯片的硬件分類單元以及DMA單元；

所述硬件分流模塊根據分流規(guī)則將報文分類，并根據所述接收端口的接收隊列與報文類型的分配關系，將所述報文轉發(fā)至與所述報文所屬的報文類型存在分配關系的接收隊列，包括：

所述硬件分類單元根據分流規(guī)則將報文分類；

所述DMA單元根據所述接收端口的接收隊列與報文類型的分配關系，將所述報文轉發(fā)至與所述報文所屬的報文類型存在分配關系的接收隊列。

在示例性實施方式中，所述硬件分流模塊可以包括外置交換芯片、CPU芯片的硬件分類單元以及DMA單元；

所述硬件分流模塊根據分流規(guī)則將報文分類，并根據所述接收端口的接收隊列與報文類型的分配關系，將所述報文轉發(fā)至與所述報文所屬的報文類型存在分配關系的接收隊列，包括：

所述外置交換芯片根據分流規(guī)則將報文分類，并根據接收端口的接收隊列與報文類型的分配關系，修改所述報文的優(yōu)先級，并將所述報文發(fā)送給所述硬件分類單元；

所述硬件分類單元匹配所述報文的優(yōu)先級；

所述DMA單元將所述報文轉發(fā)至對應所述優(yōu)先級的接收隊列。

在示例性實施方式中，所述分流規(guī)則可以包括：

匹配報文為以下任一大類：管理類報文、非管理類IP報文、非管理類非IP報文；

在所述報文屬于非管理類IP報文時，按照所述報文的IP地址，細分所述報文所屬的報文類型。

在示例性實施方式中，所述負載均衡方法還可以包括：

針對所述接收端口，所述接收到所述硬件中斷的每個CPU核在報文處理過程中，記錄不同報文類型的數據流的流量；

滿足預定條件的CPU核根據預定時長內與所述接收端口綁定的所有CPU核記錄的不同報文類型的數據流的流量，更新所述接收端口的接收隊列與報文類型的分配關系。

在示例性實施方式中，所述滿足預定條件的CPU核根據預定時長內與所述接收端口綁定的所有CPU核記錄的不同報文類型的數據流的流量，更新所述接收端口的接收隊列與報文類型的分配關系，可以包括：

根據預定時長內與所述接收端口綁定的所有CPU核記錄的不同報文類型的數據流的流量，計算非管理類IP報文的數據流以及非管理類非IP報文的數據流的流量總和；

根據所述流量總和以及用于處理報文的CPU核的數目，確定CPU核的平均負載流量；

根據非管理類IP報文的數據流的流量、非管理類非IP報文的數據流的流量以及CPU核的平均負載流量，給非管理類IP報文的數據流以及非管理類非IP報文的數據流指定所述接收端口的接收隊列，以滿足給每個接收隊列分配的數據流的總流量之間的差值小于或等于閾值。

在示例性實施方式中，所述滿足預定條件的CPU核根據預定時長內與所述接收端口綁定的所有CPU核記錄的不同報文類型的數據流的流量，更新所述接收端口的接收隊列與報文類型的分配關系，還可以包括：

在給非管理類IP報文的數據流以及非管理類非IP報文的數據流指定所述接收端口的接收隊列之后，給管理類報文的數據流指定所述接收端口的索引最大的接收隊列；其中，與所述接收端口綁定的所有CPU核中的負載最小的CPU核配置為與所述接收端口的索引最大的接收隊列綁定。

本發(fā)明實施例還提供一種多核CPU的負載均衡裝置，包括：硬件分流模塊、接收端口以及至少兩個CPU核；其中，每個接收端口配置為與至少兩個CPU核綁定，與同一個接收端口綁定的CPU核配置為分別綁定所述接收端口的一個或多個接收隊列；

所述硬件分流模塊，用于針對每個接收端口，根據分流規(guī)則將報文分類，并根據所述接收端口的接收隊列與報文類型的分配關系，將所述報文轉發(fā)至與所述報文所屬的報文類型存在分配關系的接收隊列；

所述接收端口，用于在接收到所述報文后，產生硬件中斷，并將所述硬件中斷同時上報給與所述接收端口綁定的所有CPU核；

接收到所述硬件中斷的每個CPU核，用于在軟中斷處理過程中，從與本CPU核綁定的接收隊列讀取報文。

在示例性實施方式中，所述硬件分流模塊可以至少包括CPU芯片的硬件分類單元以及DMA單元；

其中，所述硬件分類單元，用于根據分流規(guī)則將報文分類；

所述DMA單元，用于根據所述接收端口的接收隊列與報文類型的分配關系，將所述報文轉發(fā)至與所述報文所屬的報文類型存在分配關系的接收隊列。

在示例性實施方式中，所述硬件分流模塊可以包括外置交換芯片、CPU芯片的硬件分類單元以及DMA單元；

所述外置交換芯片，用于根據分流規(guī)則將報文分類，并根據接收端口的接收隊列與報文類型的分配關系，修改所述報文的優(yōu)先級，并將所述報文發(fā)送給所述硬件分類單元；

所述硬件分類單元，用于匹配所述報文的優(yōu)先級；

所述DMA單元，用于將所述報文轉發(fā)至對應所述優(yōu)先級的接收隊列。

在示例性實施方式中，所述分流規(guī)則可以包括：

匹配報文為以下任一大類：管理類報文、非管理類IP報文、非管理類非IP報文；

在所述報文屬于非管理類IP報文時，按照所述報文的IP地址，細分所述報文所屬的報文類型。

在示例性實施方式中，所述CPU核，還用于在接收到接收端口的所述硬件中斷后，在報文處理過程中，記錄不同報文類型的數據流的流量；

滿足預定條件的CPU核，還用于根據預定時長內與所述接收端口綁定的所有CPU核記錄的不同報文類型的數據流的流量，更新所述接收端口的接收隊列與報文類型的分配關系。

在示例性實施方式中，所述滿足預定條件的CPU核，用于根據預定時長內與所述接收端口綁定的所有CPU核記錄的不同報文類型的數據流的流量，計算非管理類IP報文的數據流以及非管理類非IP報文的數據流的流量總和；根據所述流量總和以及用于處理報文的CPU核的數目，確定CPU核的平均負載流量；根據非管理類IP報文的數據流的流量、非管理類非IP報文的數據流的流量以及CPU核的平均負載流量，給非管理類IP報文的數據流以及非管理類非IP報文的數據流指定所述接收端口的接收隊列，以滿足給每個接收隊列分配的數據流的總流量之間的差值小于或等于閾值。

在示例性實施方式中，所述滿足預定條件的CPU核，還用于在給非管理類IP報文的數據流以及非管理類非IP報文的數據流指定所述接收端口的接收隊列之后，給管理類報文的數據流指定所述接收端口的索引最大的接收隊列；其中，與所述接收端口綁定的所有CPU核中的負載最小的CPU核配置為與所述接收端口的索引最大的接收隊列綁定。

在本發(fā)明實施例中，每個接收端口配置為與至少兩個CPU核綁定，對于不支持在接收端口收到報文后，按報文或者按接收隊列產生硬件中斷，或者產生的硬件中斷不能分別送給多個CPU核的情況，實現了至少兩個CPU核可以同時處理同一接收端口下的報文，從而有效地改善多核效率，提高設備的轉發(fā)性能；而且，本發(fā)明實施例通過硬件預分流方式，使得分流速度達到線速，避免了引入分流產生的CPU額外開銷，從而能無額外負擔地實現數據流保序功能。

進一步地，本發(fā)明實施例通過監(jiān)控不同報文類型的數據流的流量，動態(tài)更新接收端口的接收隊列與報文類型的分配關系，從而可以根據不同報文類型的數據流的流量變化情況，實現多核CPU實時的負載動態(tài)均衡。

本申請的其它特征和優(yōu)點將在隨后的說明書中闡述，并且，部分地從說明書中變得顯而易見，或者通過實施本申請而了解。本申請的目的和其他優(yōu)點可通過在說明書、權利要求書以及附圖中所特別指出的結構來實現和獲得。

附圖說明

附圖用來提供對本申請技術方案的進一步理解，并且構成說明書的一部分，與本申請的實施例一起用于解釋本申請的技術方案，并不構成對本申請技術方案的限制。

圖1為相關技術中Linux操作系統(tǒng)的內核協(xié)議棧報文的處理流程示意圖；

圖2為本發(fā)明實施例一提供的多核CPU的負載均衡方法的流程圖；

圖3為本發(fā)明實施例一的多核CPU的負載均衡方法的應用實例示意圖；

圖4為本發(fā)明實施例一的接收端口的接收隊列與報文類型的分配關系的計算流程圖；

圖5為本發(fā)明實施例一的接收端口的接收隊列與報文類型的分配關系的一個例子的示意圖；

圖6為本發(fā)明實施例二提供的多核CPU的負載均衡裝置的示意圖。

具體實施方式

以下結合附圖對本申請實施例進行詳細說明，應當理解，以下所說明的實施例僅用于說明和解釋本申請，并不用于限定本申請。

需要說明的是，本申請的說明書和權利要求書及上述附圖中的術語“第一”、“第二”等是用于區(qū)別類似的對象，而不必用于描述特定的順序或先后次序。

需要說明的是，如果不沖突，本申請實施例以及實施例中的各個特征可以相互結合，均在本申請的保護范圍之內。另外，雖然在流程圖中示出了邏輯順序，但是在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟。

實施例一

本實施例提供一種多核CPU的負載均衡方法，可以應用于通信設備，其中，通信設備可以包括硬件分流模塊、接收端口以及至少兩個CPU核，每個接收端口配置為與至少兩個CPU核綁定，與同一接收端口綁定的CPU核配置為分別綁定此接收端口的一個或多個接收隊列。

其中，與同一接收端口綁定的不同CPU核綁定的接收隊列是不同的。當CPU核與接收端口的多個接收隊列綁定時，接收隊列的索引越大，優(yōu)先級越高。

換言之，接收端口與CPU核之間存在一對多的綁定關系，接收端口的接收隊列與CPU核之間存在一對一或者多對一的綁定關系，且不同CPU核綁定的接收隊列是不同的。

其中，每個接收端口可以使用的接收隊列的數目可以相同或不同，可以由CPU芯片的硬件決定，或者，可以在CPU芯片啟動時分配每個接收端口可以使用的接收隊列的數目。

本實施例提供的多核CPU的負載均衡方法，如圖2所示，包括：

步驟201：針對每個接收端口，硬件分流模塊根據分流規(guī)則將報文分類，并根據接收端口的接收隊列與報文類型的分配關系，將報文轉發(fā)至與報文所屬的報文類型存在分配關系的接收隊列；

步驟202：接收端口接收到報文后，產生硬件中斷，并將硬件中斷同時上報給與接收端口綁定的所有CPU核；

步驟203：接收到硬件中斷的每個CPU核在軟中斷處理過程中，從與本CPU核綁定的接收隊列讀取報文。

在相關技術中，在Linux操作系統(tǒng)中，接收端口接收報文產生的硬件中斷，之所以同一時刻只綁定到一個CPU核，是由于一個報文只能由一個CPU核收取和處理，當不同CPU核同時收取相同的報文時，會產生競爭。針對此問題，在本實施例中，對接收的報文進行分類，當多個CPU核同時收到一個接收端口的硬件中斷時，每個CPU核只處理指定類型的報文；另外，為了減少報文分類產生的CPU消耗，可以在報文轉到接收端口前，通過硬件分流模塊按照分流規(guī)則將報文分類，并送至接收端口的不同接收隊列，然后每個CPU核只處理指定接收隊列的報文。在上述機制下，可以放開一個硬件中斷只由一個CPU核處理的限制。在實際應用中，可以通過修改Linux內核源碼，比如在ARM(Advanced RISC Machines)體系下，可以修改GIC(Generic Interrupt Controller，通用中斷控制器)代碼，將一個硬件中斷同時綁定到多個CPU核上。

在一些應用中，要求報文(IP報文或非IP報文)必須按照順序發(fā)送，針對這種情況，為了確保數據流保序的問題，可以對數據流進行分類，按照報文類型指定接收隊列。比如，針對IP數據流(一條IP數據流會包含多個按順序發(fā)送的數據報文)，在分類報文指定接收隊列時，可以按IP(Internet Protocol，網絡協(xié)議)地址進行數據流分類，比如，按源IP地址根據一定算法對數據流進行分類，并指定到相應的接收隊列，這樣每條數據流就會只由一個CPU核處理，也就不會產生亂序問題。其中，大部分CPU芯片都支持按IP地址進行分類和指定接收隊列，即使不支持按IP地址分類也可通過外置交換(switch)芯片的方式配合實現報文分類。

在步驟201中，針對每個接收端口，硬件分流模塊根據預先設置的分流規(guī)則對報文進行分類，確定報文所屬的報文類型，并根據接收端口的接收隊列與報文類型的分配關系，將報文轉發(fā)至與所屬報文類型存在分配關系的接收隊列。

一些實現方式中，在CPU芯片自身支持報文分類并可以指定接收隊列時，可以直接配置CPU芯片的分流規(guī)則以及接收端口的接收隊列與報文類型的分配關系。此時，硬件分流模塊可以至少包括CPU芯片的硬件分類單元以及DMA(Direct Memory Access，直接內存存取)單元；

其中，硬件分類單元，用于根據分流規(guī)則將報文分類；DMA單元，用于根據接收端口的接收隊列與報文類型的分配關系，將報文轉發(fā)至與此報文所屬的報文類型存在分配關系的接收隊列。

在本實現方式中，CPU芯片的硬件分類單元可以實現匹配IP層及MAC(Media Access Control，介質訪問控制)層的數據進行分類；比如，匹配MAC層的MAC地址和以太類型以及目的IP地址等信息，確認是否是管理類報文，匹配IP信息用于對非管理類IP報文進行細分，剩余未匹配到前兩類的報文則屬于非管理非IP報文；然后，通過DMA單元將分類后的報文存至指定的接收隊列。

一些實現方式中，在CPU芯片自身不支持報文分類以及指定接收隊列時，可以通過外置交換芯片來配合實現報文分類以及指定接收隊列。此時，硬件分流模塊可以包括外置交換芯片、CPU芯片的硬件分類單元以及DMA單元；步驟201可以包括：

外置交換芯片根據分流規(guī)則將報文分類，并根據接收端口的接收隊列與報文類型的分配關系，修改報文的優(yōu)先級，并將報文發(fā)送給硬件分類單元；

硬件分類單元匹配報文的優(yōu)先級；

DMA單元將報文轉發(fā)至對應優(yōu)先級的接收隊列。

在本實現方式中，由外置交換芯片完成匹配IP層及MAC層的數據進行分類，然后修改報文的優(yōu)先級，并將報文轉發(fā)至CPU芯片。CPU芯片的硬件分類單元(也可以稱為QoS單元)僅支持基本的QoS(Quality of Service，服務質量)分類，即匹配優(yōu)先級，再由DMA單元將報文保存到指定的接收隊列。

其中，外置交換芯片對報文進行分類以及修改報文的優(yōu)先級之后，CPU芯片可以根據默認的報文優(yōu)先級與接收端口的接收隊列的關系，將報文按照優(yōu)先級轉發(fā)到對應的接收隊列。由于此時報文的優(yōu)先級根據接收端口的接收隊列與報文類型的分配關系進行了修改，因此，CPU芯片將報文進行轉發(fā)后，報文與接收隊列的關系可以滿足接收端口的接收隊列與報文類型的分配關系。

需要說明的是，在實際應用中，可以根據CPU芯片的硬件分類單元的分類能力強弱，選擇合適的硬件預分流方式進行報文分類。

一些實現方式中，分流規(guī)則可以包括：

匹配報文為以下任一大類：管理類報文、非管理類IP報文、非管理類非IP報文；

在報文屬于非管理類IP報文時，按照報文的IP地址，細分報文所屬的報文類型。

其中，報文可以區(qū)分為以下三個大類：管理類報文、非管理類IP報文、非管理類非IP報文。管理類報文可以單獨看成一條數據流，由于此類型的數據流的流量一般較小，因此在后續(xù)計算中可以不計算此類數據流的負載。非管理類非IP報文由于不參與轉發(fā)，且流量一般不大，因此也可以單獨看成一條數據流。非管理類IP報文的流量較大，因此需要進一步細分，比如按照源IP地址或者目的IP地址的末位比特(bit)進一步細分報文類型。

需要說明的是，本實施例提供的分流規(guī)則僅為舉例，本申請對此并不限定。

本實施例中，由于對報文進行分類，而不同報文類型的數據流的流量是不同的，造成不同CPU核的負載不同，為了最大化均衡多CPU核的負載，本實施例通過監(jiān)控不同報文類型的數據流的流量，定期(比如每10分鐘)重新計算接收端口的接收隊列與報文類型的分配關系，從而達到一段時間內多核CPU整體上的動態(tài)負載均衡。

一些實現方式中，本實施例的負載均衡方法還可以包括：

步驟204：針對每個接收端口，接收到接收端口的硬件中斷的每個CPU核在報文處理過程時，記錄不同報文類型的數據流的流量；

步驟205：滿足預定條件的CPU核根據預定時長內與接收端口綁定的所有CPU核記錄的不同報文類型的數據流的流量，更新接收端口的接收隊列與報文類型的分配關系。

其中，滿足預定條件的CPU核可以是由Linux操作系統(tǒng)隨機選擇的一個CPU核，或者，可以是整體負載最小的CPU核。本申請對此并不限定。

其中，針對一個接收端口的硬件中斷，與此接收端口綁定的每個CPU核在軟中斷過程中進行報文處理時，會記錄不同報文類型的數據流的流量。每個CPU核記錄的不同報文類型的數據流的流量信息可以存儲在共享存儲區(qū)域，每個CPU核均可以從共享存儲區(qū)域獲取記錄的流量信息?；诖耍P于接收端口的接收隊列與報文類型的分配關系的更新計算過程可以由任一CPU核執(zhí)行。

一些實現方式中，步驟205可以包括：

根據預定時長內與接收端口綁定的所有CPU核記錄的不同報文類型的數據流的流量，計算非管理類IP報文的數據流以及非管理類非IP報文的數據流的流量總和；

根據流量總和以及用于處理報文的CPU核的數目，確定CPU核的平均負載流量；

根據非管理類IP報文的數據流的流量、非管理類非IP報文的數據流的流量以及CPU核的平均負載流量，給非管理類IP報文的數據流以及非管理類非IP報文的數據流指定接收端口的接收隊列，以滿足給每個接收隊列分配的數據流的總流量之間的差值小于或等于閾值。

其中，閾值可以根據實際情況進行設置，較佳地，閾值為0。本申請對此并不限定。

換言之，針對一個接收端口，在給不同報文類型的數據流指定接收隊列之后，每個接收隊列上分配的數據流的總流量較佳地基本相同。

一些實現方式中，步驟205還可以包括：

在給非管理類IP報文的數據流以及非管理類非IP報文的數據流指定接收端口的接收隊列之后，給管理類報文的數據流指定接收端口的索引最大的接收隊列；其中，與接收端口綁定的所有CPU核中的負載最小的CPU核配置為與接收端口的索引最大的接收隊列綁定。

其中，由于管理類報文占用的流量較少，且優(yōu)先級較高，因此，可以指定管理類報文占用索引最大的接收隊列，且將此接收隊列指定給負載相對最小的CPU核。

下面參照圖3，通過一個應用實例對本實施例的多核CPU的負載均衡方法進行舉例說明。本應用實例提供的多核CPU的負載均衡方法可以包括以下步驟：

步驟301：初始化配置所有CPU核與接收端口的硬件中斷綁定，配置CPU核與接收端口的指定接收隊列綁定，生成接收端口的接收隊列與報文類型的默認分配關系，啟動定時器；

其中，根據準備用于報文轉發(fā)的CPU核的數目、接收端口可以使用的接收隊列的數目、分流的細化粒度(比如，將數據流分成若干類)配置相關參數；在完成參數配置后，啟動定時器；

在本應用實例中，初始綁定并開啟所有用于報文轉發(fā)的CPU核到接收端口上，如前所述，Linux源碼不支持接收報文類型的硬件中斷同時上報給多個CPU核，因此，需要根據體系結構進行調整，比如，在ARM體系下修改GIC affinity代碼可實現。

其中，假定使用的CPU核的數目是不變的，CPU核與接收端口的中斷綁定關系配置完成后，不再改變。如果使用的CPU核的數目發(fā)生改變，則需要重新進行初始化配置。

其中，CPU核與接收端口的接收隊列的綁定關系也可以是不變的。需要說明的是，針對管理類報文指定的接收隊列與CPU核之間的綁定關系可以根據需要進行調整，比如，管理類報文指定的接收隊列與整體負載最小的CPU核綁定。

其中，接收端口的接收隊列與報文類型的默認分配關系可以是將不同報文類型的數據流平均分配到接收端口的指定的接收隊列中。比如，接收端口的指定接收隊列為3個，數據流的報文類型為18種，則可以將18種數據流平均分配到3個接收隊列，即每個接收隊列指定接收6種報文類型的數據流。

步驟302：將分流規(guī)則以及接收端口的接收隊列與報文類型的分配關系添加到硬件；其中，當CPU芯片自身支持流分類并可以指定接收隊列時，直接配置CPU芯片的硬件規(guī)則；如果不支持，則通過設置外置交換芯片的分流規(guī)則修改報文優(yōu)先級，然后由CPU芯片的DMA單元根據優(yōu)先級映射到不同接收隊列中。

一些實現方式中，本應用實例中的初始化過程(包括步驟301及步驟302)可以由Linux操作系統(tǒng)自動選擇整體負載最小的CPU核執(zhí)行。

步驟303：硬件分流模塊自動按分流規(guī)則將報文分類，并根據接收端口的接收隊列與報文類型的分配關系轉發(fā)報文到接收端口的指定接收隊列。

步驟304：接收端口收到報文后，產生硬件中斷，同時上報給所有的CPU核。

步驟305：每個CPU核收到硬件中斷后，關閉當前CPU核的硬件中斷，并觸發(fā)當前CPU核的軟中斷。

步驟306：每個CPU核在軟中斷中僅讀取指定給本CPU核的接收隊列的報文；由于每個CPU核僅讀取指定接收隊列的報文，因此，不會產生競爭和沖突。

步驟307：每個CPU核在處理報文過程中，記錄不同數據流的流量；其中，可選記錄報文數或報文的總字節(jié)數，一般而言，路由器等設備的CPU轉發(fā)能力受限于報文數，與報文大小關系不大。

步驟308：每個CPU核在報文處理完畢后，打開本CPU核的接收端口的硬件中斷，等待下一個收包中斷。

步驟309：每個CPU核記錄的流量數據保存在共享存儲區(qū)域；

步驟310：定時器每隔10分鐘提示檢查不同報文類型的數據流的流量，CPU核更新接收端口的接收隊列與報文類型的分配關系。

其中，步驟310的分配關系更新過程可以由任一CPU核或者整體負載最小的CPU核執(zhí)行，在確定更新后的分配關系之后，可以將更新后的分配關系寫入硬件(比如，CPU芯片的寄存器或外置交換芯片)。之后，在步驟303中，硬件分流模塊可以根據更新后的分配關系轉發(fā)報文，如此，通過不同報文類型的數據流與接收隊列的分配關系的改變，達到CPU核的負載均衡；通過定時器計時實現分配關系的周期性更新，達到多核負載的動態(tài)均衡。

下面對步驟301中接收端口的接收隊列與報文類型的默認分配關系的確定過程以及步驟310中接收端口的接收隊列與報文類型的分配關系的更新過程采用的均衡算法進行舉例說明。

在本應用實例中，報文的分流規(guī)則如下：

匹配管理類報文，比如OAM(Operation Administration and Maintenance，操作管理維護)、RSTP(Rapid Spanning Tree Protocol，快速生成樹協(xié)議)等，設置流索引index_mng；需要說明的是，上述管理類報文僅為舉例，在實際應用中，可以根據實際需求確定需要匹配的管理類報文，比如其他的路由發(fā)現協(xié)議報文以及其他發(fā)送至設備本地的報文等；

匹配非管理類非IP報文，比如ARP(Address Resolution Protocol，地址解析協(xié)議)，設置流索引index_noip；

匹配非管理類IP報文，其中，按源IP第4字節(jié)低位n比特(bit)，值為x；目的IP第4字節(jié)低位m bit，值為y；x和y組成匹配字z，z＝((x<<m)|y)，可匹配2^(m+n)條流，設置每條流的索引為index_z；其中，|表示按位或，<<表示左移運算符。

在本應用實例中，index是index_z，index_mng，index_noip的集合；每條流對應的流量數組可以用flow[index]表示，其中，可以用包數作為單位。

以一個接收端口共r個可用接收隊列，用于處理報文的CPU核的數目為s個為例，其中，s<＝r，2^(m+n)+2>＝s。

每個接收隊列綁定的CPU核的計算過程可以用cpu(queue)表示。比如，每個CPU核綁定一個接收隊列即可，如CPU0綁定接收隊列0。因此，接收端口實際使用的接收隊列數目為t＝s+1。即，初始化時綁定s個CPU核與s個接收隊列，在確定每個CPU核的負載之后，將剩余的索引最高的接收隊列綁定至負載最小的CPU核。同一個CPU核綁定的多個接收隊列中，接收隊列的索引越大，優(yōu)先級越高。比如，在雙核CPU中，雖然一個接收端口的可用接收隊列有8個，但在實際使用時，可以僅使用3個接收隊列，其中兩個接收隊列用于接收非管理類非IP報文的數據流以及非管理類IP報文的數據流，索引最高的接收隊列用于接收管理類報文的數據流。

給每種報文類型的數據流指定接收隊列的計算過程可以用queue(index)表示。要求計算結果符合，每個接收隊列中包含的數據流的流量總和大體相等。

下面參照圖4說明為不同報文類型的數據流指定接收隊列的一種可選計算方式。按照前述的分流規(guī)則，建立了2^(m+n)+2條規(guī)則來進行分流，設N＝2^(m+n)+2，即可以區(qū)分N種報文類型的數據流。這些報文類型的數據流按照流量由大到小進行排序，可以將每種報文類型的數據流的流量分別標記為A₁、A₂……、A_N；一個接收端口可以使用的接收隊列為r個，則這些接收隊列可以標記為R₁、R₂……、R_r，R_b表示第b個接收隊列，第b個接收隊列的流量表示為T_b。b大于或等于1且小于或等于r。

其中，對非管理類IP報文的所有數據流和非管理類非IP報文的數據流的流量求和，比如，表示為sum(flow[index_z]+flow[index_noip])；根據下式計算每個CPU核需要承擔的平均負載流量：

ave()＝sum(flow[index_z]+flow[index_noip])/s，其中，s表示用于處理報文的CPU核的數目。

如圖4所示，當ave()等于0時，即此時生成默認分配關系，將N種報文類型的數據流平均分配給r個接收隊列，或者，當接收端口實際使用的接收隊列為t個時，可以將N種報文類型的數據流平均分配給t個接收隊列。

當ave()不等于0時，可以按照以下方式進行分配：將第a種報文類型的數據流指定給接收隊列R_b，其中，a大于或等于1且小于或等于N；此時，T_b＝A_a，判斷第b個接收隊列的流量T_b是否大于或等于ave()，若T_b大于或等于ave()，則可以判斷下一種報文類型的數據流如何分配，若T_b小于ave()，則需要將流量排序中處于最后的報文類型的數據流的流量加入第b個接收隊列，再判斷第b個接收隊列的總流量是否大于或等于ave()，若T_b仍小于ave()，則將流量排序為倒數第二的報文類型的數據流的流量，直至第b個接收隊列的總流量大于或等于ave()。

換言之，將N種報文類型的數據流按照流量由大到小進行排序，可以將每種報文類型的數據流的流量分別標記為A₁、A₂……、A_N；A_N為最小流量；如果A₁大于或等于ave()，則將流量A₁對應的報文類型指定給接收隊列0，繼續(xù)判斷流量A₂和ave()的大小，根據判斷結果，給流量A₂對應的報文類型指定接收隊列；如果A₁小于ave()，則判斷A₁+A_N是否大于或等于ave()，如果是，則將流量A₁和A_N對應的報文類型指定給接收隊列0，繼續(xù)判斷流量A₂和ave()的大小，根據判斷結果，給流量A₂對應的報文類型指定接收隊列；如果A₁+A_N小于ave()，則判斷流量A₁+A_N+A_N-1和ave()的大小，根據判斷結果，給相應流量對應的報文類型指定接收隊列；后續(xù)通過迭代方式依次進行計算。

需要說明的是，在一些實現方式中，如果A₁+A_N小于ave()，則可以依次判斷大于流量A₁+A_N的流量(比如，流量A₁+A_N-1、流量A₁+A_N-2)和ave()的大??；在兩個流量(A₁與排序中的任一其他報文類型的數據流的流量)之和均不滿足大于或等于ave()時，再繼續(xù)判斷三個流量之和(比如，流量A₁+A_N+A_N-1)和ave()的大小；通過迭代方式依次進行計算，以確定每種報文類型指定的接收隊列。

需要說明的是，本申請采用的均衡算法并不限定于此。本申請還可以采用其他均衡算法，最終能夠確定每個接收隊列指定的報文類型的數據流的流量總和大體相等即可。

需要注意的是，管理類報文單獨占用索引最大的接收隊列，管理類報文的流量較少且優(yōu)先級高，因此，可以指定給負載相對最小的CPU核。

其中，接收端口的接收隊列、CPU核可以根據實際芯片的支持數目確定，分流粒度受限于CPU芯片或外置交換芯片的分流規(guī)則的支持能力，可自由設置。如圖5所示，以雙核CPU、8個接收隊列、預計分流粒度為16+2條為例，可掩碼SIP(Source IP)的末位2比特(bit)，DIP(Destination IP)的末位2bit，建立18條規(guī)則。初始綁定CPU0至接收隊列0，CPU1綁定至接收隊列1，然后，可以根據監(jiān)控得到的流量數據，計算得到部分非管理類IP報文的數據流進入接收隊列0，其余非管理類IP報文的數據流以及非管理類非IP報文的數據流進入接收隊列1，管理類報文的數據流進入接收隊列7，并綁定CPU1與接收隊列7。即，在本例中，s＝2，r＝8，t＝3(即實際使用了3個接收隊列)，2^(m+n)+2＝16+2，m+n＝4。

綜上所述，本實施例將接收端口接收報文后產生的硬件中斷輸出到所有綁定的CPU核，然后每個CPU核再選擇指定的接收隊列收取報文，從而有效改善多核效率，提高設備的轉發(fā)性能；通過硬件預分流代替軟件分流，可以避免引入分流產生的CPU的額外開銷；而且，通過定期監(jiān)控每種報文類型的數據流的流量，周期性更新接收端口的接收隊列與報文類型的分配關系，從而實現負載動態(tài)均衡。

實施例二、一種多核CPU的負載均衡裝置，如圖6所示，包括：

硬件分流模塊601、接收端口602以及至少兩個CPU核(比如，CPU核603a和603b)；其中，每個接收端口602配置為與至少兩個CPU核(比如，CPU核603a和603b)綁定，與同一個接收端口602綁定的CPU核配置為分別綁定接收端口602的一個或多個接收隊列；

硬件分流模塊601，用于針對每個接收端口602，根據分流規(guī)則將報文分類，并根據接收端口602的接收隊列與報文類型的分配關系，將報文轉發(fā)至與報文所屬的報文類型存在分配關系的接收隊列；

接收端口602，用于在接收到報文后，產生硬件中斷，并將硬件中斷同時上報給與接收端口602綁定的所有CPU核(比如，CPU核603a和603b)；

接收到硬件中斷的每個CPU核(比如，CPU核603a和603b)，用于在軟中斷處理過程中，從與本CPU核綁定的接收隊列讀取報文。

一些實現方式中，硬件分流模塊601至少包括CPU芯片的硬件分類單元以及DMA單元；其中，硬件分類單元，用于根據分流規(guī)則將報文分類；DMA單元，用于根據接收端口的接收隊列與報文類型的分配關系，將報文轉發(fā)至與此報文所屬的報文類型存在分配關系的接收隊列。

一些實現方式中，硬件分流模塊601包括外置交換芯片、CPU芯片的硬件分類單元以及DMA單元；其中，外置交換芯片，用于根據分流規(guī)則將報文分類，并根據接收端口的接收隊列與報文類型的分配關系，修改報文的優(yōu)先級，并將報文發(fā)送給硬件分類單元；硬件分類單元，用于匹配報文的優(yōu)先級；DMA單元，用于將報文轉發(fā)至對應優(yōu)先級的接收隊列。

一些實現方式中，分流規(guī)則可以包括：

匹配報文為以下任一大類：管理類報文、非管理類IP報文、非管理類非IP報文；

在報文屬于非管理類IP報文時，按照報文的IP地址，細分報文所屬的報文類型。

一些實現方式中，CPU核(比如，CPU核603a或者603b)，還用于在接收到接收端口602的硬件中斷后，在報文處理過程中，記錄不同報文類型的數據流的流量；滿足預定條件的CPU核(比如，CPU核603a或者603b)，還用于根據預定時長內與接收端口602綁定的所有CPU核記錄的不同報文類型的數據流的流量，更新接收端口602的接收隊列與報文類型的分配關系。

一些實現方式中，滿足預定條件的CPU核(比如，CPU核603a或者603b)，用于根據預定時長內與接收端口602綁定的所有CPU核記錄的不同報文類型的數據流的流量，計算非管理類IP報文的數據流以及非管理類非IP報文的數據流的流量總和；根據流量總和以及用于處理報文的CPU核的數目，確定CPU核的平均負載流量；根據非管理類IP報文的數據流的流量、非管理類非IP報文的數據流的流量以及CPU核的平均負載流量，給非管理類IP報文的數據流以及非管理類非IP報文的數據流指定接收端口602的接收隊列，以滿足給每個接收隊列分配的數據流的總流量之間的差值小于或等于閾值。

一些實現方式中，滿足預定條件的CPU核(比如，CPU核603a或者603b)，還用于在給非管理類IP報文的數據流以及非管理類非IP報文的數據流指定所述接收端口的接收隊列之后，給管理類報文的數據流指定接收端口602的索引最大的接收隊列；其中，與接收端口602綁定的所有CPU核中的負載最小的CPU核配置為與接收端口602的索引最大的接收隊列綁定。

關于本實施例提供的多核CPU的負載均衡裝置的詳細處理流程可以參照實施例一描述的多核CPU的負載均衡方法，故于此不再贅述。

本領域普通技術人員可以理解上述方法中的部分步驟可通過程序來指令相關硬件(例如處理器)完成，所述程序可以存儲于計算機可讀存儲介質中，如只讀存儲器、磁盤或光盤等?？蛇x地，上述實施例的全部或部分步驟也可以使用一個或多個集成電路來實現。相應地，上述實施例中的各模塊/單元可以采用硬件的形式實現，例如通過集成電路來實現其相應功能，也可以采用軟件功能模塊的形式實現，例如通過處理器執(zhí)行存儲于存儲器中的程序/指令來實現其相應功能。本申請不限制于任何特定形式的硬件和軟件的結合。

以上顯示和描述了本申請的基本原理和主要特征和本申請的優(yōu)點。本申請不受上述實施例的限制，上述實施例和說明書中描述的只是說明本申請的原理，在不脫離本申請精神和范圍的前提下，本申請還會有各種變化和改進，這些變化和改進都落入要求保護的本申請范圍內。