1. 16 Oct, 2010 3 commits
    • 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 12 commits