On Fri, 2006-04-08 at 00:02 +1000, Herbert Xu wrote: > Even if we get it wrong and wake up something that we shouldn't have, > the xmit function will simply bail out and stop the queue for us. >
Infact thats close to what i was seeing. setup is: eth0 tied to cpu 0 eth1 tied to cpu1 --> eth0 -- forward --> eth1 --> eth1 -- forward --> eth0 Take the example of eth1: * It is actually being fed packets by cpu0 but is tied to cpu1. The stop happens in cpu0 (99.99999% of the time) and the wake happens in cpu1 (100% of the time)[1]. The wakes on most occasions dont even get to run tx softirq on cpu1 since there is constant activity already happening on cpu0. So that lock being grabbed was causing a collision on the tx path which caused a requeue which caused a reschedule on cpu0 - all this unnecessarily. > Since this is exceedingly unlikely we should drop the locks rather > than bother about it. I should say that the fact that e1000 does its pruning of descriptors only on the tx path makes the locking unnecessary when stopped. cheers, jamal [1] As you may know this comes from testing your qdisc_is_running change. I was hoping to induce a DOS attack such that a cpuX is busy processing packets from another CPU (eg eth1 on cpu1) so that it forgets to process its own receive path ;-> This is a theoretical possibility with that change ;-> Clearly i failed given the % above ;-> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
