1. 17 12月, 2010 3 次提交
  2. 09 12月, 2010 3 次提交
  3. 07 12月, 2010 1 次提交
  4. 02 12月, 2010 1 次提交
  5. 29 11月, 2010 1 次提交
  6. 25 11月, 2010 2 次提交
    • T
      xps: Transmit Packet Steering · 1d24eb48
      Tom Herbert 提交于
      This patch implements transmit packet steering (XPS) for multiqueue
      devices.  XPS selects a transmit queue during packet transmission based
      on configuration.  This is done by mapping the CPU transmitting the
      packet to a queue.  This is the transmit side analogue to RPS-- where
      RPS is selecting a CPU based on receive queue, XPS selects a queue
      based on the CPU (previously there was an XPS patch from Eric
      Dumazet, but that might more appropriately be called transmit completion
      steering).
      
      Each transmit queue can be associated with a number of CPUs which will
      use the queue to send packets.  This is configured as a CPU mask on a
      per queue basis in:
      
      /sys/class/net/eth<n>/queues/tx-<n>/xps_cpus
      
      The mappings are stored per device in an inverted data structure that
      maps CPUs to queues.  In the netdevice structure this is an array of
      num_possible_cpu structures where each structure holds and array of
      queue_indexes for queues which that CPU can use.
      
      The benefits of XPS are improved locality in the per queue data
      structures.  Also, transmit completions are more likely to be done
      nearer to the sending thread, so this should promote locality back
      to the socket on free (e.g. UDP).  The benefits of XPS are dependent on
      cache hierarchy, application load, and other factors.  XPS would
      nominally be configured so that a queue would only be shared by CPUs
      which are sharing a cache, the degenerative configuration woud be that
      each CPU has it's own queue.
      
      Below are some benchmark results which show the potential benfit of
      this patch.  The netperf test has 500 instances of netperf TCP_RR test
      with 1 byte req. and resp.
      
      bnx2x on 16 core AMD
         XPS (16 queues, 1 TX queue per CPU)  1234K at 100% CPU
         No XPS (16 queues)                   996K at 100% CPU
      Signed-off-by: NTom Herbert <therbert@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d24eb48
    • T
      xps: Improvements in TX queue selection · 3853b584
      Tom Herbert 提交于
      In dev_pick_tx, don't do work in calculating queue
      index or setting
      the index in the sock unless the device has more than one queue.  This
      allows the sock to be set only with a queue index of a multi-queue
      device which is desirable if device are stacked like in a tunnel.
      
      We also allow the mapping of a socket to queue to be changed.  To
      maintain in order packet transmission a flag (ooo_okay) has been
      added to the sk_buff structure.  If a transport layer sets this flag
      on a packet, the transmit queue can be changed for the socket.
      Presumably, the transport would set this if there was no possbility
      of creating OOO packets (for instance, there are no packets in flight
      for the socket).  This patch includes the modification in TCP output
      for setting this flag.
      Signed-off-by: NTom Herbert <therbert@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3853b584
  7. 16 11月, 2010 6 次提交
  8. 10 11月, 2010 1 次提交
  9. 02 11月, 2010 1 次提交
  10. 28 10月, 2010 2 次提交
  11. 26 10月, 2010 3 次提交
  12. 21 10月, 2010 4 次提交
    • S
      napi: unexport napi_reuse_skb · d0c2b0d2
      stephen hemminger 提交于
      The function napi_reuse_skb is only used inside core.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0c2b0d2
    • B
      net/core: Allow tagged VLAN packets to flow through VETH devices. · d2ed8177
      Ben Greear 提交于
      When there are VLANs on a VETH device, the packets being transmitted
      through the VETH device may be 4 bytes bigger than MTU.  A check
      in dev_forward_skb did not take this into account and so dropped
      these packets.
      
      This patch is needed at least as far back as 2.6.34.7 and should
      be considered for -stable.
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d2ed8177
    • J
      vlan: Centralize handling of hardware acceleration. · 3701e513
      Jesse Gross 提交于
      Currently each driver that is capable of vlan hardware acceleration
      must be aware of the vlan groups that are configured and then pass
      the stripped tag to a specialized receive function.  This is
      
      different from other types of hardware offload in that it places a
      significant amount of knowledge in the driver itself rather keeping
      it in the networking core.
      
      This makes vlan offloading function more similarly to other forms
      of offloading (such as checksum offloading or TSO) by doing the
      following:
      * On receive, stripped vlans are passed directly to the network
      core, without attempting to check for vlan groups or reconstructing
      the header if no group
      * vlans are made less special by folding the logic into the main
      receive routines
      * On transmit, the device layer will add the vlan header in software
      if the hardware doesn't support it, instead of spreading that logic
      out in upper layers, such as bonding.
      
      There are a number of advantages to this:
      * Fixes all bugs with drivers incorrectly dropping vlan headers at once.
      * Avoids having to disable VLAN acceleration when in promiscuous mode
      (good for bridging since it always puts devices in promiscuous mode).
      * Keeps VLAN tag separate until given to ultimate consumer, which
      avoids needing to do header reconstruction as in tg3 unless absolutely
      necessary.
      * Consolidates common code in core networking.
      Signed-off-by: NJesse Gross <jesse@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3701e513
    • J
      vlan: Enable software emulation for vlan accleration. · 7b9c6090
      Jesse Gross 提交于
      Currently users of hardware vlan accleration need to know whether
      the device supports it before generating packets.  However, vlan
      acceleration will soon be available in a more flexible manner so
      knowing ahead of time becomes much more difficult.  This adds
      a software fallback path for vlan packets on devices without the
      necessary offloading support, similar to other types of hardware
      accleration.
      Signed-off-by: NJesse Gross <jesse@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7b9c6090
  13. 20 10月, 2010 3 次提交
  14. 13 10月, 2010 1 次提交
    • E
      net: percpu net_device refcount · 29b4433d
      Eric Dumazet 提交于
      We tried very hard to remove all possible dev_hold()/dev_put() pairs in
      network stack, using RCU conversions.
      
      There is still an unavoidable device refcount change for every dst we
      create/destroy, and this can slow down some workloads (routers or some
      app servers, mmap af_packet)
      
      We can switch to a percpu refcount implementation, now dynamic per_cpu
      infrastructure is mature. On a 64 cpus machine, this consumes 256 bytes
      per device.
      
      On x86, dev_hold(dev) code :
      
      before
              lock    incl 0x280(%ebx)
      after:
              movl    0x260(%ebx),%eax
              incl    fs:(%eax)
      
      Stress bench :
      
      (Sending 160.000.000 UDP frames,
      IP route cache disabled, dual E5540 @2.53GHz,
      32bit kernel, FIB_TRIE)
      
      Before:
      
      real    1m1.662s
      user    0m14.373s
      sys     12m55.960s
      
      After:
      
      real    0m51.179s
      user    0m15.329s
      sys     10m15.942s
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      29b4433d
  15. 09 10月, 2010 2 次提交
  16. 07 10月, 2010 1 次提交
  17. 06 10月, 2010 1 次提交
    • E
      net: add a core netdev->rx_dropped counter · caf586e5
      Eric Dumazet 提交于
      In various situations, a device provides a packet to our stack and we
      drop it before it enters protocol stack :
      - softnet backlog full (accounted in /proc/net/softnet_stat)
      - bad vlan tag (not accounted)
      - unknown/unregistered protocol (not accounted)
      
      We can handle a per-device counter of such dropped frames at core level,
      and automatically adds it to the device provided stats (rx_dropped), so
      that standard tools can be used (ifconfig, ip link, cat /proc/net/dev)
      
      This is a generalization of commit 8990f468 (net: rx_dropped
      accounting), thus reverting it.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      caf586e5
  18. 05 10月, 2010 1 次提交
  19. 30 9月, 2010 2 次提交
  20. 28 9月, 2010 1 次提交