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。