From: "Qinghua(Kevin) Ye" <[EMAIL PROTECTED]> Date: Thu, 7 Jul 2005 16:04:40 -0600
> I did some small test showing that polling can improve the packet processing > throughput a bit. I still need to do more tests. Could anyone give me some > information about the lock scheme of RX and TX precedure? I would be very > appreciate. Thanks. It depends, the locking changed significantly in the current 2.6.13-rcX version of the driver. But before that: 1) ->hard_start_xmit() needs to hold the tx_lock with hard IRQs disabled, as does tg3_tx(). It uses NETIF_F_LLTX locking, thus the callers do not grab netdev->xmit_lock and thus do not guarentee atomic invocation of the driver's ->hard_start_xmit method. 2) Interrupt processing needs to hold ->lock with hard IRQs disabled. As does any code which wants to reprogram the hardware. 3) tg3_rx() runs without locks held because ->poll() calls are guarenteed to be atomic. 4) Any piece of code which wants to significantly reprogram the tg3 chip must: a) shut down ->poll() processing by doing tg3_netif_stop() b) grabbing ->lock with HW irqs disabled c) grabbing ->tx_lock The unlocking afterwards must be done in the precise reverse order. You could have figured this out by simply reading the driver and looking at how the locks are used. I merely translated the code into english, and also there is a big fat comment at the top of "struct tg3" describing how the locks are used. I did not put that comment there for my health. :-) You also can turn on spinlock debugging to try and figure out any SMP hang problems you might be seeing as well. - 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
