Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bdb95b1792664f25eb2a4d13a587d2020aa93002
Commit: bdb95b1792664f25eb2a4d13a587d2020aa93002
Parent: d987160b710c98997015832422a05e18d9f0f925
Author: David S. Miller <[EMAIL PROTECTED]>
AuthorDate: Mon Jan 7 20:26:59 2008 -0800
Committer: David S. Miller <[EMAIL PROTECTED]>
CommitDate: Tue Jan 8 23:30:07 2008 -0800
[NET]: Do not grab device reference when scheduling a NAPI poll.
It is pointless, because everything that can make a device go away
will do a napi_disable() first.
The main impetus behind this is that now we can legally do a NAPI
completion in generic code like net_rx_action() which a following
changeset needs to do. net_rx_action() can only perform actions
in NAPI centric ways, because there may be a one to many mapping
between NAPI contexts and network devices (SKY2 is one example).
We also want to get rid of this because it's an extra atomic in the
NAPI paths, and also because it is one of the last instances where the
NAPI interfaces care about net devices.
The one remaining netdev detail the NAPI stuff cares about is the
netif_running() check which will be killed off in a subsequent
changeset.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
include/linux/netdevice.h | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 1e6af4f..e393995 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1277,7 +1277,6 @@ static inline int netif_rx_schedule_prep(struct
net_device *dev,
static inline void __netif_rx_schedule(struct net_device *dev,
struct napi_struct *napi)
{
- dev_hold(dev);
__napi_schedule(napi);
}
@@ -1308,7 +1307,6 @@ static inline void __netif_rx_complete(struct net_device
*dev,
struct napi_struct *napi)
{
__napi_complete(napi);
- dev_put(dev);
}
/* Remove interface from poll list: it must be in the poll list
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
