免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
12下一页
最近访问板块 发新帖
查看: 29751 | 回复: 15

udp数据报从网卡驱动到用户空间流程总结 [复制链接]

论坛徽章:
0
发表于 2009-09-01 17:50 |显示全部楼层
最近学习linux内核网络协议栈,把数据包接收流程大致理了一下,
前面也看了瀚海书香兄的总结,感觉总结的比我精炼,抓住了主干,是一目了然的那种
我的这篇本来是自己看得,因此把我自己学习中一些遇到的问题写了出来,可能其他人会觉得废话比较多,呵呵
另外,因为我看的书Understanding Linux Network Internal只讲了ip层及以下,
因此L4层的流程是我自己在代码中找的,不保证100%正确,
如果有错误,还希望大虾及时指出,防止误人子弟
NAPI驱动流程:
    中断发生
    -->确定中断原因是数据接收完毕(中断原因也可能是发送完毕,DMA完毕,甚至是中断通道上的其他设备中断)
    -->通过netif_rx_schedule将驱动自己的napi结构加入softnet_data的poll_list链表,禁用网卡中断,并发出软中断
    -->中断返回时触发软中断net_rx_action,从softnet_data的poll_list上取下刚挂入的napi结构,并且调用其poll函数,这个poll函数也是驱动自己提供的,比如rtl8139网卡驱动中的rtl8139_poll等。
    -->在poll函数中进行轮询,直到接受完所有的数据或者预算(budget)耗尽。每接收一个报文要分配skb,用eth_type_trans处理并交给netif_receive_skb。
    -->如果数据全部接收完(预算没有用完),则重新使能中断并将napi从链表中取下。如果数据没接收完,则什么也不作,等待下一次poll函数被调度。
非NAPI流程:
    中断发生
    -->确定中断发生的原因是接收完毕。分配skb,读入数据,用eth_type_trans处理并且将skb交给netif_rx
    -->在netif_rx中,将packet加入到softnet_data的input_pkt_queue末尾(NAPI驱动不使用这个input_pkt_queue),再通过napi_schedule将softnet_data中的backlog(这也是个napi结构)加入softnet_data的poll_list,最后发出软中断
    -->软中断net_rx_action从poll_list上取下softnet_data的backlog,调用其poll函数,这个poll函数是内核提供的process_backlog
    -->函数process_backlog从softnet_data的input_pkt_queue末尾取下skb,并且直接交给netif_receive_skb处理。
    -->如果input_pkt_queue中所有skb都处理完则将backlog从队列中除去(注意input_pkt_queue中可能有多个网卡加入的报文,因为它是每cpu公用的)并退出循环;如果预算用完后也跳出循环。最后返回接受到的包数
总结:
NAPI和非NAPI的区别
    1.NAPI使用中断+轮询的方式,中断产生之后暂时关闭中断然后轮询接收完所有的数据包,接着再开中断。而非NAPI采用纯粹中断的方式,一个中断接收一个数据包
    2.NAPI都有自己的struct napi结构,非NAPI没有
    3.NAPI有自己的poll函数,而且接收数据都是在软中断调用poll函数时做的,而非NAPI使用公共的process_backlog函数作为其poll函数,接收数据是在硬件中断中做的
    4.NAPI在poll函数中接收完数据之后直接把skb发给netif_receive_skb,而非NAPI在硬件中断中接收了数据通过netif_rx把skb挂到公共的input_pkt_queue上,最后由软中断调用的process_backlog函数来将其发送给netif_receive_skb
驱动以及软中断这块对skb仅仅做了以下简单处理:
    1.调用skb_reserve预留出2个字节的空间,这是为了让ip首部对齐,因为以太网首部是14字节
    2.调用skb_put将tail指向数据末尾
    3.调用eth_type_trans进行如下处理:
        (1)将skb->dev指向接收设备
        (2)将skb->mac_header指向data(此时data就是指向mac起始地址)
        (3)调用skb_pull(skb, ETH_HLEN)将skb->data后移14字节指向ip首部
        (4)通过比较目的mac地址判断包的类型,并将skb->pkt_type赋值PACKET_BROADCAST或PACKET_MULTICAST或者PACKET_OTHERHOST,因为PACKET_HOST为0,所以是默认值
        (5)最后判断协议类型,并返回(大部分情况下直接返回eth首部的protocol字段的值),这个返回值被存在skb->protocol字段中
总结,结束后,skb->data指向ip首部,skb->mac_header指向mac首部,skb->protocol储存L3的协议代码,skb->pkt_type已被设置,skb->len等于接收到的报文长度减去eth首部长度,也就是整个ip报文的总长。其余字段基本上还是默认值。

netif_receive_skb
    1.将skb->iif赋值为skb->dev->ifindex,将skb->network_header和skb->transport_header都指向skb->data,也就是ip首部,然后skb->mac_len=skb->network_header-skb->mac_header,正常情况下应该等于ETH_HLEN吧
    2.向ptype_all中注册(通过dev_add_pack)的每一个packet_type调用一次deliver_skb,这里没有拷贝skb,只是先增加了一下skb->users
    3.调用handle_bridge处理桥报文,如果该dev不是一个桥端口则直接返回
    4.调用handle_macvlan处理vlan
    5.对于每一个在ptype_base中注册的packet_type(也是用dev_add_pack),调用deliver_skb
    6.如果没有任何一个注册的packet_type接受skb则直接kfree_skb并且返回NET_RX_DROP。否则返回最后一个pkt_type->func返回的值
总结,需要说一下dev_add_pack,这个函数根据传入的packet_type的type字段决定加入哪个队列,如果是ETH_P_ALL就加入ptype_all,否则计算哈希值并加入ptype_base,通过这个函数注册的都是L3层的协议,比如ip,arp,rarp,bootp等,其实还有packet协议族套接字的监听函数(除了ETH_P_ALL之外都加入ptype_base,它们对应的接收函数是packet_rcv),这里对于ip来说,接受函数就是ip_rcv。
经过这个函数,又有几个字段发生变化:
network_header和transport_header都指向ip首部,mac_len为mac首部长度

ip_rcv:
    1.丢弃所有pkt_type为OTHER_HOST的包,注意对于将网卡设为混杂模式的监听进程来说,这个包已经在netif_receive_skb中给它们发送了一份拷贝
    2.检查skb是否被共享,如果被共享需要用skb_clone拷贝一份,因为后面要对skb的内容进行变更
    3.常规检测:如果报文的长度小于ip首部最小长度,丢弃;如果ip协议字段不等于4丢弃;若ip首部长度字段小于5,丢弃;若ip首部长度小于ip首部长度字段*4,丢弃;如果ip首部校验和出错,丢弃;如果skb->len(此时len为整个ip报文长度)小于ip首部总长字段,丢弃;如果ip首部总长字段小于ip首部长度字段,丢弃;
    4.注意第三步中skb->len是可以小于ip首部的总长字段的,因为根据代码注释,传输介质有可能在末尾添加了padding,在这种情况下,会调用pskb_trim_rcsum将多余的结尾部分砍掉(通过把skb->tail往前移),并且还要将检查和无效化
    5.此处调用NF_INET_PRE_ROUTING钩子函数
总结,ip_rcv主要进行的常规检查,唯一对skb进行操作的就是将结尾的填充字段砍掉。

ip_rcv_finish:
    1.首先,如果skb->dst为空,说明还不确定这个ip报文的目的地是本机还是别的机器,这时通过ip_route_input来找到rtable并且赋给skb->rtable
    2.如果ip首部长度字段大于5则调用ip_rcv_options处理ip选项。该函数调用ip_options_compile将选项全部处理放在skb的cb字段中,作为一个struct ip_options(还要详细看ip_options_compile)。如果有源站路由选项则检查设备是否支持源站路由(软件支持,可配置),则调用ip_options_rcv_srr(此函数也还需认真看)填写源站路由。
    3.添加统计信息并调用dst_input,dst_input只是调用skb->dst->input函数,这个skb->dst就是前面用ip_route_input确定的,而根据dst类型的不同,这个input函数可能是ip_local_deliver或者ip_forward,这里我们看ip_local_deliver。
总结,ip_rcv_finish改变了skb->dst字段(如果本来skb->dst字段已经有值则不改变)和skb->cb字段(在ip_rcv_options中将ip首部选项编译之后放入cb)。ip_options_compile可以改变报文内容,比如填写路由记录选项,填写时间戳选项等

ip_local_deliver
    1.如果ip首部offset或者MF不为0,则调用ip_defrag进行ip分片的重组,ip_defrag只在成功完全重组了一个报文之后才会返回0,其他情况都是返回非0,如果返回非0就会从ip_local_deliver返回。ip_defrag也比较复杂,需要细看,总体来说就是将分片放在一个哈希表中,开启定时器,来一个分片就与前面属于同一ip报文的分片合并(两个分片是否属于同一个ip报文是通过ip的id字段,源目的地址,L4协议等多个参数确定的,可参考ip4_frag_match)
    2.钩子NF_INET_LOCAL_IN,并调用ip_local_deliver_finish
总结,从上两个函数可以看出NF_INET_PRE_ROUTING和NF_INET_LOCAL_IN之间的区别,前者还没有经过路由处理,即skb->dst一般还没有确定,而后者是已经确定了skb->dst且dst为本地地址,假如skb->dst不是本地地址则会调用ip_forward,这就不会触发NF_INET_LOCAL_IN了。另外NF_INET_PRE_ROUTING尚未对ip分片进行合并处理,而NF_INET_LOCAL_IN抓到的数据包是已经合并成的ip报文了

ip_local_deliver_finish
    1.将skb->data继续移动指向传输层首部,并且将skb->transport_header也指向传输层首部,接下来开始处理
    2.首先从ip首部取得传输层协议号,然后用这个协议号调用raw_local_deliver将skb传给raw_v4_hashinfo哈希表中的原始套接字协议
    3.再利用protocol值作为下标取得inet_protos全局数组中的注册协议(对于tcp,udp,icmp分别是tcp_protocol,udp_protocol,icmp_protocol)。如果找到了对应的协议处理结构,就把skb交给该结构的handler函数处理(对于tcp,udp,icmp分别是tcp_v4_rcv,udp_rcv,icmp_rcv)。如果没找到对应的处理结构,则回发一个icmp协议不可达的目的不可达报文,并释放skb。
总结:这里又一次移动了skb->data指针,将其指向传输层首部,同时设置了transport_header也指向传输层首部。raw_v4_hashinfo和inet_protos都是一个256项的全局数组,以协议号为下标保存了各个协议的处理结构。这两个数组就像是L4层的ptype_base,根据本层的协议号来决定处理函数
注意区别raw_v4_hashinfo和上面的ptype_all,前者是AF_INET的SOCK_RAW套接字注册的接收结构,而后者是AF_PACKET套接字注册的接收结构,可见raw套接字是经过了ip层处理的而packet是在netif_receive_skb中接收的,尚未经过任何处理,其中一个显著区别就是raw经过了ip_defrag而packet没有


对于udp来说,inet_protos中的结构是全局变量udp_protocol,它的handler函数是udp_rcv
udp_rcv所做的就是直接调用__udp4_lib_rcv(skb, udp_hash, IPPROTO_UDP);


__udp4_lib_rcv
    此函数中会调用__udp4_lib_lookup_skb-->()__udp4_lib_lookup()来查找此udp包对应的socket,主要是查找源目的地址和端口号都符合的socket。
    如果查找到了对应的socket,则调用udp_queue_rcv_skb将skb放入udp的接收队列,然后返回0
    如果没有查找到对应的socket,要向源地址发送一个ICMP端口不可达消息


udp_queue_rcv_skb
    它经过__udp_queue_rcv_skb(sk, skb)-->__udp_queue_rcv_skb-->skb_queue_tail一系列调用过程将skb加入socket的接收队列sk->sk_receive_queuek末尾。其中还要检测接收缓冲区是否已经满。
    接着调用sk->sk_data_ready(sk, skb_len)通知socket有数据就绪,可以读了。一般情况下这个函数对应sock_def_readable,这个函数的功能就是唤醒在sk->sk_sleep上睡眠的进程



    那么是谁在这里睡眠呢?在调用recvfrom系统调用接收报文的时候,会经过这样一个流程
    sys_socketcall
    -->sys_recvfrom
    -->sock_recvmsg
    -->__sock_recvmsg
    -->sock->ops->recvmsg,这个sock->ops对应全局变量inet_dgram_ops,里面的recvmsg对应sock_common_recvmsg
    -->sock_common_recvmsg
    -->sk->sk_prot->recvmsg,这个sk->sk_prot对应全局变量udp_prot,里面的recvmsg对应udp_recvmsg
    -->udp_recvmsg
    -->__skb_recv_datagram
    在__skb_recv_datagram中,会首先尝试从sk->sk_receive_queue上取下数据包,如果发现队列中没有数据包,则开始在sk->sk_skeep上睡眠。而上面sock_def_readable唤醒的就是这里睡眠的进程。
    可以看到,在__skb_recv_datagram中被唤醒后,函数又尝试从sk->sk_receive_queue上取下数据包,这时当然会成功,成功之后返回到udp_recvmsg。udp_recvmsg再进行一些简单的检测之后就调用copy_to_user将数据拷贝到用户空间了(其实这里并不是简单调用copy_to_user,还要处理很多情况,比如用户使用的msghdr可能包含多个iovec,skb可能有多个frags等等)

这样,一个udp数据包就从网卡到达了用户的缓冲区

评分

参与人数 2可用积分 +60 收起 理由
scutan + 30 精品文章
Godbach + 30 精品文章

查看全部评分

论坛徽章:
36
IT运维版块每日发帖之星
日期:2016-04-10 06:20:00IT运维版块每日发帖之星
日期:2016-04-16 06:20:0015-16赛季CBA联赛之广东
日期:2016-04-16 19:59:32IT运维版块每日发帖之星
日期:2016-04-18 06:20:00IT运维版块每日发帖之星
日期:2016-04-19 06:20:00每日论坛发贴之星
日期:2016-04-19 06:20:00IT运维版块每日发帖之星
日期:2016-04-25 06:20:00IT运维版块每日发帖之星
日期:2016-05-06 06:20:00IT运维版块每日发帖之星
日期:2016-05-08 06:20:00IT运维版块每日发帖之星
日期:2016-05-13 06:20:00IT运维版块每日发帖之星
日期:2016-05-28 06:20:00每日论坛发贴之星
日期:2016-05-28 06:20:00
发表于 2009-09-01 19:15 |显示全部楼层
LZ总结的很精彩啊。

《Understanding Linux Network Internal》这本书已经看完了吗,看的是影印版吧。

论坛徽章:
0
发表于 2009-09-01 19:47 |显示全部楼层
这本书确实讲的不错,如果能结合 孤独阁 前辈的博客学习,就更如虎添翼了

论坛徽章:
36
IT运维版块每日发帖之星
日期:2016-04-10 06:20:00IT运维版块每日发帖之星
日期:2016-04-16 06:20:0015-16赛季CBA联赛之广东
日期:2016-04-16 19:59:32IT运维版块每日发帖之星
日期:2016-04-18 06:20:00IT运维版块每日发帖之星
日期:2016-04-19 06:20:00每日论坛发贴之星
日期:2016-04-19 06:20:00IT运维版块每日发帖之星
日期:2016-04-25 06:20:00IT运维版块每日发帖之星
日期:2016-05-06 06:20:00IT运维版块每日发帖之星
日期:2016-05-08 06:20:00IT运维版块每日发帖之星
日期:2016-05-13 06:20:00IT运维版块每日发帖之星
日期:2016-05-28 06:20:00每日论坛发贴之星
日期:2016-05-28 06:20:00
发表于 2009-09-01 20:05 |显示全部楼层

回复 #3 duanjigang 的帖子

是啊,端木隐兄的博客精华文章太多了。

论坛徽章:
0
发表于 2009-09-01 20:14 |显示全部楼层
原帖由 Godbach 于 2009-9-1 19:15 发表
LZ总结的很精彩啊。

《Understanding Linux Network Internal》这本书已经看完了吗,看的是影印版吧。


to Godbach,目前该看第7部分路由了,是看得影印版,英文看得挺累得阿,正好网上有前辈翻译了第七部分,打算打印出来中英文结合看了
但是前面看得都还不扎实,有些都忘了。准备看完一遍对总体架构有些了解再立刻开始第二遍

本来只是个人整理思路的一些笔记,发出来更多是想让各位大虾看看有没有理解错误,
顺便也算给本版作点贡献吧

to duanjigang:孤独阁是哪位前辈?google了一下好像没找到阿。是独孤九贱前辈么?

论坛徽章:
36
IT运维版块每日发帖之星
日期:2016-04-10 06:20:00IT运维版块每日发帖之星
日期:2016-04-16 06:20:0015-16赛季CBA联赛之广东
日期:2016-04-16 19:59:32IT运维版块每日发帖之星
日期:2016-04-18 06:20:00IT运维版块每日发帖之星
日期:2016-04-19 06:20:00每日论坛发贴之星
日期:2016-04-19 06:20:00IT运维版块每日发帖之星
日期:2016-04-25 06:20:00IT运维版块每日发帖之星
日期:2016-05-06 06:20:00IT运维版块每日发帖之星
日期:2016-05-08 06:20:00IT运维版块每日发帖之星
日期:2016-05-13 06:20:00IT运维版块每日发帖之星
日期:2016-05-28 06:20:00每日论坛发贴之星
日期:2016-05-28 06:20:00
发表于 2009-09-01 20:29 |显示全部楼层

回复 #5 peimichael 的帖子

独孤阁不是独孤九贱。独孤阁的博客:
http://blog.chinaunix.net/u/12313/article_21496.html

论坛徽章:
36
IT运维版块每日发帖之星
日期:2016-04-10 06:20:00IT运维版块每日发帖之星
日期:2016-04-16 06:20:0015-16赛季CBA联赛之广东
日期:2016-04-16 19:59:32IT运维版块每日发帖之星
日期:2016-04-18 06:20:00IT运维版块每日发帖之星
日期:2016-04-19 06:20:00每日论坛发贴之星
日期:2016-04-19 06:20:00IT运维版块每日发帖之星
日期:2016-04-25 06:20:00IT运维版块每日发帖之星
日期:2016-05-06 06:20:00IT运维版块每日发帖之星
日期:2016-05-08 06:20:00IT运维版块每日发帖之星
日期:2016-05-13 06:20:00IT运维版块每日发帖之星
日期:2016-05-28 06:20:00每日论坛发贴之星
日期:2016-05-28 06:20:00
发表于 2009-09-01 20:31 |显示全部楼层
目前该看第7部分路由了,是看得影印版,英文看得挺累得阿,正好网上有前辈翻译了第七部分,打算打印出来中英文结合看了

呵呵,如果翻译质量有保证,看中文来的看一些。据说翻译了前七章的朋友,是因为版权问题,所以没有继续后面的翻译。听说而已,未经确认。

论坛徽章:
6
金牛座
日期:2013-10-08 10:19:10技术图书徽章
日期:2013-10-14 16:24:09CU十二周年纪念徽章
日期:2013-10-24 15:41:34狮子座
日期:2013-11-24 19:26:19未羊
日期:2014-01-23 15:50:002015年亚洲杯之阿联酋
日期:2015-05-09 14:36:15
发表于 2009-09-01 23:10 |显示全部楼层

回复 #1 peimichael 的帖子

分析的比较具体,透彻,小弟还要向前辈学习啊

论坛徽章:
0
发表于 2009-09-01 23:18 |显示全部楼层
4个字:不服不行

论坛徽章:
0
发表于 2009-09-21 14:32 |显示全部楼层
原帖由 Godbach 于 2009-9-1 20:29 发表
独孤阁不是独孤九贱。独孤阁的博客:
http://blog.chinaunix.net/u/12313/article_21496.html


why not update ?
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

DTCC2020中国数据库技术大会 限时8.5折

【架构革新 高效可控】2020年6月4日~6日第十一届中国数据库技术大会将在北京隆重召开。

大会设置2大主会场,20+技术专场,将邀请超百位行业专家,重点围绕数据架构、AI与大数据、传统企业数据库实践和国产开源数据库等内容展开分享和探讨,为广大数据领域从业人士提供一场年度盛会和交流平台。

http://dtcc.it168.com


大会官网>>
  

北京盛拓优讯信息技术有限公司. 版权所有 16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122
中国互联网协会会员  联系我们:huangweiwei@it168.com
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP