又见南风的博客

深入理解Linux网络（八）：内核如何发送网络包一、总览二、网卡启动准备三、ACCEPT 创建新 SOCKET四、开始发送数据send 系统调⽤实现传输层处理传输层拷贝传输层发送网络层发送原理邻居⼦系统网络设备子系统软中断调度igb网卡驱动发送发送完成硬件中断五、问题一、总览⽤户数据被拷⻉到内核态，然后经过协议栈处理后进⼊到了 RingBuffer 中。随后⽹卡驱动真正将数据发送了出去。当发送完成，硬中断来通知 CPU 触发清理 RingBuffer 的代码。调用顺序如下：应用层：send()

wa（等待）：等待I/O操作完成的时间，即CPU等待输入输出操作完成的时间。sy（系统空间）：系统态占用CPU的时间，即操作系统内核进程执行的时间。us（用户空间）：用户态占用CPU的时间，即用户进程或应用程序执行的时间。st: 12%：在虚拟化环境中，偷取时间占12%，表示有其他虚拟机正在共享物理资源并占用部分CPU时间。这是CPU未被占用的时间。sy: 15%：系统空间占用CPU的15%，表示操作系统内核进程正在执行一些任务。id: 45%：空闲时间占45%，表示大部分时间CPU处于空闲状态。

IO复用解决的真正问题是什么？：每次⼀个进程专⻔为了等⼀个 socket 上的数据就得被从 CPU 上拿下来。然后再换上另⼀个进程。等到数据 ready 了，睡眠的进程⼜会被唤醒。总共两次进程上下⽂切换开销，根据之前的测试来看，每⼀次切换⼤约是 3-5 us(微秒)左右。如果是⽹络 IO 密集型的应⽤的话，CPU 就不停地做进程切换这种⽆⽤功。也就是频繁进程上下文切换的开销巨大。

在 recv 函数执⾏的时候，使⽤ DEFINE_WAIT() 定义等待队列项的细节，内核把 curr->func 设置成了 autoremove_wake_function。回想上⾯我们在 创建 socket 流程⾥执⾏到的 sock_init_data 函数，在这个函数⾥已经把 sk_data_ready 设置成 sock_def_readable 函数了。在 tcp_rcv_established 中通过调⽤ tcp_queue_rcv 函数中完成了将接收数据放到 socket 的接收队列上。

进⼊系统调⽤后，⽤户进程就进⼊到了内核态，通过执⾏⼀系列的内核协议层函数，然后到 socket 对象的接收队列中查看是否有数据，没有的话就把⾃⼰添加到 socket 对应的等待队列⾥。这样后⾯当内核收完数据产⽣就绪时间的时候，就可以查找 socket 等待队列上的等待项，进⽽就可以找到回调函数和在等待该 socket 就绪事件的进程了。紧接着在 sk_wait_data 中 调⽤ sk_sleep 获取 sock 对象下的等待队列列表头 wait_queue_head_t。

inet_create 中根据类型 SOCK_STREAM 查找到对于 tcp 定义的操作⽅法实现集合 inet_stream_ops 和 tcp_prot。当软中断上收到数据包时会通过调⽤ sk_data_ready 函数指针（实际被设置成了 sock_def_readable()） 来唤醒在 sock 上等待的进程。sock_init_data 中将 sock 中的 sk_data_ready 函数指针进⾏了初始化，设置为默认 sock_def_readable()。

代码⾥调⽤的 recvfrom 是⼀个 glibc 的库函数，该函数在执⾏后会将⽤户进⾏陷⼊到内核态，进⼊到 Linux 实现的系统调⽤ sys_recvfrom。如果没有数据，且⽤户也允许等待，则将调⽤ wait_for_more_packets() 执⾏等待操作，它加⼊会让⽤户进程进⼊睡眠状态。对于 udp 来说，是通过 inet_dgram_ops 来定义的，其中注册了 inet_recvmsg ⽅法。接收队列⼤⼩受内核参数。具体是怎么进⼊睡眠状态的，和 TCP 的实现一样，属于进程的基本知识了。

在上⾯的代码中跟踪函数调⽤， __igb_open => igb_request_irq => igb_request_msix , 在 igb_request_msix 中我们看到了，对于多队列的⽹卡，为每⼀个队列都注册了中断，其对应的中断处理函数是 igb_msix_ring（该函数也在 drivers/net/ethernet/intel/igb/igb_main.c 下）。如协议注册⼩节看到 inet_protos 中保存着 tcp_v4_rcv() 和 udp_rcv() 的函数地址。