1. 22 11月, 2010 1 次提交
    • E
      pktgen: allow faster module unload · 551eaff1
      Eric Dumazet 提交于
      Unloading pktgen module needs ~6 seconds on a 64 cpus machine, to stop
      64 kthreads.
      
      Add a pktgen_exiting variable to let kernel threads die faster, so that
      kthread_stop() doesnt have to wait too long for them. This variable is
      not tested in fast path.
      
      Note : Before exiting from pktgen_thread_worker(), we must make sure
      kthread_stop() is waiting for this thread to be stopped, like its done
      in kernel/softirq.c
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      551eaff1
  2. 19 11月, 2010 1 次提交
  3. 09 11月, 2010 1 次提交
  4. 07 11月, 2010 1 次提交
  5. 29 10月, 2010 1 次提交
  6. 25 10月, 2010 1 次提交
  7. 22 9月, 2010 1 次提交
  8. 01 9月, 2010 1 次提交
  9. 24 7月, 2010 1 次提交
  10. 13 7月, 2010 1 次提交
  11. 26 6月, 2010 1 次提交
  12. 12 6月, 2010 1 次提交
  13. 11 6月, 2010 1 次提交
  14. 22 3月, 2010 1 次提交
    • R
      pktgen node allocation · e99b99b4
      Robert Olsson 提交于
      Here is patch to manipulate packet node allocation and implicitly
      how packets are DMA'd etc.
      
      The flag NODE_ALLOC enables the function and numa_node_id();
      when enabled it can also be explicitly controlled via a new
      node parameter
      
      Tested this with 10 Intel 82599 ports w. TYAN S7025 E5520 CPU's.
      Was able to TX/DMA ~80 Gbit/s to Ethernet wires.
      Signed-off-by: NRobert Olsson <robert.olsson@its.uu.se>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e99b99b4
  15. 23 2月, 2010 1 次提交
  16. 05 2月, 2010 1 次提交
  17. 24 12月, 2009 1 次提交
  18. 30 11月, 2009 1 次提交
  19. 29 11月, 2009 1 次提交
    • E
      pktgen: NUMA aware · 3291b9db
      Eric Dumazet 提交于
      pktgen threads are bound to given CPU, we can allocate memory for
      these threads in a NUMA aware way.
      
      After a pktgen session on two threads, we can check flows memory was
      allocated on right node, instead of a not related one.
      
      # grep pktgen_thread_write /proc/vmallocinfo
      0xffffc90007204000-0xffffc90007385000 1576960 pktgen_thread_write+0x3a4/0x6b0 [pktgen] pages=384 vmalloc N0=384
      0xffffc90007386000-0xffffc90007507000 1576960 pktgen_thread_write+0x3a4/0x6b0 [pktgen] pages=384 vmalloc N1=384
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3291b9db
  20. 25 11月, 2009 1 次提交
  21. 24 11月, 2009 1 次提交
    • E
      pktgen: Fix device name compares · 593f63b0
      Eric Dumazet 提交于
      Commit e6fce5b9 (pktgen: multiqueue etc.) tried to relax
      the pktgen restriction of one device per kernel thread, adding a '@'
      tag to device names.
      
      Problem is we dont perform check on full pktgen device name.
      This allows adding many time same 'device' to pktgen thread
      
       pgset "add_device eth0@0"
      
      one session later :
      
       pgset "add_device eth0@0"
      
      (This doesnt find previous device)
      
      This consumes ~1.5 MBytes of vmalloc memory per round and also triggers
      this warning :
      
      [  673.186380] proc_dir_entry 'pktgen/eth0@0' already registered
      [  673.186383] Modules linked in: pktgen ixgbe ehci_hcd psmouse mdio mousedev evdev [last unloaded: pktgen]
      [  673.186406] Pid: 6219, comm: bash Tainted: G        W  2.6.32-rc7-03302-g41cec6f1-dirty #16
      [  673.186410] Call Trace:
      [  673.186417]  [<ffffffff8104a29b>] warn_slowpath_common+0x7b/0xc0
      [  673.186422]  [<ffffffff8104a341>] warn_slowpath_fmt+0x41/0x50
      [  673.186426]  [<ffffffff8114e789>] proc_register+0x109/0x210
      [  673.186433]  [<ffffffff8100bf2e>] ? apic_timer_interrupt+0xe/0x20
      [  673.186438]  [<ffffffff8114e905>] proc_create_data+0x75/0xd0
      [  673.186444]  [<ffffffffa006ad38>] pktgen_thread_write+0x568/0x640 [pktgen]
      [  673.186449]  [<ffffffffa006a7d0>] ? pktgen_thread_write+0x0/0x640 [pktgen]
      [  673.186453]  [<ffffffff81149144>] proc_reg_write+0x84/0xc0
      [  673.186458]  [<ffffffff810f5a58>] vfs_write+0xb8/0x180
      [  673.186463]  [<ffffffff810f5c11>] sys_write+0x51/0x90
      [  673.186468]  [<ffffffff8100b51b>] system_call_fastpath+0x16/0x1b
      [  673.186470] ---[ end trace ccbb991b0a8d994d ]---
      
      Solution to this problem is to use a odevname field (includes @ tag and suffix),
      instead of using netdevice name.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NRobert Olsson <robert.olsson@its.uu.se>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      593f63b0
  22. 06 11月, 2009 1 次提交
  23. 24 10月, 2009 1 次提交
  24. 05 10月, 2009 3 次提交
  25. 02 10月, 2009 1 次提交
  26. 25 9月, 2009 2 次提交
  27. 01 9月, 2009 1 次提交
  28. 29 8月, 2009 10 次提交