On 11/5/06, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
On Sun, 5 Nov 2006 18:28:33 +0100 "Eric Lemoine" <[EMAIL PROTECTED]> wrote:> > You could also just use net_tx_lock() now. > > You mean netif_tx_lock()? > > Thanks for letting me know about that function. Yes, I may need it. > tg3 and bnx2 use it to wake up the transmit queue: > > if (unlikely(netif_queue_stopped(tp->dev) && > (tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH))) { > netif_tx_lock(tp->dev); > if (netif_queue_stopped(tp->dev) && > (tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH)) > netif_wake_queue(tp->dev); > netif_tx_unlock(tp->dev); > } > > 2.6.17 didn't use it. Was it a bug? > > Thanks, No, it was introduced in 2.6.18. The functions are just a wrapper around the network device transmit lock that is normally held. If the device does not need to acquire the lock during IRQ, it is a good alternative and avoids a second lock. For transmit locking there are three common alternatives: Method A: dev->queue_xmit_lock and per-device tx_lock send: dev->xmit_lock held by caller dev->hard_start_xmit acquires netdev_priv(dev)->tx_lock irq: netdev_priv(dev)->tx_lock acquired Method B: dev->queue_xmit_lock only send: dev->xmit_lock held by caller irq: schedules softirq (NAPI) napi_poll: calls netif_tx_lock() which acquires dev->xmit_lock Method C: LLTX set dev->features LLTX send: no locks held by caller dev->hard_start_xmit acquires netdev_priv(dev)->tx_lock irq: netdev_priv(dev)->tx_lock acquired Method A is the only one that works with 2.4 and early (2.6.8?) kernels.
Current sungem does Method C, and uses two locks: lock and tx_lock. What I was planning to do is Method B (which current tg3 uses). It seems to me that Method B is better than Method C. What do you think? -- Eric - 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
