RE：探讨 Linux bridge 对802.1q包的处理

hi.stao

本人的配置：

1. eth1      Link encap:Ethernet  HWaddr 00:0C:29:85:2B:A6
   
2.           inet addr:192.168.80.102  Bcast:192.168.80.255  Mask:255.255.255.0
   
3.           inet6 addr: fe80::20c:29ff:fe85:2ba6/64 Scope:Link
   
4.           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   
5.           RX packets:1032 errors:0 dropped:0 overruns:0 frame:0
   
6.           TX packets:675 errors:0 dropped:0 overruns:0 carrier:0
   
7.           collisions:0 txqueuelen:1000
   
8.           RX bytes:100087 (97.7 KiB)  TX bytes:98901 (96.5 KiB)
   
9.           Interrupt:19 Base address:0x2024
   
10. 
    
11. eth1.33   Link encap:Ethernet  HWaddr 00:0C:29:85:2B:A6
    
12.           inet6 addr: fe80::20c:29ff:fe85:2ba6/64 Scope:Link
    
13.           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    
14.           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    
15.           TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
    
16.           collisions:0 txqueuelen:0
    
17.           RX bytes:0 (0.0 b)  TX bytes:768 (768.0 b)
    
18. 
    
19. eth1.34   Link encap:Ethernet  HWaddr 00:0C:29:85:2B:A6
    
20.           inet6 addr: fe80::20c:29ff:fe85:2ba6/64 Scope:Link
    
21.           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    
22.           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    
23.           TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
    
24.           collisions:0 txqueuelen:0
    
25.           RX bytes:0 (0.0 b)  TX bytes:492 (492.0 b)
    
26. 
    
27. [root@localhost ipv4]# brctl show
    
28. bridge name     bridge id               STP enabled     interfaces
    
29. br0             8000.000c29852ba6       no              eth1.33
    
30.                                                         eth1.34

复制代码

1：首先网卡收到包，触发中断，进入到netif_rx，然后进行到netif_receive_skb函数中。
这时skb->dev是eth1,带有vlan，协议是8100-----关于从netif_rx到netif_receive_skb的过程，有太多的文章，我大概看了但还是不甚了了！

2：在netif_receive_skb里顺序执行到handle_bridge的时候，由于eth1不在br0中，所以退出handle_bridge

1. if ((*pskb)->pkt_type == PACKET_LOOPBACK ||
   
2.             (port = rcu_dereference((*pskb)->dev->br_port)) == NULL)
   
3.                 return 0;

复制代码

交给下面的deliver_skb处理，然后进入到vlan处理部分

1. type = skb->protocol;
   
2.         list_for_each_entry_rcu(ptype, &ptype_base[ntohs(type)&15], list) {
   
3.                 if (ptype->type == type &&
   
4.                     (!ptype->dev || ptype->dev == skb->dev)) {
   
5.                         if (pt_prev)
   
6.                                 ret = deliver_skb(skb, pt_prev, orig_dev);
   
7.                         pt_prev = ptype;
   
8.                 }
   
9.         }
   

复制代码

3：vlan部分注册了协议函数，vlan_skb_recv函数：

        通过skb->dev = __find_vlan_dev(dev, vid)，根据vlan值33查找eth1.33。
              也就是说如果没有找到eth1.33，会释放掉skb退出，如果找到了，继续：
        调用vlan_check_reorder_header剥离vlan，并且把protocol设置为下一层的协议，例如0800（IP）
        然后调用netif_rx

4：netif_rx会再次执行到netif_receive_skb，这时skb->dev已经变成了eth1.33，并且报文已经没有vlan了。

再次进入到handle_bridge的时候，由于eth1.33在br0中，所以会进入到br处理

然后就是查找mac地址，如果找不到，则洪泛。找到了，则转发（待分析）

如果是洪泛，则需要向br0本身复制一份，最终会调用br_pass_frame_up，该函数最终调用netif_receive_skb，再次越过handle_bridge进入到上层协议（例如IP,arp等等)




上面是读了帖子http://bbs.chinaunix.net/thread-3566835-1-1.html之后我的析，供大家指正。

我还有一个疑问，在vlan处理中，最后调用netif_rx函数，为什么？为什么不是直接调用netif_receive_skb?

瀚海书香

我还有一个疑问，在vlan处理中，最后调用netif_rx函数，为什么？为什么不是直接调用netif_receive_skb?

这是一个规范问题。网络层向上层提供的数据包接收函数是netif_rx，那么就应该调用它。当然直接调用netif_receive_skb也可以，但是这样不规范，扩展性不好，因为接收数据包也是有队列，有先后顺序的，如果做了输入流控，那么就会跳过输入流控了。
就行发送数据包的时候，在网络层应该调用ip_queue_xmit来通过QOS来发送数据包，但是你也可以直接调用hard_start_xmit来发送数据包，但是这样就绕过了QOS处理了。

hi.stao

感谢回复

linux 的vlan处理确实有很多冗余，对性能会有影响