linux多隊列網卡
⑴ 怎樣查看 linux 的網卡信息
查看 linux 的網卡信息步驟如下：
工具原料：linux操作系統
①啟動 linux 操作系統，進入到桌面；
④linux 的網卡信息解讀：
1.查看網卡生產廠商和信號：
查看基本信息：lspci
查看詳細信息：lspci -vvv # 3個小寫的v
查看網卡信息：lspci | grep Ethernet；
2.查看網卡驅動：
查看網卡驅動信息：lspci -vvv # 找到網卡設備的詳細信息，包括網卡驅動
# lsmod 列出載入的所有驅動，包括網卡驅動；
3.查看網卡驅動版本
查看模塊信息：modifo<mole name> # 其中包含version信息或 # ethtool-i <device name>；
4.查看網路介面隊列數
查看網卡介面的中斷信息：#cat /proc/interrupts | grep eth0或 # ethtool-S eth0；
5.查看網卡驅動源碼的版本號
解壓Intel網卡驅動源碼，打開解壓縮目錄下的*.spec文件查看驅動的版本；
⑵ 如何使用Linux工作隊列workqueue
創建一個per-CPU *編譯期間靜態創建一個per-CPU DEFINE_PER_CPU(type, name) 創建一個名為name,數據類型為type的per-CPU,比如static DEFINE_PER_CPU(struct sk_buff_head, bs_cpu_queues)，此時每個CPU都有一個名叫bs_cpu_queues，數據結構為sk_buff_head的變數副本。每個副本都是在自己的CPU上工作。 * 動態創建per-CPU,以下代碼是內核create_workqueue實現的片斷 struct workqueue_struct *__create_workqueue(const char *name, int singlethread) { int cpu, destroy = 0; struct workqueue_struct *wq; struct task_struct *p; wq = kzalloc(sizeof(*wq), GFP_KERNEL); if (!wq) return NULL; wq->cpu_wq = alloc_percpu(struct cpu_workqueue_struct); if (!wq->cpu_wq) { kfree(wq); return NULL; } …… }創建一個名為name,數據類型為type的per-CPU,比如static DEFINE_PER_CPU(struct sk_buff_head, bs_cpu_queues)，此時每個CPU都有一個名叫bs_cpu_queues，數據結構為sk_buff_head的變數副本。每個副本都是在自己的CPU上工作。Linux 2.6內核使用了不少工作隊列來處理任務，他在使用上和 tasklet最大的不同是工作隊列的函數可以使用休眠，而tasklet的函數是不允許使用休眠的。工作隊列的使用又分兩種情況，一種是利用系統共享的工作隊列來添加自己的工作，這種情況處理函數不能消耗太多時間，這樣會影響共享隊列中其他任務的處理;另外一種是創建自己的工作隊列並添加工作。第二步：創建一個工作結構體變數，並將處理函數和參數的入口地址賦給這個工作結構體變數如果不想要在編譯時就用DECLARE_WORK()創建並初始化工作結構體變數，也可以在程序運行時再用INIT_WORK()創建struct work_struct my_work; //創建一個名為my_work的結構體變數，創建後才能使用INIT_WORK()INIT_WORK(&my_work,my_func,&data); //初始化已經創建的my_work，其實就是往這個結構體變數中添加處理函數的入口地址和data的地址，通常在驅動的open函數中完成INIT_WORK(&my_work, my_func, &data); //創建一個工作結構體變數並初始化，和第一種情況的方法一樣//作用與schele_work()類似，不同的是將工作添加入p_queue指針指向的工作隊列而不是系統共享的工作隊列work queue是一種bottom half，中斷處理的後半程，強調的是動態的概念，即work是重點，而queue是其次。wait queue是一種「任務隊列」，可以把一些進程放在上面睡眠等待某個事件，強調靜態多一些，重點在queue上，即它就是一個queue，這個queue如何調度，什麼時候調度並不重要等待隊列在內核中有很多用途，尤其適合用於中斷處理，進程同步及定時。這里只說，進程經常必須等待某些事件的發生。例如，等待一個磁碟操作的終止，等待釋放系統資源，或者等待時間經過固定的間隔。等待隊列實現了在事件上的條件等待，希望等待特定事件的進程把放進合適的等待隊列，並放棄控制權。因此。等待隊列表示一組睡眠的進程，當某一條件為真時，由內核喚醒進程。等待隊列由循環鏈表實現，其元素包括指向進程描述符的指針。每個等待隊列都有一個等待隊列頭，等待隊列頭是一個類型為wait_queue_head_t的數據結構。等待隊列鏈表的每個元素代表一個睡眠進程，該進程等待某一事件的發生，描述符地址存放在task欄位中。然而，要喚醒等待隊列中所有的進程有時並不方便。例如，如果兩個或多個進程在等待互斥訪問某一個要釋放的資源，僅喚醒等待隊列中一個才有意義。這個進程佔有資源，而其他進程繼續睡眠可以用DECLARE_WAIT_QUEUE_HEAD(name)宏定義一個新的等待隊列，該宏靜態地聲明和初始化名為name的等待隊列頭變數。 init_waitqueue_head()函數用於初始化已動態分配的wait queue head變數等待隊列可以通過DECLARE_WAITQUEUE()靜態創建，也可以用init_waitqueue_head()動態創建。進程放入等待隊列並設置成不可執行狀態。工作隊列，workqueue，它允許內核代碼來請求在將來某個時間調用一個函數。用來處理不是很緊急事件的回調方式處理方法.工作隊列的作用就是把工作推後,交由一個內核線程去執行，更直接的說就是寫了一個函數,而現在不想馬上執行它，需要在將來某個時刻去執行，那就得用工作隊列准沒錯。如果需要用一個可以重新調度的實體來執行下半部處理，也應該使用工作隊列。是唯一能在進程上下文運行的下半部實現的機制。這意味著在需要獲得大量的內存時、在需要獲取信號量時，在需要執行阻塞式的I/O操作時，都會非常有用。
⑶ 在Linux 上，編寫一個每秒接收 100萬UDP數據包的程序究竟有多難
首先，我們假設：
測量每秒的數據包(pps)比測量每秒位元組數(Bps)更有意思。您可以通過更好的管道輸送以及發送更長數據包來獲取更高的Bps。而相比之下，提高pps要困難得多。
因為我們對pps感興趣，我們的實驗將使用較短的 UDP 消息。准確來說是 32 位元組的 UDP 負載，這相當於乙太網層的 74 位元組。
在實驗中，我們將使用兩個物理伺服器：「接收器」和「發送器」。
它們都有兩個六核2 GHz的 Xeon處理器。每個伺服器都啟用了 24 個處理器的超線程(HT)，有 Solarflare 的 10G 多隊列網卡，有 11 個接收隊列配置。稍後將詳細介紹。
測試程序的源代碼分別是：udpsender、udpreceiver。
預備知識
我們使用4321作為UDP數據包的埠，在開始之前，我們必須確保傳輸不會被iptables干擾：
Shell
receiver$ iptables -I INPUT 1 -p udp --dport 4321 -j ACCEPT
receiver$ iptables -t raw -I PREROUTING 1 -p udp --dport 4321 -j NOTRACK
為了後面測試方便，我們顯式地定義IP地址：
Shell
receiver$ for i in `seq 1 20`; do
ip addr add 192.168.254.$i/24 dev eth2;
done
sender$ ip addr add 192.168.254.30/24 dev eth3
1. 簡單的方法
開始我們做一些最簡單的試驗。通過簡單地發送和接收，有多少包將會被傳送？
模擬發送者的偽代碼：
Python
fd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
fd.bind(("0.0.0.0", 65400)) # select source port to rece nondeterminism
fd.connect(("192.168.254.1", 4321))
while True:
fd.sendmmsg(["x00" * 32] * 1024)
因為我們使用了常見的系統調用的send，所以效率不會很高。上下文切換到內核代價很高所以最好避免它。幸運地是，最近Linux加入了一個方便的系統調用叫sendmmsg。它允許我們在一次調用時，發送很多的數據包。那我們就一次發1024個數據包。
模擬接受者的偽代碼：
Python
fd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
fd.bind(("0.0.0.0", 4321))
while True:
packets = [None] * 1024
fd.recvmmsg(packets, MSG_WAITFORONE)
同樣地，recvmmsg 也是相對於常見的 recv 更有效的一版系統調用。
讓我們試試吧：
Shell
sender$ ./udpsender 192.168.254.1:4321
receiver$ ./udpreceiver1 0.0.0.0:4321
0.352M pps 10.730MiB / 90.010Mb
0.284M pps 8.655MiB / 72.603Mb
0.262M pps 7.991MiB / 67.033Mb
0.199M pps 6.081MiB / 51.013Mb
0.195M pps 5.956MiB / 49.966Mb
0.199M pps 6.060MiB / 50.836Mb
0.200M pps 6.097MiB / 51.147Mb
0.197M pps 6.021MiB / 50.509Mb
測試發現，運用最簡單的方式可以實現 197k – 350k pps。看起來還不錯嘛，但不幸的是，很不穩定啊，這是因為內核在核之間交換我們的程序，那我們把進程附在 CPU 上將會有所幫助
Shell
sender$ taskset -c 1 ./udpsender 192.168.254.1:4321
receiver$ taskset -c 1 ./udpreceiver1 0.0.0.0:4321
0.362M pps 11.058MiB / 92.760Mb
0.374M pps 11.411MiB / 95.723Mb
0.369M pps 11.252MiB / 94.389Mb
0.370M pps 11.289MiB / 94.696Mb
0.365M pps 11.152MiB / 93.552Mb
0.360M pps 10.971MiB / 92.033Mb
現在內核調度器將進程運行在特定的CPU上，這提高了處理器緩存，使數據更加一致，這就是我們想要的啊！
2. 發送更多的數據包
雖然 370k pps 對於簡單的程序來說已經很不錯了，但是離我們 1Mpps 的目標還有些距離。為了接收更多，首先我們必須發送更多的包。那我們用獨立的兩個線程發送，如何呢：
Shell
sender$ taskset -c 1,2 ./udpsender
192.168.254.1:4321 192.168.254.1:4321
receiver$ taskset -c 1 ./udpreceiver1 0.0.0.0:4321
0.349M pps 10.651MiB / 89.343Mb
0.354M pps 10.815MiB / 90.724Mb
0.354M pps 10.806MiB / 90.646Mb
0.354M pps 10.811MiB / 90.690Mb
接收一端的數據沒有增加，ethtool –S 命令將顯示數據包實際上都去哪兒了：
Shell
receiver$ watch 'sudo ethtool -S eth2 |grep rx'
rx_nodesc_drop_cnt: 451.3k/s
rx-0.rx_packets: 8.0/s
rx-1.rx_packets: 0.0/s
rx-2.rx_packets: 0.0/s
rx-3.rx_packets: 0.5/s
rx-4.rx_packets: 355.2k/s
rx-5.rx_packets: 0.0/s
rx-6.rx_packets: 0.0/s
rx-7.rx_packets: 0.5/s
rx-8.rx_packets: 0.0/s
rx-9.rx_packets: 0.0/s
rx-10.rx_packets: 0.0/s
通過這些統計，NIC 顯示 4 號 RX 隊列已經成功地傳輸大約 350Kpps。rx_nodesc_drop_cnt 是 Solarflare 特有的計數器，表明NIC發送到內核未能實現發送 450kpps。
有時候，這些數據包沒有被發送的原因不是很清晰，然而在我們這種情境下卻很清楚：4號RX隊列發送數據包到4號CPU，然而4號CPU已經忙不過來了，因為它最忙也只能讀350kpps。在htop中顯示為：
多隊列 NIC 速成課程
從歷史上看，網卡擁有單個RX隊列，用於硬體和內核之間傳遞數據包。這樣的設計有一個明顯的限制，就是不可能比單個CPU處理更多的數據包。
為了利用多核系統，NIC開始支持多個RX隊列。這種設計很簡單：每個RX隊列被附到分開的CPU上，因此，把包送到所有的RX隊列網卡可以利用所有的CPU。但是又產生了另一個問題：對於一個數據包，NIC怎麼決定把它發送到哪一個RX隊列？
用 Round-robin 的方式來平衡是不能接受的，因為這有可能導致單個連接中數據包的重排序。另一種方法是使用數據包的hash值來決定RX號碼。Hash值通常由一個元組（源IP，目標IP，源port，目標port）計算而來。這確保了從一個流產生的包將最終在完全相同的RX隊列，並且不可能在一個流中重排包。
在我們的例子中，hash值可能是這樣的：
Shell
1
RX_queue_number = hash('192.168.254.30', '192.168.254.1', 65400, 4321) % number_of_queues
多隊列 hash 演算法
Hash演算法通過ethtool配置，設置如下：
Shell
receiver$ ethtool -n eth2 rx-flow-hash udp4
UDP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA
對於IPv4 UDP數據包，NIC將hash(源 IP,目標 IP)地址。即
Shell
1
RX_queue_number = hash('192.168.254.30', '192.168.254.1') % number_of_queues
這是相當有限的，因為它忽略了埠號。很多NIC允許自定義hash。再一次，使用ethtool我們可以選擇元組(源 IP、目標 IP、源port、目標port)生成hash值。
Shell
receiver$ ethtool -N eth2 rx-flow-hash udp4 sdfn
Cannot change RX network flow hashing options: Operation not supported
不幸地是，我們的NIC不支持自定義，我們只能選用(源 IP、目的 IP) 生成hash。
NUMA性能報告
到目前為止，我們所有的數據包都流向一個RX隊列，並且一個CPU。我們可以借這個機會為基準來衡量不同CPU的性能。在我們設置為接收方的主機上有兩個單獨的處理器，每一個都是一個不同的NUMA節點。
在我們設置中，可以將單線程接收者依附到四個CPU中的一個，四個選項如下：
另一個CPU上運行接收器，但將相同的NUMA節點作為RX隊列。性能如上面我們看到的，大約是360 kpps。
將運行接收器的同一 CPU 作為RX隊列，我們可以得到大約430 kpps。但這樣也會有很高的不穩定性，如果NIC被數據包所淹沒，性能將下降到零。
當接收器運行在HT對應的處理RX隊列的CPU之上，性能是通常的一半，大約在200kpps左右。
接收器在一個不同的NUMA節點而不是RX隊列的CPU上，性能大約是330 kpps。但是數字會不太一致。
雖然運行在一個不同的NUMA節點上有10%的代價，聽起來可能不算太壞，但隨著規模的變大，問題只會變得更糟。在一些測試中，每個核只能發出250 kpps，在所有跨NUMA測試中，這種不穩定是很糟糕。跨NUMA節點的性能損失，在更高的吞吐量上更明顯。在一次測試時，發現在一個壞掉的NUMA節點上運行接收器，性能下降有4倍。
3.多接收IP
因為我們NIC上hash演算法的限制，通過RX隊列分配數據包的唯一方法是利用多個IP地址。下面是如何將數據包發到不同的目的IP：
1
sender$ taskset -c 1,2 ./udpsender 192.168.254.1:4321 192.168.254.2:4321
ethtool 證實了數據包流向了不同的 RX 隊列：
Shell
receiver$ watch 'sudo ethtool -S eth2 |grep rx'
rx-0.rx_packets: 8.0/s
rx-1.rx_packets: 0.0/s
rx-2.rx_packets: 0.0/s
rx-3.rx_packets: 355.2k/s
rx-4.rx_packets: 0.5/s
rx-5.rx_packets: 297.0k/s
rx-6.rx_packets: 0.0/s
rx-7.rx_packets: 0.5/s
rx-8.rx_packets: 0.0/s
rx-9.rx_packets: 0.0/s
rx-10.rx_packets: 0.0/s
接收部分：
Shell
receiver$ taskset -c 1 ./udpreceiver1 0.0.0.0:4321
0.609M pps 18.599MiB / 156.019Mb
0.657M pps 20.039MiB / 168.102Mb
0.649M pps 19.803MiB / 166.120Mb
萬歲！有兩個核忙於處理RX隊列，第三運行應用程序時，可以達到大約650 kpps !
我們可以通過發送數據到三或四個RX隊列來增加這個數值，但是很快這個應用就會有另一個瓶頸。這一次rx_nodesc_drop_cnt沒有增加，但是netstat接收到了如下錯誤：
Shell
receiver$ watch 'netstat -s --udp'
Udp:
437.0k/s packets received
0.0/s packets to unknown port received.
386.9k/s packet receive errors
0.0/s packets sent
RcvbufErrors: 123.8k/s
SndbufErrors: 0
InCsumErrors: 0
這意味著雖然NIC能夠將數據包發送到內核，但是內核不能將數據包發給應用程序。在我們的case中，只能提供440 kpps，其餘的390 kpps + 123 kpps的下降是由於應用程序接收它們不夠快。
4.多線程接收
我們需要擴展接收者應用程序。最簡單的方式是利用多線程接收，但是不管用：
Shell
sender$ taskset -c 1,2 ./udpsender 192.168.254.1:4321 192.168.254.2:4321
receiver$ taskset -c 1,2 ./udpreceiver1 0.0.0.0:4321 2
0.495M pps 15.108MiB / 126.733Mb
0.480M pps 14.636MiB / 122.775Mb
0.461M pps 14.071MiB / 118.038Mb
0.486M pps 14.820MiB / 124.322Mb
接收性能較於單個線程下降了，這是由UDP接收緩沖區那邊的鎖競爭導致的。由於兩個線程使用相同的套接字描述符，它們花費過多的時間在UDP接收緩沖區的鎖競爭。這篇論文詳細描述了這一問題。
看來使用多線程從一個描述符接收，並不是最優方案。
5. SO_REUSEPORT
幸運地是，最近有一個解決方案添加到 Linux 了 —— SO_REUSEPORT 標志位（flag）。當這個標志位設置在一個套接字描述符上時，Linux將允許許多進程綁定到相同的埠，事實上，任何數量的進程將允許綁定上去，負載也會均衡分布。
有了SO_REUSEPORT，每一個進程都有一個獨立的socket描述符。因此每一個都會擁有一個專用的UDP接收緩沖區。這樣就避免了以前遇到的競爭問題：
Shell
1
2
3
4
receiver$ taskset -c 1,2,3,4 ./udpreceiver1 0.0.0.0:4321 4 1
1.114M pps 34.007MiB / 285.271Mb
1.147M pps 34.990MiB / 293.518Mb
1.126M pps 34.374MiB / 288.354Mb
現在更加喜歡了，吞吐量很不錯嘛！
更多的調查顯示還有進一步改進的空間。即使我們開始4個接收線程，負載也會不均勻地分布：
兩個進程接收了所有的工作，而另外兩個根本沒有數據包。這是因為hash沖突，但是這次是在SO_REUSEPORT層。
結束語
我做了一些進一步的測試，完全一致的RX隊列，接收線程在單個NUMA節點可以達到1.4Mpps。在不同的NUMA節點上運行接收者會導致這個數字做多下降到1Mpps。
總之，如果你想要一個完美的性能，你需要做下面這些：
確保流量均勻分布在許多RX隊列和SO_REUSEPORT進程上。在實踐中，只要有大量的連接(或流動)，負載通常是分布式的。
需要有足夠的CPU容量去從內核上獲取數據包。
To make the things harder, both RX queues and receiver processes should be on a single NUMA node.
為了使事情更加穩定，RX隊列和接收進程都應該在單個NUMA節點上。
雖然我們已經表明，在一台Linux機器上接收1Mpps在技術上是可行的，但是應用程序將不會對收到的數據包做任何實際處理——甚至連看都不看內容的流量。別太指望這樣的性能，因為對於任何實際應用並沒有太大用處。
⑷ Linux多線程同步之消息隊列有何特點
消息隊列是消息的鏈表，存放在內核中並有消息隊列標示符標示。
msgget用於創建一個新隊列或打開一個現存的隊列。msgsnd將新消息加入到消息隊列中；每個
消息包括一個long型的type；和消息緩存；msgrcv用於從隊列中取出消息；取消息很智能，不一定先進先出
①msgget，創建一個新隊列或打開一個現有隊列
#include
int msgget ( key_t key, int flag )；
//成功返回消息隊列ID；錯誤返回-1
②msgsnd: 發送消息
#include
int msgsnd( int msgid, const void* ptr, size_t nbytes, int flag )
//成功返回0，錯誤返回-1
a:
flag可以指定為IPC_NOWAIT;
若消息隊列已滿，則msgsnd立即出錯返回EABAIN；
若沒指定IPC_NOWAIT； msgsnd會阻塞，直到消息隊列有空間為止
③msgrcv: 讀取消息：
ssize_t msgrcv( int msgid, void* ptr, size_t nbytes, long type, int flag );
a. type == 0; 返回消息隊列中第一個消息，先進先出
b. type > 0
返回消息隊列中類型為tpye的第一個消息
c. type < 0
返回消息隊列中類型 <=
|type| 的數據；若這種消息有若干個，則取類型值最小的消息
消息隊列創建步驟：
#define
MSG_FILE "."
struct msgtype {
long mtype;
char buffer[BUFFER+1];
};
if((key=ftok(MSG_FILE,'a'))==-1)
{
fprintf(stderr,"Creat Key Error:%s\n", strerror(errno));
exit
(1);
}
if((msgid=msgget(key, IPC_CREAT | 0666/*PERM*/))==-1)
{
fprintf(stderr,"Creat Message
Error:%s\n", strerror(errno));
exit
(1);
}
⑸ linux多隊列網卡始終只有一個隊列收包是怎麼回事
答：很多無線網卡都很難知道它們的晶元是什麼??我買了好幾個54M的網卡都不行,分別是:BLEKINF5D700BUFFALOWLI2-PCI-G54。