网卡发送数据包
IP报文可以看作一个包。
linux网卡驱动程序，将IP包添加14字节的MAC包头，构成MAC包。
MAC包中含有发送端和接收端的MAC地址信息。既然是驱动程序创建的MAC包头信息，当然可以随便输入地址信息的。主机伪装就是这么实现的。
驱动程序将MAC包拷贝到网卡芯片内部的缓冲区，就算完事了。有网卡芯片接手处理。
网卡芯片对MAC包，再次封装成物理帧，添加头部同步信息和CRC校验。然后丢到网线上，就完成一个IP报文的发送。所有挂接到本网线的网卡都可以看到该物理帧。
------------------------------------------------------------------------------------
网卡接收数据包
网线可以看作一个高速公路，物理帧也就是辆汽车，网卡呢？或许是个加油站吧。
从这个角度将，汽车和加油站没有绝对的对应关系，所有的汽车都可以进入该加油站。
正常情况：
网线上的物理帧首先被网卡芯片获取，网卡芯片会检查物理帧的CRC，保证完整性。
其次，网卡芯片将物理帧头去掉，得到MAC包。
网卡芯片检查MAC包内的目的MAC地址信息，和本网卡的MAC地址是否一致？不一致，抛弃。
网卡芯片将MAC帧拷贝到网卡内部的缓冲区，触发中断。
驱动程序通过中断，将MAC包拷贝到系统中，构建sk_buff。告诉上层。
上层去掉MAC包头，得到需要的IP包。
过程中，网卡芯片对物理帧进行了MAC匹配过滤。这样做可以减小系统负荷。
试想一下，若网卡芯片对所有的MAC帧不加判断的直接提供给驱动，让CPU判决会是什么样子呢？
当总线上数据繁忙，CPU将浪费大部分时间去判断该MAC包是否是自己需要的，效率低下。
不正常模式（混听）：
网线上的物理帧首先被网卡芯片获取，网卡芯片会检查物理帧的CRC，保证完整性。
其次，网卡芯片将物理帧头去掉，得到MAC包。
网卡芯片发现自己当前被配置为混听模式，就不对MAC包过滤。
网卡芯片将MAC帧拷贝到网卡内部的缓冲区，触发中断。
驱动程序通过中断，将MAC包拷贝到系统中，构建sk_buff。告诉上层。
上层去掉MAC包头，得到需要的IP包。
显然，这里的IP包并一定是发给自己的。
驱动的问题
网卡到底能不能接收其他MAC包，完全取决于网卡芯片中RCR（receive control register)配置。
驱动程序是决定网卡能否工作与混听模式的桥梁。
混听模式会加重CPU的负荷，而且也是不符合标准应用的！
所有的车辆都要从加油站穿过，（有些都不加油），加油站工作人员的任务量就可想而知。
当然也有例外，有些程序不通过驱动，也可以直接访问网卡芯片RCR达到设置混听模式。
所谓 条条大路通香港，就是这个道理：）没有绝对的
linux网卡驱动的关键就是处理两个问题
1。如何发送数据
也就是ndev->hard_start_xmit 函数的实现啦。
从上层扔下来的sk_buff中拿到数据，放到网卡的缓冲区里面。
2。如何接收数据
数据的接收是不用提供驱动接口的。
目前多采用中断接收，然后将网卡缓冲区的数据重新打包为sk_buff，扔给上层即可。
netif_rx(skb);
既然接收程序不是驱动提供的接口，可以很灵活的实现。
我们可以另外写个驱动，启动个定时器，周期构造sk_buff，扔给上层即可。
这样做没有什么意义，但可以更好的理解接收是怎么回事。
3。对于多个网卡共用一个驱动，处理起来可能要小心了
系统有2个PCI网卡，使用一个linux RTL8139驱动。
从上层扔下来的sk_buff中拿到数据，这时该怎么办呢？？？
扔到哪个网卡的缓冲区里面呢？