三.编写Linux网络驱动程序中需要注意的问题
3.1 中断共享
Linux系统运行几个设备共享同一个中断。需要共享的话,在申请的时候指明共享方式。系统提供的request_irq()调用的定义:
int request_irq(unsigned int irq,
void (*handler)(int irq, void *dev_id, struct pt_regs *regs),
unsigned long irqflags,
const char * devname,
void *dev_id);
如果共享中断,irqflags设置SA_SHIRQ属性,这样就允许别的设备申请同一个中断。需要注意所有用到这个中断的设备在调用request_irq()都必须设置这个属性。系统在回调每个中断处理程序时,可以用dev_id这个参数找到相应的设备。系统在回调每个中断处理程序时,可以用dev_id这个参数找到相应的设备。一般dev_id就设为device结构本身。系统处理共享中断是用各自的dev_id参数依次调用每一个中断处理程序。
3.2 硬件发送忙时的处理
主CPU的处理能力一般比网络发送要快,所以经常会遇到系统有数据要发,但上一包数据网络设备还没发送完。因为在Linux里网络设备驱动程序一般不做数据缓存,不能发送的数据都是通知系统发送不成功,所以必须要有一个机制在硬件不忙时及时通知系统接着发送下面的数据。
一般对发送忙的处理在前面设备的发送方法(hard_start_xmit)里已经描述过,即如果发送忙,置tbusy为1。处理完发送数据后,在发送结束中断里清tbusy,同时用mark_bh()调用通知系统继续发送。
但在具体实现我的驱动程序时发现,这样的处理系统好象并不能及时地知道硬件已经空闲了,即在mark_bh()以后,系统要等一段时间才会接着发送。造成发送效率很低。2M线路只有10%不到的使用率。内核版本为2.0.35。
我最后的实现是不把tbusy置1,让系统始终认为硬件空闲,但是报告发送不成功。系统会一直尝试重发。这样处理就运行正常了。但是遍循内核源码中的网络驱动程序,似乎没有这样处理的。不知道症结在哪里。
3.3 流量控制(flow control)
网络数据的发送和接收都需要流量控制。这些控制是在系统里实现的,不需要驱动程序做工作。每个设备数据结构里都有一个参数dev->tx_queue_len,这个参数标明发送时最多缓存的数据包。在Linux系统里以太网设备(10/100Mbps)标明发送时最多缓存的数据包。在Linux系统里以太网设备(10/100Mbps)tx_queue_len一般设置为100,串行线路(异步串口)为10。实际上如果看源码可以知道,设置了dev->tx_queue_len并不是为缓存这些数据申请了空间。这个参数只是在收到协议层的数据包时判断发送队列里的数据是不是到了tx_queue_len的限度,以决定这一包数据加不加进发送队列。发送时另一个方面的流控是更高层协议的发送窗口(TCP协议里就有发送窗口)。达到了窗口大小,高层协议就不会再发送数据。
接收流控也分两个层次。netif_rx()缓存的数据包有限制。另外高层协议也会有一个最大的等待处理的数据量。
发送和接收流控处理在net/core/dev.c的do_dev_queue_xmit()和netif_rx()中。专题:http://www.qqread.com/linux/y571247206.html
更多内容请看网络管理实用手册、网络故障手册、Linux集群技术专题,或进入讨论组讨论。
3.1 中断共享
Linux系统运行几个设备共享同一个中断。需要共享的话,在申请的时候指明共享方式。系统提供的request_irq()调用的定义:
int request_irq(unsigned int irq,
void (*handler)(int irq, void *dev_id, struct pt_regs *regs),
unsigned long irqflags,
const char * devname,
void *dev_id);
如果共享中断,irqflags设置SA_SHIRQ属性,这样就允许别的设备申请同一个中断。需要注意所有用到这个中断的设备在调用request_irq()都必须设置这个属性。系统在回调每个中断处理程序时,可以用dev_id这个参数找到相应的设备。系统在回调每个中断处理程序时,可以用dev_id这个参数找到相应的设备。一般dev_id就设为device结构本身。系统处理共享中断是用各自的dev_id参数依次调用每一个中断处理程序。
3.2 硬件发送忙时的处理
主CPU的处理能力一般比网络发送要快,所以经常会遇到系统有数据要发,但上一包数据网络设备还没发送完。因为在Linux里网络设备驱动程序一般不做数据缓存,不能发送的数据都是通知系统发送不成功,所以必须要有一个机制在硬件不忙时及时通知系统接着发送下面的数据。
一般对发送忙的处理在前面设备的发送方法(hard_start_xmit)里已经描述过,即如果发送忙,置tbusy为1。处理完发送数据后,在发送结束中断里清tbusy,同时用mark_bh()调用通知系统继续发送。
但在具体实现我的驱动程序时发现,这样的处理系统好象并不能及时地知道硬件已经空闲了,即在mark_bh()以后,系统要等一段时间才会接着发送。造成发送效率很低。2M线路只有10%不到的使用率。内核版本为2.0.35。
我最后的实现是不把tbusy置1,让系统始终认为硬件空闲,但是报告发送不成功。系统会一直尝试重发。这样处理就运行正常了。但是遍循内核源码中的网络驱动程序,似乎没有这样处理的。不知道症结在哪里。
3.3 流量控制(flow control)
网络数据的发送和接收都需要流量控制。这些控制是在系统里实现的,不需要驱动程序做工作。每个设备数据结构里都有一个参数dev->tx_queue_len,这个参数标明发送时最多缓存的数据包。在Linux系统里以太网设备(10/100Mbps)标明发送时最多缓存的数据包。在Linux系统里以太网设备(10/100Mbps)tx_queue_len一般设置为100,串行线路(异步串口)为10。实际上如果看源码可以知道,设置了dev->tx_queue_len并不是为缓存这些数据申请了空间。这个参数只是在收到协议层的数据包时判断发送队列里的数据是不是到了tx_queue_len的限度,以决定这一包数据加不加进发送队列。发送时另一个方面的流控是更高层协议的发送窗口(TCP协议里就有发送窗口)。达到了窗口大小,高层协议就不会再发送数据。
接收流控也分两个层次。netif_rx()缓存的数据包有限制。另外高层协议也会有一个最大的等待处理的数据量。
发送和接收流控处理在net/core/dev.c的do_dev_queue_xmit()和netif_rx()中。专题:http://www.qqread.com/linux/y571247206.html
相关图文阅读
频道图文推荐
健 康 咨 询
时 尚 咨 询
相关专题
- 网络管理实用手册 (22421篇文章)
- 网络故障手册 (14465篇文章)
- Linux集群技术 (8259篇文章)
- 网络组网专题 (12494篇文章)
- 网络建设 (14032篇文章)
- 体验Linux的音影世界 (7931篇文章)
- Linux驱动大全 (8729篇文章)
- Linux下的路由的配置与应用 (11721篇文章)
- Linux命令简介 (9775篇文章)
- Linux防火墙 (9606篇文章)
- Linux与Windows Vista的桌面之争 (83次浏览)
- 对比评测Vista XP Linux启动时间 (59次浏览)
- Linux 基本概念及常用命令 (57次浏览)
- Linux系统如何判断CPU是双核还是单核 (53次浏览)
- VMware下Linux与真实主机共享上网 (31次浏览)
- Linux系统下如何更改终端显示分辨率 (30次浏览)
- 实用技巧:配置Linux操作系统环境变量 (30次浏览)
- Fedora 8 Linux下安装配置audacious过程 (27次浏览)
- Linux系统下设置环境变量Path的方法 (25次浏览)
- 最流行的发行版:Ubuntu 8.04 Alpha 2发布 (24次浏览)



