From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 26 Jul 2007 00:05:47 -0700

David Miller wrote:

quoted

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.

What are we trying to protect against by taking the TX lock before
calling ->poll_controller()?

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.

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.

Thanks.