On Thu, 2007-07-26 at 00:15 -0700, David Miller wrote:

The netpoll code has to take that anyways in order to call
into ->hard_start_xmit() to send out the packet it has
pending, I'm leveraging that as a synchronization mechanism
in the drivers because the locking options are limited
given that netpoll can try to do this in any context whatsoever.

quoted

There is a measurable difference in oprofile.  When passing small
packets, there's a non-trivial difference in throughput.

Then please help come up with an alternate scheme, because these
NAPI changes fix real limitations and bugs in the current code
and unless we fix netpoll too we can't move forward.

I'm not very familiar with netpoll, but I am guessing that we need to
prevent concurrent calls to the TX cleanup code.  For maximum
flexibility, we should let ->poll_controller() handle the locking as the
driver knows what kind of locking is best.

If the driver wants a simple solution, it can do what you did in the
patch:  wrap the tx cleanup code with netif_tx_lock() and
netif_tx_unlock().

If a NAPI driver wants to be more clever, it can do something such as
this in tg3's poll_controller:

if (netif_rx_schedule_prep(dev, &tp->napi)) {
	tg3_tx(tp);
	netif_poll_enable(tp->napi);
}