1. 06 5月, 2011 1 次提交
  2. 30 4月, 2011 1 次提交
    • B
      ipv4, ipv6, bonding: Restore control over number of peer notifications · ad246c99
      Ben Hutchings 提交于
      For backward compatibility, we should retain the module parameters and
      sysfs attributes to control the number of peer notifications
      (gratuitous ARPs and unsolicited NAs) sent after bonding failover.
      Also, it is possible for failover to take place even though the new
      active slave does not have link up, and in that case the peer
      notification should be deferred until it does.
      
      Change ipv4 and ipv6 so they do not automatically send peer
      notifications on bonding failover.
      
      Change the bonding driver to send separate NETDEV_NOTIFY_PEERS
      notifications when the link is up, as many times as requested.  Since
      it does not directly control which protocols send notifications, make
      num_grat_arp and num_unsol_na aliases for a single parameter.  Bump
      the bonding version number and update its documentation.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Acked-by: NBrian Haley <brian.haley@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad246c99
  3. 26 4月, 2011 1 次提交
    • J
      bonding: move processing of recv handlers into handle_frame() · 3aba891d
      Jiri Pirko 提交于
      Since now when bonding uses rx_handler, all traffic going into bond
      device goes thru bond_handle_frame. So there's no need to go back into
      bonding code later via ptype handlers. This patch converts
      original ptype handlers into "bonding receive probes". These functions
      are called from bond_handle_frame and they are registered per-mode.
      
      Note that vlan packets are also handled because they are always untagged
      thanks to vlan_untag()
      
      Note that this also allows arpmon for eth-bond-bridge-vlan topology.
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3aba891d
  4. 20 4月, 2011 1 次提交
    • J
      bonding: 802.3ad - fix agg_device_up · 2430af8b
      Jiri Bohac 提交于
      The slave member of struct aggregator does not necessarily point
      to a slave which is part of the aggregator. It points to the
      slave structure containing the aggregator structure, while
      completely different slaves (or no slaves at all) may be part of
      the aggregator.
      
      The agg_device_up() function wrongly uses agg->slave to find the state
      of the aggregator.  Use agg->lag_ports->slave instead. The bug has
      been introduced by commit 4cd6fe1c
      ("bonding: fix link down handling in 802.3ad mode").
      Signed-off-by: NJiri Bohac <jbohac@suse.cz>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2430af8b
  5. 18 4月, 2011 1 次提交
  6. 17 4月, 2011 1 次提交
  7. 15 4月, 2011 3 次提交
  8. 12 4月, 2011 5 次提交
  9. 05 4月, 2011 1 次提交
    • T
      net: Allow no-cache copy from user on transmit · c6e1a0d1
      Tom Herbert 提交于
      This patch uses __copy_from_user_nocache on transmit to bypass data
      cache for a performance improvement.  skb_add_data_nocache and
      skb_copy_to_page_nocache can be called by sendmsg functions to use
      this feature, initial support is in tcp_sendmsg.  This functionality is
      configurable per device using ethtool.
      
      Presumably, this feature would only be useful when the driver does
      not touch the data.  The feature is turned on by default if a device
      indicates that it does some form of checksum offload; it is off by
      default for devices that do no checksum offload or indicate no checksum
      is necessary.  For the former case copy-checksum is probably done
      anyway, in the latter case the device is likely loopback in which case
      the no cache copy is probably not beneficial.
      
      This patch was tested using 200 instances of netperf TCP_RR with
      1400 byte request and one byte reply.  Platform is 16 core AMD x86.
      
      No-cache copy disabled:
         672703 tps, 97.13% utilization
         50/90/99% latency:244.31 484.205 1028.41
      
      No-cache copy enabled:
         702113 tps, 96.16% utilization,
         50/90/99% latency 238.56 467.56 956.955
      
      Using 14000 byte request and response sizes demonstrate the
      effects more dramatically:
      
      No-cache copy disabled:
         79571 tps, 34.34 %utlization
         50/90/95% latency 1584.46 2319.59 5001.76
      
      No-cache copy enabled:
         83856 tps, 34.81% utilization
         50/90/95% latency 2508.42 2622.62 2735.88
      
      Note especially the effect on latency tail (95th percentile).
      
      This seems to provide a nice performance improvement and is
      consistent in the tests I ran.  Presumably, this would provide
      the greatest benfits in the presence of an application workload
      stressing the cache and a lot of transmit data happening.
      Signed-off-by: NTom Herbert <therbert@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c6e1a0d1
  10. 31 3月, 2011 2 次提交
  11. 24 3月, 2011 1 次提交
  12. 20 3月, 2011 1 次提交
  13. 17 3月, 2011 6 次提交
  14. 16 3月, 2011 3 次提交
  15. 13 3月, 2011 1 次提交
  16. 10 3月, 2011 1 次提交
  17. 08 3月, 2011 4 次提交
  18. 03 3月, 2011 1 次提交
  19. 01 3月, 2011 2 次提交
  20. 28 2月, 2011 3 次提交