| Submitter | Eric Dumazet |
|---|---|
| Date | June 14, 2010, 8:31 a.m. |
| Message ID | <1276504295.2478.35.camel@edumazet-laptop> |
| Download | mbox | patch |
| Permalink | /patch/55491/ |
| State | RFC |
| Delegated to: | David Miller |
| Headers | show |
Comments
On Jun 14, 2010, at 11:31 AM, Eric Dumazet wrote: > But your problem is about bridge, not bonding (see trace). I want it for performance reason, not because of this bug. Bridge isn't a bottleneck for me, but bonding may be and not to me only, but for many people. I believe that performance gain would be more than 1% on cpu? :-) > > And 2.6.34 wont accept such changes, its already released. It can be as a separate patch or I can test 2.3.35 if it would accept such change. I just need a stable kernel with good performance :-) > >> I also have another issue with NMI. On older machine with 5500 xeons i >> have almost no overhead with nmi_watchdog enabled, but on this it is about twice. >> without nmi enabled cpu peak average is 30%, and with nmi enabled i have 53%. >> When traffic is not passing all cpus are idling at 100%. >> Maybe overhead could be a little bit smaller? :-) >> > > I am a bit lost here, NMI have litle to do with network stack ;) May this be related to very recent cpu? As i understand NMI depends on CPU. > > > Could you please test another patch ? Applied, it's working correctly for now. If i'll get a warning i'll write you or maybe I shouldn't get it if a patch is correct? > > Before calling sk_tx_queue_set(sk, queue_index); we should check if dst > dev is current device. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Your new patch doesn't show any warnings about tx queue and everything is working as expected. On Jun 14, 2010, at 12:27 PM, Arturas wrote: > > On Jun 14, 2010, at 11:31 AM, Eric Dumazet wrote: >> But your problem is about bridge, not bonding (see trace). > I want it for performance reason, not because of this bug. > Bridge isn't a bottleneck for me, but bonding may be and not to me only, > but for many people. I believe that performance gain would be more > than 1% on cpu? :-) > >> >> And 2.6.34 wont accept such changes, its already released. > It can be as a separate patch or I can test 2.3.35 if it would accept > such change. I just need a stable kernel with good performance :-) > >> >>> I also have another issue with NMI. On older machine with 5500 xeons i >>> have almost no overhead with nmi_watchdog enabled, but on this it is about twice. >>> without nmi enabled cpu peak average is 30%, and with nmi enabled i have 53%. >>> When traffic is not passing all cpus are idling at 100%. >>> Maybe overhead could be a little bit smaller? :-) >>> >> >> I am a bit lost here, NMI have litle to do with network stack ;) > May this be related to very recent cpu? As i understand NMI depends on CPU. > >> >> >> Could you please test another patch ? > Applied, it's working correctly for now. If i'll get a warning i'll write you or maybe I > shouldn't get it if a patch is correct? > >> >> Before calling sk_tx_queue_set(sk, queue_index); we should check if dst >> dev is current device. > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch
--- net/core/dev.c.orig 2010-06-10 17:52:17.000000000 +0200 +++ net/core/dev.c 2010-06-14 10:25:25.000000000 +0200 @@ -1958,12 +1958,10 @@ static inline u16 dev_cap_txqueue(struct net_device *dev, u16 queue_index) { if (unlikely(queue_index >= dev->real_num_tx_queues)) { - if (net_ratelimit()) { - WARN(1, "%s selects TX queue %d, but " - "real number of TX queues is %d\n", - dev->name, queue_index, - dev->real_num_tx_queues); - } + WARN_ONCE("%s selects TX queue %d, but " + "real number of TX queues is %d\n", + dev->name, queue_index, + dev->real_num_tx_queues); return 0; } return queue_index; @@ -1977,6 +1975,7 @@ if (sk_tx_queue_recorded(sk)) { queue_index = sk_tx_queue_get(sk); + queue_index = dev_cap_txqueue(dev, queue_index); } else { const struct net_device_ops *ops = dev->netdev_ops; @@ -1991,7 +1990,7 @@ if (sk) { struct dst_entry *dst = rcu_dereference_bh(sk->sk_dst_cache); - if (dst && skb_dst(skb) == dst) + if (dst && skb_dst(skb) == dst && dst->dev == dev) sk_tx_queue_set(sk, queue_index); } }