1. 21 Oct, 2010 38 commits
  2. 20 Oct, 2010 2 commits
    • Eric Dumazet's avatar
      net: avoid RCU for NOCACHE dst · 27b75c95
      Eric Dumazet authored
      There is no point using RCU for dst we allocate for a very short time
      (used once).
      
      Change dst_release() to take DST_NOCACHE into account, but also change
      skb_dst_set_noref() to force a refcount increment for such dst.
      
      This is a _huge_ gain, because we dont waste memory to store xx thousand
      of dsts. Instead of queueing them to RCU, we can free them instantly.
      
      CPU caches can stay hot, re-using same memory blocks to hold temporary
      dsts.
      
      Note : remove unneeded smp_mb__before_atomic_dec(); in dst_release(),
      since atomic_dec_return() implies a full memory barrier.
      
      Stress test, 160.000.000 udp frames sent, IP route cache disabled
      (DDOS).
      
      Before:
      
      real    0m38.091s
      user    0m13.189s
      sys     7m53.018s
      
      After:
      
      real	0m29.946s
      user	0m12.157s
      sys	7m40.605s
      
      For reference, if IP route cache was enabled :
      
      real	0m32.030s
      user	0m10.521s
      sys	8m15.243s
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      27b75c95
    • Tom Herbert's avatar
      net: allocate tx queues in register_netdevice · e6484930
      Tom Herbert authored
      This patch introduces netif_alloc_netdev_queues which is called from
      register_device instead of alloc_netdev_mq.  This makes TX queue
      allocation symmetric with RX allocation.  Also, queue locks allocation
      is done in netdev_init_one_queue.  Change set_real_num_tx_queues to
      fail if requested number < 1 or greater than number of allocated
      queues.
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e6484930