netmap源码读后感（第二版）

netmap源码，短小精悍，精读多遍，获益匪浅。netmap宣称的10G NIC上的14.88 Mpps高性能，也正是我们所追求的（从linux内核协议栈所追求不到的）：

netmap / VALE is a framework for high speed packet I/O. Implemented as a kernel module for FreeBSD and Linux, it supports access to network cards (NICs), host stack, virtual ports (the "VALE" switch), and "netmap pipes". netmap can easily do line rate on 10G NICs (14.88 Mpps), moves over 20 Mpps on VALE ports, and over 100 Mpps on netmap pipes.

本文分享我们对netmap（不涉及VALE）的理解（如有错误，还望指正，谢谢）。我们针对netmap自身独特的那些特点，逐一分析。（为方便说明，以下仅考虑收包操作）

1 控制权的转移

这个控制权，针对的是收发包处理的控制权。以收包为例，在softirq有精细控制：一次softirq里最多收多少包，一个网卡又最多收多少包，这些控制都是在napi方式的poll函数里完成的。而在netmap里呢，这个控制权，从softirq移交至app（这个app，可以是进程，也可以是线程）。

毕竟netmap另辟新径，旁路了协议栈，这样app就成了主角。app通过调用nm_nextpkt()来控制收包的节奏：

struct nm_desc是一个控制块，管理本app（同上，可以是进程，也可是线程）所涉及的所有队列（这些队列可能属于不同网卡）。app通过NETMAP_BUF()直接收包，自然就掌控了收包的节奏。

2 无锁化

app多线程和多网卡多队列的对应关系的分散化处理，避免了锁的引入。当然，如果一定要重叠（比如多个线程处理同一个网卡的同一个队列），还是避免不了的。同时操作同一个队列是需要保护的，使用nm_kr_tryget()来保证：

不过app由用户定制，用户应该会做出明智决定。

多队列技术将流量分散到各个队列，也就是各个app，分散方式自然是用到了hash（硬件实现），比如tcp包，就是基于sip+dip+sport+dport。对终端设备（通信的两端端点，不是手机。。。）来说没问题，但是对于中间设备（比如防火墙）就有来回两个方向流量需要归属同一个线程的问题了（可以软件解决）。

3 零拷贝

显然，使用mmap技术使得app和内核（模块）同时操作数据，大大减少了用户态和内核之间的拷贝操作。针对收包过程而言，全过程仅有dma必需的一次拷贝动作（不考虑app可能的对包的其它clone处理）：

此处要注意的是，netmap的ring和内核nic驱动的ring，这样的两个ring，其实同时操作的只是同一块dma内存，这块内存是零拷贝核心所在。

4 app的poll

显然，一个app监控多个队列的动作自然要用poll，但是poll不是只能监控fd么？其实netmap提供了将队列转为fd的方式：

其实，这就是设备文件的意义所在。

5 问题

比如网卡中断到cpu（线程）的分发、已经numa绑定等问题，netmap没有处理，应该是希望把这个控制权留给用户或者内核。

总的看来，netmap旨是在提供一个高效的网卡驱动层，至于上面的协议栈层或者用户其它应用则需要用户另外搭建了。。。

转自:

http://mp.weixin.qq.com/s?__biz=MzAxNjM3MDkyOQ==&mid=207207754&idx=1&sn=1cd2e6656fba2b5d8ee740f460f61463&scene=21#wechat_redirect