1. 06 7月, 2008 2 次提交
  2. 23 5月, 2008 1 次提交
  3. 21 5月, 2008 2 次提交
  4. 02 5月, 2008 1 次提交
  5. 16 4月, 2008 8 次提交
  6. 05 4月, 2008 1 次提交
  7. 02 4月, 2008 1 次提交
  8. 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
  9. 26 3月, 2008 2 次提交
  10. 18 3月, 2008 1 次提交
  11. 06 3月, 2008 1 次提交
  12. 29 2月, 2008 1 次提交
  13. 24 2月, 2008 1 次提交
  14. 18 2月, 2008 1 次提交
  15. 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
  16. 29 1月, 2008 15 次提交