1. 10 5月, 2011 1 次提交
    • A
      net: add mac_pton() for parsing MAC address · 4940fc88
      Alexey Dobriyan 提交于
      mac_pton() parses MAC address in form XX:XX:XX:XX:XX:XX and only in that form.
      
      mac_pton() doesn't dirty result until it's sure string representation is valid.
      
      mac_pton() doesn't care about characters _after_ last octet,
      it's up to caller to deal with it.
      
      mac_pton() diverges from 0/-E return value convention.
      Target usage:
      
      	if (!mac_pton(str, whatever->mac))
      		return -EINVAL;
      	/* ->mac being u8 [ETH_ALEN] is filled at this point. */
      	/* optionally check str[3 * ETH_ALEN - 1] for termination */
      
      Use mac_pton() in pktgen and netconsole for start.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4940fc88
  2. 09 5月, 2011 1 次提交
  3. 30 4月, 2011 1 次提交
  4. 17 4月, 2011 1 次提交
  5. 23 3月, 2011 1 次提交
  6. 15 3月, 2011 1 次提交
  7. 10 3月, 2011 1 次提交
  8. 26 1月, 2011 1 次提交
    • E
      pktgen: speedup fragmented skbs · 26ad7879
      Eric Dumazet 提交于
      We spend lot of time clearing pages in pktgen.
      (Or not clearing them on ipv6 and leaking kernel memory)
      
      Since we dont modify them, we can use one zeroed page, and get
      references on it. This page can use NUMA affinity as well.
      
      Define pktgen_finalize_skb() helper, used both in ipv4 and ipv6
      
      Results using skbs with one frag :
      
      Before patch :
      
      Result: OK: 608980458(c608978520+d1938) nsec, 1000000000
      (100byte,1frags)
        1642088pps 1313Mb/sec (1313670400bps) errors: 0
      
      After patch :
      
      Result: OK: 345285014(c345283891+d1123) nsec, 1000000000
      (100byte,1frags)
        2896158pps 2316Mb/sec (2316926400bps) errors: 0
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      26ad7879
  9. 21 12月, 2010 1 次提交
  10. 11 12月, 2010 1 次提交
  11. 29 11月, 2010 1 次提交
  12. 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
  13. 19 11月, 2010 1 次提交
  14. 09 11月, 2010 1 次提交
  15. 07 11月, 2010 1 次提交
  16. 29 10月, 2010 1 次提交
  17. 25 10月, 2010 1 次提交
  18. 22 9月, 2010 1 次提交
  19. 01 9月, 2010 1 次提交
  20. 24 7月, 2010 1 次提交
  21. 13 7月, 2010 1 次提交
  22. 26 6月, 2010 1 次提交
  23. 12 6月, 2010 1 次提交
  24. 11 6月, 2010 1 次提交
  25. 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
  26. 23 2月, 2010 1 次提交
  27. 05 2月, 2010 1 次提交
  28. 24 12月, 2009 1 次提交
  29. 30 11月, 2009 1 次提交
  30. 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
  31. 25 11月, 2009 1 次提交
  32. 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
  33. 06 11月, 2009 1 次提交
  34. 24 10月, 2009 1 次提交
  35. 05 10月, 2009 3 次提交
  36. 02 10月, 2009 1 次提交
  37. 25 9月, 2009 2 次提交