1. 16 Oct, 2010 5 commits
    • Dan Carpenter's avatar
      pch_gbe: fix if condition in set_settings() · 89980827
      Dan Carpenter authored
      There were no curly braces in this if condition so it always enabled full
      duplex.
      
      And ecmd->speed is an unsigned short so it is never equal to -1.  The
      effect is that mii_ethtool_sset() fails with -EINVAL and an error is
      printed to dmesg.
      Signed-off-by: default avatarDan Carpenter <error27@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      89980827
    • Harvey Harrison's avatar
      dnet: mark methods static and annotate for correct endianness · 35f2516f
      Harvey Harrison authored
      Their doesn't appear to be bugs with the endianness handling here, just get the
      annotations right to keep sparse happy.
      
      Suppresses the following sparse warnings:
      drivers/net/dnet.c:30:5: warning: symbol 'dnet_readw_mac' was not declared. Should it be static?
      drivers/net/dnet.c:49:6: warning: symbol 'dnet_writew_mac' was not declared. Should it be static?
      drivers/net/dnet.c:364:5: warning: symbol 'dnet_phy_marvell_fixup' was not declared. Should it be static?
      drivers/net/dnet.c:66:13: warning: incorrect type in assignment (different base types)
      drivers/net/dnet.c:66:13:    expected unsigned short [unsigned] [usertype] tmp
      drivers/net/dnet.c:66:13:    got restricted __be16 [usertype] <noident>
      drivers/net/dnet.c:68:13: warning: incorrect type in assignment (different base types)
      drivers/net/dnet.c:68:13:    expected unsigned short [unsigned] [usertype] tmp
      drivers/net/dnet.c:68:13:    got restricted __be16 [usertype] <noident>
      drivers/net/dnet.c:70:13: warning: incorrect type in assignment (different base types)
      drivers/net/dnet.c:70:13:    expected unsigned short [unsigned] [usertype] tmp
      drivers/net/dnet.c:70:13:    got restricted __be16 [usertype] <noident>
      drivers/net/dnet.c:92:27: warning: cast to restricted __be16
      drivers/net/dnet.c:94:33: warning: cast to restricted __be16
      drivers/net/dnet.c:96:33: warning: cast to restricted __be16
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      35f2516f
    • Harvey Harrison's avatar
      cxgb4vf: make single bit signed bitfields unsigned · 65495745
      Harvey Harrison authored
      Single bit signed bitfields don't make a lot of sense, noticed by sparse:
      drivers/net/cxgb4vf/t4vf_common.h:135:31: error: dubious one-bit signed bitfield
      drivers/net/cxgb4vf/t4vf_common.h:136:36: error: dubious one-bit signed bitfield
      drivers/net/cxgb4vf/t4vf_common.h:137:36: error: dubious one-bit signed bitfield
      drivers/net/cxgb4vf/t4vf_common.h:138:36: error: dubious one-bit signed bitfield
      drivers/net/cxgb4vf/t4vf_common.h:139:36: error: dubious one-bit signed bitfield
      drivers/net/cxgb4vf/t4vf_common.h:140:31: error: dubious one-bit signed bitfield
      drivers/net/cxgb4vf/t4vf_common.h:141:31: error: dubious one-bit signed bitfield
      drivers/net/cxgb4vf/t4vf_common.h:142:35: error: dubious one-bit signed bitfield
      drivers/net/cxgb4vf/t4vf_common.h:143:35: error: dubious one-bit signed bitfield
      drivers/net/cxgb4vf/t4vf_common.h:154:27: error: dubious one-bit signed bitfield
      drivers/net/cxgb4vf/t4vf_common.h:155:26: error: dubious one-bit signed bitfield
      drivers/net/cxgb4vf/t4vf_common.h:156:27: error: dubious one-bit signed bitfield
      drivers/net/cxgb4vf/t4vf_common.h:157:26: error: dubious one-bit signed bitfield
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      65495745
    • Eric Dumazet's avatar
      net: allocate skbs on local node · 564824b0
      Eric Dumazet authored
      commit b30973f8 (node-aware skb allocation) spread a wrong habit of
      allocating net drivers skbs on a given memory node : The one closest to
      the NIC hardware. This is wrong because as soon as we try to scale
      network stack, we need to use many cpus to handle traffic and hit
      slub/slab management on cross-node allocations/frees when these cpus
      have to alloc/free skbs bound to a central node.
      
      skb allocated in RX path are ephemeral, they have a very short
      lifetime : Extra cost to maintain NUMA affinity is too expensive. What
      appeared as a nice idea four years ago is in fact a bad one.
      
      In 2010, NIC hardwares are multiqueue, or we use RPS to spread the load,
      and two 10Gb NIC might deliver more than 28 million packets per second,
      needing all the available cpus.
      
      Cost of cross-node handling in network and vm stacks outperforms the
      small benefit hardware had when doing its DMA transfert in its 'local'
      memory node at RX time. Even trying to differentiate the two allocations
      done for one skb (the sk_buff on local node, the data part on NIC
      hardware node) is not enough to bring good performance.
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Acked-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      564824b0
    • Eric Dumazet's avatar
      r8169: use 50% less ram for RX ring · 6f0333b8
      Eric Dumazet authored
      Using standard skb allocations in r8169 leads to order-3 allocations (if
      PAGE_SIZE=4096), because NIC needs 16383 bytes, and skb overhead makes
      this bigger than 16384 -> 32768 bytes per "skb"
      
      Using kmalloc() permits to reduce memory requirements of one r8169 nic
      by 4Mbytes. (256 frames * 16Kbytes). This is fine since a hardware bug
      requires us to copy incoming frames, so we build real skb when doing
      this copy.
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f0333b8
  2. 15 Oct, 2010 1 commit
  3. 14 Oct, 2010 11 commits
  4. 13 Oct, 2010 4 commits
  5. 12 Oct, 2010 9 commits
  6. 11 Oct, 2010 10 commits