netif_receive_skb pt_prev why?
|
|
关于netif_receive_skb中的一个链表处理问题
正文
| |
在netif_receive_skb中有一段代码是将receive的数据包clone一份交给ptype_all的链,代码如下：
……
pt_prev=NULL;
list_for_each_entry_rcu(ptype,&ptype_all,list){
if(!ptype->dev||ptype->dev==skb->dev){
if(pt_prev)
ret=deliver_skb(skb,pt_prev,orig_dev);
pt_prev=ptype;
}
}
我感觉上述代码有点迷糊啊，既然是遍历ptype_all链，为什么需要一个pt_prev保存一下呢,直接下面这样不就就行了
list_for_each_entry_rcu(ptype,&ptype_all,list){
if(!ptype->dev||ptype->dev==skb->dev){
ret=deliver_skb(skb,ptype,orig_dev);
}
}
那位大虾给讲解一下
[ 本帖最后由 Godbach 于 2009-8-21 16:06 编辑 ]
作者: Godbach 时间: 2009-8-21 16:07
LZ好啊，我把你的标题编辑了一下。希望有更多人讨论你的问题
作者: dreamice 时间: 2009-8-21 16:15
在netif_receive_skb中有一段代码是将receive的数据包clone一份交给ptype_all的链,代码如下：
……
pt_prev=NULL;
list_for_each_entry_rcu(ptype,&ptype_all,list){
if(!ptype->dev||ptype->dev==sk ...
这里是为了确定pt_prev是不是已经被投递了，如果已经被投递了，就往下遍历。
这个可能是为了避免smp并发处理造成对包的多次deliver。
作者: 瀚海书香 时间: 2009-8-21 16:16 标题: 回复 #2 Godbach 的帖子
谢谢版主
麻烦版主给分析一下吧
作者: Godbach 时间: 2009-8-21 16:21
看一下dreamice兄的解释。
但从程序上来看，基本上是遍历到当前节点时，将保存的前一个非空节点deliver。
作者: 瀚海书香 时间: 2009-8-21 16:25 标题: 回复 #3 dreamice 的帖子
可否详细讲解一下
上面那种情况是如何防止smp的多次deliver,以及下面这种情况又是在怎样的情况下产生多次deliver的？？
小弟愿闻其详
作者: Godbach 时间: 2009-8-21 16:31
按理说遍历链表的时候已经加锁了啊
作者: 瀚海书香 时间: 2009-8-21 16:37
而且更让我疑惑的是，按上面的那种情况，好像链表最后符合条件的那个ptype没有deliver啊
作者: dreamice 时间: 2009-8-21 17:26
可否详细讲解一下
上面那种情况是如何防止smp的多次deliver,以及下面这种情况又是在怎样的情况下产生多次deliver的？？
小弟愿闻其详
我先看看代码
作者: platinum 时间: 2009-8-21 17:43
因为后面还要用
作者: 瀚海书香 时间: 2009-8-21 19:13 标题: 回复 #10 platinum 的帖子
之后的代码就是bridge和vlan,然后就是ptype_base对应的协议处理函数。
在ptype_base的链表遍历中的确会deliver给ptype_all中的最后一个，但是为什么要到这里才deilver给ptype_all中的最后一个呢？
还有如果说在bridge或者vlan的处理中就返回了，就走不到这一步,那样ptype_all的最后一个就不能收到数据包了
作者: ShadowStar 时间: 2009-8-22 01:34
之后的代码就是bridge和vlan,然后就是ptype_base对应的协议处理函数。
在ptype_base的链表遍历中的确会deliver给ptype_all中的最后一个，但是为什么要到这里才deilver给ptype_all中的最后一个呢？
还有如果说 ...
逻辑处理上没有问题。
pt_prev意思就是“前一个packet_type”。
可以这么说，最后一个ptype_all的func是在ptype_base的循环中调用的。（如果ptype_base的循环中if成立）
你看在ptype_base循环下面，还有个if(pt_prev) {......
我也不清楚为什么这么做
而且，我觉得这里有点问题。
因为deliver_skb（就是执行packet_type->func()）是有可能kfree_skb()的。
这样的话，后面如果还有匹配到的话，skb已经被释放了。
[ 本帖最后由 ShadowStar 于 2009-8-22 01:46 编辑 ]
作者: 瀚海书香 时间: 2009-8-22 09:08 标题: 回复 #12 ShadowStar 的帖子
pt_prev意思就是“前一个packet_type”。
可以这么说，最后一个ptype_all的func是在ptype_base的循环中调用的。（如果ptype_base的循环中if成立）
你看在ptype_base循环下面
的确是这样的，但是如果说没有运行到这就return了呢？
因为deliver_skb（就是执行packet_type->func()）是有可能kfree_skb()的。
这个地方是没问题的，因为deliver_skb的时候有操作atomic_inc(&skb->users);而之后的 kfree_skb()也是atomic_dec(&skb->users),只有当skb->users=0的时候才真正的 free(skb)和free(skb->data)
作者: eexplorer 时间: 2009-8-22 11:33 标题: 回复 #1 瀚海书香 的帖子
这个还是涉及到优化的问题。
如 果只有一个packet_type match的话，我们就可以直接call pt_prev->func(skb, skb->dev, pt_prev, orig_dev)，注意这里的话并没有increase skb->uesrs，这个skb就是这个handler所独有的。
如 果存在多个handler match的话，在deliver_skb的时候需要increase skb->users，然后在这个handler里，如果这个skb是共享的，就需要skb_clone这个skb (see skb_share_check for details)
所以这么麻烦，就是为了优化最common的一个case，就是只有一个handler match的话，省去了skb_clone的开销。
[ 本帖最后由 eexplorer 于 2009-8-22 11:35 编辑 ]
作者: 瀚海书香 时间: 2009-8-22 11:53 标题: 回复 #14 eexplorer 的帖子
的确是这样的。
但 是在ptype_all类型的handle之后紧跟着是bridge和vlan的处理，之后是ptype_base类型handle的处理，但是如果 bridge和vlan两个处理的某一个返回值为NULL,则直接跳转到out:处执行，这样的话最后一个handle就不能收到数据包了？
作者: eexplorer 时间: 2009-8-22 13:14
的确是这样的。
但是在ptype_all类型的handle之后紧跟着是bridge和vlan的处理，之后是ptype_base类型handle的处理，但是如果bridge和vlan两个处理的某一个返回值为NULL,则直接跳转到out:处执行，这样的话最后一 ...
看了一下handle_bridge和hanel_macvlan，两个函数都有这样一段code:
if (*pt_prev) {
*ret = deliver_skb(skb, *pt_prev, orig_dev);
*pt_prev = NULL;
}
作者: 瀚海书香 时间: 2009-8-22 13:20 标题: 回复 #16 eexplorer 的帖子
那就明白了
多谢了
