linux dev_queue_xmit、qos队列与NET_TX软中断

2180阅读 0评论2019-09-13 lelv123
分类:LINUX

发送的主要流程
1. 高层任务通过统一的设备无关接口来发起发送动作,dev_queue_xmit(*skb)
2. 在这个接口中,通过判断txq->qdisc->enqueue是否存在来判断是否为接口挂上了tc配置的qos队列,如果有非空的回调接口那么就进入了qos的队列调度中__dev_xmit_skb。事实上除非netdev的txqueuelen=0,这个回调总是存在的。即使你没有主动为netdev配置队列,也会使用默认的pfifo_fast(只要netdev的txqueuelen不是0)。
3. 在__dev_xmit_skb()中,已经知道了所需要使用的qdisc,检查他的状态和队列长度,把skb送入qdisc的队列,进入真正的出队调度__qdisc_run(q)
4. __qdisc_run(q) 唯一任务是出队,qos就是对出队的控制。这时候除非配额到了,或者是有其他任务需要使用cpu了,会一直循环调用qdisc_restart
5. qdisc_restart()每次从qdisc的队列中拿到一个skb,这个skb是tc调度后的幸运儿。有机会真正发送出去,调用netdev的dev_hard_start_xmit()
6. dev_hard_start_xmit()是设备相关接口。netdev的硬件驱动初始化时定义好了设备的操作方法集合,比如ndo_start_xmit负责硬件驱动发包。
7. ndo_start_xmit()以下就是每个网卡本身的sdk驱动,比如atheros的驱动定义在drivers/net/ethernet/atheros/ag71xx_main.c
   static const struct net_device_ops ag71xx_netdev_ops = {
       ...
   }


但是发包不是也有软中断 NET_TX么?
原来软中断并非是必须的,就是说发一个包出去不一定非得要触发软中断。
做了个实验,发200k包出去时,观察 /proc/softirqs 的NET_TX 基本没有增长。
在出接口配上tc规则把速率限制到100k,模拟发包压力大的情况,这时候看到 softirq 才会猛增

绝好的设计,当发包压力很小时,这是理想情况,直接操作buffer到硬件xmit返回再去发送下一个,就根本无须软中断调度。

上一篇:内存屏障是什么?
下一篇:linux设备驱动归纳总结(一):内核的相关基础概念