From: "Michael Chan" <[EMAIL PROTECTED]> Date: Wed, 25 Jul 2007 23:33:03 -0700
> This will lead to more and longer lock contentions between > ->hard_start_xmit() and ->poll() in the normal fast path. Why > do we need to widen the scope of netif_tx_lock() in this case? So that ->poll_controller() can process TX acks by just having the TX lock and interrupts disabled. Can you think of another way to process TX acks from absolutely any execution context whatsoever? That's what we need and preferably in some generic way, and the above is what I came up with. To be honest I don't think the TX lock contention will matter, and even if there were a small cost, the simplicity of the netpoll implementation is worth it given how problematic and hard to debug netpoll has been in the past. - 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
