免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 1521 | 回复: 6

[网络子系统] linux 对于lookback,tunnels 这些非物理设备的数据包的发送是否没有触发软中断的? [复制链接]

论坛徽章:
1
2017金鸡报晓
日期:2017-01-10 15:13:29
发表于 2016-06-30 10:00 |显示全部楼层
分析2.3.32内核的 dev_queue_xmit 函数如下,注释:
int dev_queue_xmit(struct sk_buff *skb)
{
        struct net_device *dev = skb->dev;
        struct netdev_queue *txq;
        struct Qdisc *q;
        int rc = -ENOMEM;

        ………………

gso:
  /* Disable soft irqs for various locks below. Also
         * stops preemption for RCU.
         */
        rcu_read_lock_bh();

        txq = dev_pick_tx(dev, skb);
        q = rcu_dereference(txq->qdisc);

#ifdef CONFIG_NET_CLS_ACT
        skb->tc_verd = SET_TC_AT(skb->tc_verd, AT_EGRESS);
#endif
        if (q->enqueue) {
                rc = __dev_xmit_skb(skb, q, dev, txq);  /*这里会调用到netif_schedule,先放去softnet_data,
                                                                           *然后raise softirq NET_TX_SOFTIRQ,会先软中断,再到驱动发送函数
                                                                           */

                goto out;
        }

        /* The device has no queue. Common case for software devices:
           loopback, all the sorts of tunnels...

           Really, it is unlikely that netif_tx_lock protection is necessary
           here.  (f.e. loopback and IP tunnels are clean ignoring statistics
           counters.)
           However, it is possible, that they rely on protection
           made by us here.

           Check this and shot the lock. It is not prone from deadlocks.
           Either shot noqueue qdisc, it is even simpler
         */
        if (dev->flags & IFF_UP) {  /*处理没有queue的设备的分支*/
               ………………

                        if (!netif_tx_queue_stopped(txq)) {
                                rc = NET_XMIT_SUCCESS;
                                if (!dev_hard_start_xmit(skb, dev, txq)) { /*直接调用了驱动的发送函数*/
                                        HARD_TX_UNLOCK(dev, txq);
                                        goto out;
                                }
                        }
                        
               ………………
        }

        rc = -ENETDOWN;
        rcu_read_unlock_bh();

out_kfree_skb:
        kfree_skb(skb);
        return rc;
out:
        rcu_read_unlock_bh();
        return rc;
}

问题如题

论坛徽章:
20
程序设计版块每日发帖之星
日期:2015-08-17 06:20:00程序设计版块每日发帖之星
日期:2016-07-16 06:20:00程序设计版块每日发帖之星
日期:2016-07-18 06:20:00每日论坛发贴之星
日期:2016-07-18 06:20:00黑曼巴
日期:2016-12-26 16:00:3215-16赛季CBA联赛之江苏
日期:2017-06-26 11:05:5615-16赛季CBA联赛之上海
日期:2017-07-21 18:12:5015-16赛季CBA联赛之青岛
日期:2017-09-04 17:32:0515-16赛季CBA联赛之吉林
日期:2018-03-26 10:02:16程序设计版块每日发帖之星
日期:2016-07-15 06:20:0015-16赛季CBA联赛之江苏
日期:2016-07-07 18:37:512015亚冠之萨济拖拉机
日期:2015-08-17 12:21:08
发表于 2016-06-30 17:54 |显示全部楼层
1,对于有queue的情况,__dev_xmit_skb【一般】跟TX_SOFTIRQ没有【直接】关系吧?
除非tc的流控算法有延迟发送的情况,或者__qdisc_run跑的时间太长也是触发TX_SOFTIRQ的一种情况。

2. 对于没有queue的情况,直接调用drivre的xmit,跟TX_SOFTIRQ没有关系。
不过,取决于xmit的写法,
* 如果直接调用netif_receive_skb,不考虑rps的情况下,可以认为跟RX_SOFTIRQ没有关系。
* 通常虚拟device会调用netif_rx,通过enque_to_backlog会有RX_SOFTIRQ的调度产生。

论坛徽章:
1
2017金鸡报晓
日期:2017-01-10 15:13:29
发表于 2016-07-01 09:31 |显示全部楼层
是的,再仔细看了一下发送确实是这样的,接收的话应该是用napi的方式也会触发NET_RX_SOFTIRQ 吧回复 2# nswcfd


   

论坛徽章:
20
程序设计版块每日发帖之星
日期:2015-08-17 06:20:00程序设计版块每日发帖之星
日期:2016-07-16 06:20:00程序设计版块每日发帖之星
日期:2016-07-18 06:20:00每日论坛发贴之星
日期:2016-07-18 06:20:00黑曼巴
日期:2016-12-26 16:00:3215-16赛季CBA联赛之江苏
日期:2017-06-26 11:05:5615-16赛季CBA联赛之上海
日期:2017-07-21 18:12:5015-16赛季CBA联赛之青岛
日期:2017-09-04 17:32:0515-16赛季CBA联赛之吉林
日期:2018-03-26 10:02:16程序设计版块每日发帖之星
日期:2016-07-15 06:20:0015-16赛季CBA联赛之江苏
日期:2016-07-07 18:37:512015亚冠之萨济拖拉机
日期:2015-08-17 12:21:08
发表于 2016-07-01 11:30 |显示全部楼层
是的,backlog dev就是留给netif_rx用的(把之前的非NAPI方式过渡到NAPI方式)

论坛徽章:
1
2017金鸡报晓
日期:2017-01-10 15:13:29
发表于 2016-07-01 11:38 |显示全部楼层
如果是直接发送,不就会频繁的触发硬中断,不是应该触发个软中断,让数据包积累到一定程度,或者等一段时间,再触发硬中断,发送,这样对大流量的性能更好吗?就像接收那样回复 4# nswcfd


   

论坛徽章:
20
程序设计版块每日发帖之星
日期:2015-08-17 06:20:00程序设计版块每日发帖之星
日期:2016-07-16 06:20:00程序设计版块每日发帖之星
日期:2016-07-18 06:20:00每日论坛发贴之星
日期:2016-07-18 06:20:00黑曼巴
日期:2016-12-26 16:00:3215-16赛季CBA联赛之江苏
日期:2017-06-26 11:05:5615-16赛季CBA联赛之上海
日期:2017-07-21 18:12:5015-16赛季CBA联赛之青岛
日期:2017-09-04 17:32:0515-16赛季CBA联赛之吉林
日期:2018-03-26 10:02:16程序设计版块每日发帖之星
日期:2016-07-15 06:20:0015-16赛季CBA联赛之江苏
日期:2016-07-07 18:37:512015亚冠之萨济拖拉机
日期:2015-08-17 12:21:08
发表于 2016-07-01 17:49 |显示全部楼层
“直接发送”是针对哪种driver说的?

1. 像loopback/tunnel这样的virtual device本来就没有硬中断的概念。

2. 对于physical driver(例如e1000/igb等),不考虑tc的影响的话,确实有这个可能性。

a.  早期kernel给device提供的xmit API是面向单个skb的,而不是面向一批skb的,所以就算是使用软中断延迟或者其它批量化的发送手段,最终调用driver xmit接口仍然是packet by packet的,并不改变问题的性质。

b.  比较新的内核,在skb上有一个xmit_more的标记,指示是否有后续报文,驱动可以利用这个标记来推迟寄存器(例如igb的TAIL指针)的更新。

c.  大流量的情况下,连续向driver提交descriptor,或许hw有自己的机制,抑制tx interrupt产生的频率?(这句话没有根据……

d.  某些驱动的某些版本,会在xmit内部做一些优化,每隔多少次才更新一下寄存器,dpdk就有点像这个模型。

论坛徽章:
20
程序设计版块每日发帖之星
日期:2015-08-17 06:20:00程序设计版块每日发帖之星
日期:2016-07-16 06:20:00程序设计版块每日发帖之星
日期:2016-07-18 06:20:00每日论坛发贴之星
日期:2016-07-18 06:20:00黑曼巴
日期:2016-12-26 16:00:3215-16赛季CBA联赛之江苏
日期:2017-06-26 11:05:5615-16赛季CBA联赛之上海
日期:2017-07-21 18:12:5015-16赛季CBA联赛之青岛
日期:2017-09-04 17:32:0515-16赛季CBA联赛之吉林
日期:2018-03-26 10:02:16程序设计版块每日发帖之星
日期:2016-07-15 06:20:0015-16赛季CBA联赛之江苏
日期:2016-07-07 18:37:512015亚冠之萨济拖拉机
日期:2015-08-17 12:21:08
发表于 2016-07-01 17:57 |显示全部楼层
linux的tx bh解决的问题是:
1. 中断上下文释放的skb的安全回收;
2. 已暂停qdisc的重新调度;
http://lxr.free-electrons.com/source/net/core/dev.c#L3810

tx中断的优化貌似不在这个上下文解决?
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP