1. 01 2月, 2008 1 次提交
    • C
      [VLAN]: set_rx_mode support for unicast address list · e83a2ea8
      Chris Leech 提交于
      Reuse the existing logic for multicast list synchronization for the
      unicast address list. The core of dev_mc_sync/unsync are split out as
      __dev_addr_sync/unsync and moved from dev_mcast.c to dev.c.  These are
      then used to implement dev_unicast_sync/unsync as well.
      
      I'm working on cleaning up Intel's FCoE stack, which generates new MAC
      addresses from the fibre channel device id assigned by the fabric as
      per the current draft specification in T11.  When using such a
      protocol in a VLAN environment it would be nice to not always be
      forced into promiscuous mode, assuming the underlying Ethernet driver
      supports multiple unicast addresses as well.
      Signed-off-by: NChris Leech <christopher.leech@intel.com>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      e83a2ea8
  2. 09 1月, 2008 2 次提交
    • D
      [NET]: Add NAPI_STATE_DISABLE. · a0a46196
      David S. Miller 提交于
      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: NDavid S. Miller <davem@davemloft.net>
      a0a46196
    • D
      [NET]: Do not grab device reference when scheduling a NAPI poll. · bdb95b17
      David S. Miller 提交于
      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: NDavid S. Miller <davem@davemloft.net>
      bdb95b17
  3. 01 11月, 2007 1 次提交
  4. 26 10月, 2007 1 次提交
  5. 24 10月, 2007 2 次提交
  6. 22 10月, 2007 1 次提交
  7. 18 10月, 2007 2 次提交
  8. 14 10月, 2007 1 次提交
    • R
      net core: fix kernel-doc for new function parameters · c4ea43c5
      Randy Dunlap 提交于
      Fix networking code kernel-doc for newly added parameters.
      
      Warning(linux-2.6.23-git2//net/core/sock.c:879): No description found for parameter 'net'
      Warning(linux-2.6.23-git2//net/core/dev.c:570): No description found for parameter 'net'
      Warning(linux-2.6.23-git2//net/core/dev.c:594): No description found for parameter 'net'
      Warning(linux-2.6.23-git2//net/core/dev.c:617): No description found for parameter 'net'
      Warning(linux-2.6.23-git2//net/core/dev.c:641): No description found for parameter 'net'
      Warning(linux-2.6.23-git2//net/core/dev.c:667): No description found for parameter 'net'
      Warning(linux-2.6.23-git2//net/core/dev.c:722): No description found for parameter 'net'
      Warning(linux-2.6.23-git2//net/core/dev.c:959): No description found for parameter 'net'
      Warning(linux-2.6.23-git2//net/core/dev.c:1195): No description found for parameter 'dev'
      Warning(linux-2.6.23-git2//net/core/dev.c:2105): No description found for parameter 'n'
      Warning(linux-2.6.23-git2//net/core/dev.c:3272): No description found for parameter 'net'
      Warning(linux-2.6.23-git2//net/core/dev.c:3445): No description found for parameter 'net'
      Warning(linux-2.6.23-git2//include/linux/netdevice.h:1301): No description found for parameter 'cpu'
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c4ea43c5
  9. 11 10月, 2007 17 次提交
  10. 14 8月, 2007 1 次提交
  11. 21 7月, 2007 1 次提交
  12. 18 7月, 2007 1 次提交
    • D
      [NET]: move dev_mc_discard from dev_mcast.c to dev.c · 456ad75c
      Denis Cheng 提交于
      Because this function is only called by unregister_netdevice,
      this moving could make this non-global function static,
      and also remove its declaration in netdevice.h;
      
      Any further, function __dev_addr_discard is also just called by
      dev_mc_discard and dev_unicast_discard, keeping this two functions
      both in one c file could make __dev_addr_discard also static
      and remove its declaration in netdevice.h;
      
      Futhermore, the sequential call to dev_unicast_discard and then
      dev_mc_discard in unregister_netdevice have a similar mechanism that:
      (netif_tx_lock_bh / __dev_addr_discard / netif_tx_unlock_bh),
      they should merged into one to eliminate duplicates in acquiring and
      releasing the dev->_xmit_lock, this would be done in my following patch.
      Signed-off-by: NDenis Cheng <crquan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      456ad75c
  13. 17 7月, 2007 1 次提交
  14. 15 7月, 2007 3 次提交
    • P
      [NET]: Add macvlan driver · b863ceb7
      Patrick McHardy 提交于
      Add macvlan driver, which allows to create virtual ethernet devices
      based on MAC address.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b863ceb7
    • P
      [NET]: dev_mcast: add multicast list synchronization helpers · a0a400d7
      Patrick McHardy 提交于
      The method drivers currently use to synchronize multicast lists is not
      very pretty:
      
      - walk the multicast list
      - search each entry on a copy of the previous list
      - if new add to lower device
      - walk the copy of the previous list
      - search each entry on the current list
      - if removed delete from lower device
      - copy entire list
      
      This patch adds a new field to struct dev_addr_list to store the
      synchronization state and adds two helper functions for synchronization
      and cleanup.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0a400d7
    • P
      [NET]: Add net_device change_rx_mode callback · 24023451
      Patrick McHardy 提交于
      Currently the set_multicast_list (and set_rx_mode) callbacks are
      responsible for configuring the device according to the IFF_PROMISC,
      IFF_MULTICAST and IFF_ALLMULTI flags and the mc_list (and uc_list in
      case of set_rx_mode).
      
      These callbacks can be invoked from BH context without the rtnl_mutex
      by dev_mc_add/dev_mc_delete, which makes reading the device flags and
      promiscous/allmulti count racy. For real hardware drivers that just
      commit all changes to the hardware this is not a real problem since
      the stack guarantees to call them for every change, so at least the
      final call will not race and commit the correct configuration to the
      hardware.
      
      For software devices that want to synchronize promiscous and multicast
      state to an underlying device however this can cause corruption of the
      underlying device's flags or promisc/allmulti counts.
      
      When the software device is concurrently put in promiscous or allmulti
      mode while set_multicast_list is invoked from bottem half context, the
      device might synchronize the change to the underlying device without
      holding the rtnl_mutex, which races with concurrent changes to the
      underlying device.
      
      Add a dev->change_rx_flags hook that is invoked when any of the flags
      that affect rx filtering change (under the rtnl_mutex), which allows
      drivers to perform synchronization immediately and only synchronize
      the address lists in set_multicast_list/set_rx_mode.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      24023451
  15. 12 7月, 2007 1 次提交
  16. 11 7月, 2007 4 次提交