From: Jan-Bernd Themann <ossthema@de.ibm.com>
Ok, for now I'm going to try and deal with this by reverting

the list handling to something approximating the old NAPI

code, as per the patch below.
I've only quickly test booted into this kernel on my workstation.

So take care when trying it out.
I took the liberty to add some assertions and comments all over

wrt. list and quota handling.  One thing to note that (and this

was true previously too) that if ->poll() uses the whole quota

it _MUST_ _NOT_ modify the NAPI state by doing a complete or

reschedule.  The net_rx_action code still owns the NAPI state in

that case, and therefore is allowed to make modifications to the

->poll_list.
I realize this adds a lot of IRQ enable/disable overhead back

into the code, but we can't get rid of that cleanly without

solving this list ownership and modification issue properly.
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h

index 0106fa6..9837ed3 100644

--- a/include/linux/netdevice.h

+++ b/include/linux/netdevice.h

@@ -284,7 +284,14 @@ extern int __init netdev_boot_setup(char *str);

  * Structure for NAPI scheduling similar to tasklet but with weighting

  */

 struct napi_struct {

+	/* The poll_list must only be managed by the entity which

+	 * changes the state of the NAPI_STATE_SCHED bit.  This means

+	 * whoever atomically sets that bit can add this napi_struct

+	 * to the per-cpu poll_list, and whoever clears that bit

+	 * can remove from the list right before clearing the bit.

+	 */

 	struct list_head	poll_list;

+

 	unsigned long		state;

 	int			weight;

 	int			quota;

@@ -336,13 +343,21 @@ static inline void napi_schedule(struct napi_struct *n)

  *

  * Mark NAPI processing as complete.

  */

-static inline void napi_complete(struct napi_struct *n)

+static inline void __napi_complete(struct napi_struct *n)

 {

 	BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state));

+	list_del(&n-&...
[ message continues ]

Hi,
I'm currently updating the eHEA polling function to work with this

scheme. Up to now we had sort of a quota for or TX refill part as well,

which was also done in the poll function. This was possible as the device

could be scheduled again even if the quota has not been used

completely. If I got it right this is not longer possible.

The idea was to benefit from the same "fairness" scheme of NAPI as it is

done for the RX side.
One other thing I observed is that I can not unload the module as the

ref counter of the eth device is too low. I haven't tracked down the

source of this problem yet.
Regards,

Jan-Bernd

-

> One other thing I observed is that I can not unload the module as the

 > ref counter of the eth device is too low. I haven't tracked down the

 > source of this problem yet.
I suspect that this is because netif_rx_reschedule() was missing a

dev_hold() to match the dev_put() in netif_rx_complete().  Dave merged

a fix for that problem yesterday, so current net-2.6.24 should be OK.

Let us know if it's not OK, because then there's another bug...
 - R.

-

When I applied this netif_rx_reschedule fix this problem did not occur

anymore (module could be unloaded). So I guess I hit the problem you

described.
Thanks,

Jan-Bernd

-

From: Jan-Bernd Themann <ossthema@de.ibm.com>
This is probably because of the resched device refcounting

bug that Roland Dreier just posted a fix for.
Look for subject "Fix refcounting problem with netif_rx_reschedule()"
I merge that in shortly to net-2.6.24 as well.

-