diff options
author | David S. Miller <davem@davemloft.net> | 2008-01-08 05:35:07 +0100 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2008-01-09 08:30:07 +0100 |
commit | a0a46196cd98af5cc015842bba757571f02a8c30 (patch) | |
tree | 1e73ef1d0251f969fbb1a51637722c2c793ff0b6 /drivers/net/ixgb | |
parent | [NET]: Do not grab device reference when scheduling a NAPI poll. (diff) | |
download | linux-a0a46196cd98af5cc015842bba757571f02a8c30.tar.xz linux-a0a46196cd98af5cc015842bba757571f02a8c30.zip |
[NET]: Add NAPI_STATE_DISABLE.
Create a bit to signal that a napi_disable() is in progress.
This sets up infrastructure such that net_rx_action() can generically
break out of the ->poll() loop on a NAPI context that has a pending
napi_disable() yet is being bombed with packets (and thus would
otherwise poll endlessly and not allow the napi_disable() to finish).
Now, what napi_disable() does is first set the NAPI_STATE_DISABLE bit
(to indicate that a disable is pending), then it polls for the
NAPI_STATE_SCHED bit, and once the NAPI_STATE_SCHED bit is acquired
the NAPI_STATE_DISABLE bit is cleared. Here, the test_and_set_bit()
provides the necessary memory barrier between the various bitops.
napi_schedule_prep() now tests for a pending disable as it's first
action and won't try to obtain the NAPI_STATE_SCHED bit if a disable
is pending.
As a result, we can remove the netif_running() check in
netif_rx_schedule_prep() because the NAPI disable pending state serves
this purpose. And, it does so in a NAPI centric manner which is what
we really want.
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/ixgb')
0 files changed, 0 insertions, 0 deletions