1. 13 7月, 2010 1 次提交
  2. 26 6月, 2010 1 次提交
  3. 12 6月, 2010 1 次提交
  4. 11 6月, 2010 1 次提交
  5. 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
  6. 23 2月, 2010 1 次提交
  7. 05 2月, 2010 1 次提交
  8. 24 12月, 2009 1 次提交
  9. 30 11月, 2009 1 次提交
  10. 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
  11. 25 11月, 2009 1 次提交
  12. 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
  13. 06 11月, 2009 1 次提交
  14. 24 10月, 2009 1 次提交
  15. 05 10月, 2009 3 次提交
  16. 02 10月, 2009 1 次提交
  17. 25 9月, 2009 2 次提交
  18. 01 9月, 2009 1 次提交
  19. 29 8月, 2009 15 次提交
  20. 08 6月, 2009 1 次提交
  21. 26 5月, 2009 1 次提交
    • E
      net: txq_trans_update() helper · 08baf561
      Eric Dumazet 提交于
      We would like to get rid of netdev->trans_start = jiffies; that about all net
      drivers have to use in their start_xmit() function, and use txq->trans_start
      instead.
      
      This can be done generically in core network, as suggested by David.
      
      Some devices, (particularly loopback) dont need trans_start update, because
      they dont have transmit watchdog. We could add a new device flag, or rely
      on fact that txq->tran_start can be updated is txq->xmit_lock_owner is
      different than -1. Use a helper function to hide our choice.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      08baf561
  22. 22 5月, 2009 1 次提交
  23. 31 3月, 2009 1 次提交
    • A
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      Alexey Dobriyan 提交于
      Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
      as correctly noted at bug #12454. Someone can lookup entry with NULL
      ->owner, thus not pinning enything, and release it later resulting
      in module refcount underflow.
      
      We can keep ->owner and supply it at registration time like ->proc_fops
      and ->data.
      
      But this leaves ->owner as easy-manipulative field (just one C assignment)
      and somebody will forget to unpin previous/pin current module when
      switching ->owner. ->proc_fops is declared as "const" which should give
      some thoughts.
      
      ->read_proc/->write_proc were just fixed to not require ->owner for
      protection.
      
      rmmod'ed directories will be empty and return "." and ".." -- no harm.
      And directories with tricky enough readdir and lookup shouldn't be modular.
      We definitely don't want such modular code.
      
      Removing ->owner will also make PDE smaller.
      
      So, let's nuke it.
      
      Kudos to Jeff Layton for reminding about this, let's say, oversight.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      99b76233