[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1287507866-25156-3-git-send-email-nhorman@tuxdriver.com>
Date: Tue, 19 Oct 2010 13:04:26 -0400
From: nhorman@...driver.com
To: netdev@...r.kernel.org
Cc: bonding-devel@...ts.sourceforge.net, fubar@...ibm.com,
davem@...emloft.net, andy@...yhouse.net, amwang@...hat.com,
nhorman@...driver.com
Subject: [PATCH 2/2] Revert napi_poll fix for bonding driver
From: Neil Horman <nhorman@...driver.com>
In an erlier patch I modified napi_poll so that devices with IFF_MASTER polled
the per_cpu list instead of the device list for napi. I did this because the
bonding driver has no napi instances to poll, it instead expects to check the
slave devices napi instances, which napi_poll was unaware of. Looking at this
more closely however, I now see this isn't strictly needed. As the bond driver
poll_controller calls the slaves poll_controller via netpoll_poll_dev, which
recursively calls poll_napi on each slave, allowing those napi instances to get
serviced. The earlier patch isn't at all harmfull, its just not needed, so lets
revert it to make the code cleaner. Sorry for the noise,
Signed-off-by: Neil Horman <nhorman@...driver.com>
---
net/core/netpoll.c | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index d79d221..4e98ffa 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -156,15 +156,8 @@ static void poll_napi(struct net_device *dev)
{
struct napi_struct *napi;
int budget = 16;
- struct softnet_data *sd = &__get_cpu_var(softnet_data);
- struct list_head *nlist;
- if (dev->flags & IFF_MASTER)
- nlist = &sd->poll_list;
- else
- nlist = &dev->napi_list;
-
- list_for_each_entry(napi, nlist, dev_list) {
+ list_for_each_entry(napi, &dev->napi_list, dev_list) {
if (napi->poll_owner != smp_processor_id() &&
spin_trylock(&napi->poll_lock)) {
budget = poll_one_napi(dev->npinfo, napi, budget);
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists