1. 10 6月, 2009 1 次提交
  2. 30 5月, 2009 1 次提交
    • J
      net: convert unicast addr list · ccffad25
      Jiri Pirko 提交于
      This patch converts unicast address list to standard list_head using
      previously introduced struct netdev_hw_addr. It also relaxes the
      locking. Original spinlock (still used for multicast addresses) is not
      needed and is no longer used for a protection of this list. All
      reading and writing takes place under rtnl (with no changes).
      
      I also removed a possibility to specify the length of the address
      while adding or deleting unicast address. It's always dev->addr_len.
      
      The convertion touched especially e1000 and ixgbe codes when the
      change is not so trivial.
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      
       drivers/net/bnx2.c               |   13 +--
       drivers/net/e1000/e1000_main.c   |   24 +++--
       drivers/net/ixgbe/ixgbe_common.c |   14 ++--
       drivers/net/ixgbe/ixgbe_common.h |    4 +-
       drivers/net/ixgbe/ixgbe_main.c   |    6 +-
       drivers/net/ixgbe/ixgbe_type.h   |    4 +-
       drivers/net/macvlan.c            |   11 +-
       drivers/net/mv643xx_eth.c        |   11 +-
       drivers/net/niu.c                |    7 +-
       drivers/net/virtio_net.c         |    7 +-
       drivers/s390/net/qeth_l2_main.c  |    6 +-
       drivers/scsi/fcoe/fcoe.c         |   16 ++--
       include/linux/netdevice.h        |   18 ++--
       net/8021q/vlan.c                 |    4 +-
       net/8021q/vlan_dev.c             |   10 +-
       net/core/dev.c                   |  195 +++++++++++++++++++++++++++-----------
       net/dsa/slave.c                  |   10 +-
       net/packet/af_packet.c           |    4 +-
       18 files changed, 227 insertions(+), 137 deletions(-)
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ccffad25
  3. 26 4月, 2009 1 次提交
    • J
      vlan: update vlan carrier state for admin up/down · adc667e8
      Jay Vosburgh 提交于
      	Currently, the VLAN event handler does not adjust the VLAN
      device's carrier state when the real device or the VLAN device is set
      administratively up or down.
      
      	The following patch adds a transfer of operating state from the
      real device to the VLAN device when the real device is administratively
      set up or down, and sets the carrier state up or down during init, open
      and close of the VLAN device.
      
      	This permits observers above the VLAN device that care about the
      carrier state (bonding's link monitor, for example) to receive updates
      for administrative changes by more closely mimicing the behavior of real
      devices.
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      adc667e8
  4. 10 3月, 2009 1 次提交
  5. 01 2月, 2009 1 次提交
  6. 20 11月, 2008 1 次提交
  7. 29 10月, 2008 1 次提交
  8. 12 9月, 2008 1 次提交
  9. 15 7月, 2008 1 次提交
  10. 08 7月, 2008 3 次提交
  11. 06 7月, 2008 3 次提交
  12. 23 5月, 2008 1 次提交
  13. 21 5月, 2008 2 次提交
  14. 19 5月, 2008 1 次提交
  15. 16 4月, 2008 6 次提交
  16. 02 4月, 2008 1 次提交
  17. 27 3月, 2008 1 次提交
    • P
      [VLAN]: Reduce memory consumed by vlan_groups · 67727184
      Pavel Emelyanov 提交于
      Currently each vlan_groupd contains 8 pointers on arrays with 512
      pointers on struct net_device each  :)  Such a construction "in many
      cases ... wastes memory".
      
      My proposal is to allow for some of these arrays pointers be NULL,
      meaning that there are no devices in it. When a new device is added
      to the vlan_group, the appropriate array is allocated.
      
      The check in vlan_group_get_device's is safe, since the pointer
      vg->vlan_devices_arrays[x] can only switch from NULL to not-NULL.
      The vlan_group_prealloc_vid() is guarded with rtnl lock and is
      also safe.
      
      I've checked (I hope that) all the places, that use these arrays
      and found, that the register_vlan_dev is the only place, that can
      put a vlan device on an empty vlan_group.
      
      Rough calculations shows, that after the patch a setup with a
      single vlan dev (or up to 512 vlans with sequential vids) will
      occupy approximately 8 times less memory.
      
      The question I have is - does this patch makes sense, or a totally
      new structures are required to store the vlan_devs?
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      67727184
  18. 26 3月, 2008 1 次提交
  19. 29 1月, 2008 11 次提交
  20. 11 1月, 2008 1 次提交