Linux 网络协议栈开发（五）—— 二层桥转发蓝图（上）

一、看一张桥转发时函数调用的一个基本蓝图。

这张图中，简单的展示了，数据的接收和发送，其中还包括netfilet的钩子点所处的位置。

需要说明的是：
1）.我们先暂时忽略数据包从一开始是怎么从驱动进入到netif_receive_skb的，因为这个暂时不影响我们理解这幅图的流程。
2）.由于桥转发的篇幅较大，图中没有标示出，数据包中途被丢弃的情况。约定数据包会发送成功。

现在数据包(skb)已经准备好了装备要闯关了

1.首先skb从驱动经过繁杂的路线走到了netif_receive_skb这个函数中经过一些小波折到达__netif_receive_skb_core中时遇到了第一个十字路口是看了看自己有没有skb->dev->rx_handler(注1)这个装备，如果有，则进入br_handle_frame(注2).如果没有则直接上协议栈。

  注1：桥下的设备注册过rx_handler函数，所以数据包会进入桥，br_pass_frame_up函数将原先的设备换成了桥设备， 而桥设备没有注册过rx_handler函数，所以数据包不会二次进入桥。 
  注2：br_handle_frame我们在前几节提到过，是skb进入桥的入口函数，在br_add_if的时候会注册该函数。

2.skb注定要经历一番劫难，刚进入br_handle_frame又将陷入两难境地，此时有两个入口，这两个是netfilter设下的连个hook点，分别是，NF_BR_PRE_ROUTING，和NF_BR_LOCAL_IN，两种路径，如果数据包只想去本地，则会选择NF_BR_LOCAL_IN入口，然后发往本地，如果暂时还确定不了，则先进入NF_BR_PRE_ROUTING入口.

3.进入NF_BR_PRE_ROUTING入口后，会遇到br_handle_frame_finish函数，这个函数决定了skb的何去何从

(1)如果是转发，则在经过NF_BR_FORWARD钩子点进入转发阶段的障碍，最后在进入NF_BR_POST_ROUTING，以及最终的dev_queue_xmit，实现最终转发。

(2)如果发往本地则重新进入NF_BR_LOCAL_IN最后在进入netif_receive_skb，进行转发。

skb在经过目前口述的磨练最终得以释放。

4.如果是如果是本地发出的数据包，经过NF_BR_LOCAL_OUT钩子点然后进入最后阶段的NF_BR_POST_ROUTING，进行相应的转发。

二、我们看看数据包如何在桥中进行转发的一些动作。

  首先，上节的大蓝图中，标识除了，数据包是如何进入桥的，有一个很重要的函数br_handle_frame这个函数的初始注册地点是在桥添加接口的时候，注册在桥某一个接口上

[cpp]  view plain  copy

1. int br_add_if(struct net_bridge *br, struct net_device *dev)  
2. {  
3.     ........  
4.     /*注册设备接收帧函数*/  
5.     err = netdev_rx_handler_register(dev, br_handle_frame, p);  
6.     ........  
7. }  

其次，那么__netif_receive_skb_core是怎样让数据包进入桥的呢？我们看看上面提到的netdev_rx_handler_register函数，具体做了什么

[cpp]  view plain  copy

1. int netdev_rx_handler_register(struct net_device *dev,  
2.                    rx_handler_func_t *rx_handler,  
3.                    void *rx_handler_data)  
4. {