1. 18 5月, 2009 1 次提交
  2. 05 5月, 2009 1 次提交
    • I
      tcp: extend ECN sysctl to allow server-side only ECN · 255cac91
      Ilpo Järvinen 提交于
      This should be very safe compared with full enabled, so I see
      no reason why it shouldn't be done right away. As ECN can only
      be negotiated if the SYN sending party is also supporting it,
      somebody in the loop probably knows what he/she is doing. If
      SYN does not ask for ECN, the server side SYN-ACK is identical
      to what it is without ECN. Thus it's quite safe.
      
      The chosen value is safe w.r.t to existing configs which
      choose to currently set manually either 0 or 1 but
      silently upgrades those who have not explicitly requested
      ECN off.
      
      Whether to just enable both sides comes up time to time but
      unless that gets done now we can at least make the servers
      aware of ECN already. As there are some known problems to occur
      if ECN is enabled, it's currently questionable whether there's
      any real gain from enabling clients as servers mostly won't
      support it anyway (so we'd hit just the negative sides). After
      enabling the servers and getting that deployed, the client end
      enable really has some potential gain too.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      255cac91
  3. 19 3月, 2009 1 次提交
    • B
      ipv6: Fix incorrect disable_ipv6 behavior · 9bdd8d40
      Brian Haley 提交于
      Fix the behavior of allowing both sysctl and addrconf_dad_failure()
      to set the disable_ipv6 parameter without any bad side-effects.
      If DAD fails and accept_dad > 1, we will still set disable_ipv6=1,
      but then instead of allowing an RA to add an address then
      immediately fail DAD, we simply don't allow the address to be
      added in the first place.  This also lets the user set this flag
      and disable all IPv6 addresses on the interface, or on the entire
      system.
      Signed-off-by: NBrian Haley <brian.haley@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9bdd8d40
  4. 24 2月, 2009 2 次提交
  5. 23 2月, 2009 1 次提交
  6. 01 2月, 2009 1 次提交
  7. 28 10月, 2008 1 次提交
    • N
      net: implement emergency route cache rebulds when gc_elasticity is exceeded · 1080d709
      Neil Horman 提交于
      This is a patch to provide on demand route cache rebuilding.  Currently, our
      route cache is rebulid periodically regardless of need.  This introduced
      unneeded periodic latency.  This patch offers a better approach.  Using code
      provided by Eric Dumazet, we compute the standard deviation of the average hash
      bucket chain length while running rt_check_expire.  Should any given chain
      length grow to larger that average plus 4 standard deviations, we trigger an
      emergency hash table rebuild for that net namespace.  This allows for the common
      case in which chains are well behaved and do not grow unevenly to not incur any
      latency at all, while those systems (which may be being maliciously attacked),
      only rebuild when the attack is detected.  This patch take 2 other factors into
      account:
      1) chains with multiple entries that differ by attributes that do not affect the
      hash value are only counted once, so as not to unduly bias system to rebuilding
      if features like QOS are heavily used
      2) if rebuilding crosses a certain threshold (which is adjustable via the added
      sysctl in this patch), route caching is disabled entirely for that net
      namespace, since constant rebuilding is less efficient that no caching at all
      
      Tested successfully by me.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1080d709
  8. 11 7月, 2008 2 次提交
  9. 09 7月, 2008 1 次提交
  10. 03 7月, 2008 2 次提交
  11. 02 7月, 2008 2 次提交
  12. 29 1月, 2008 1 次提交
  13. 26 10月, 2007 1 次提交
  14. 20 10月, 2007 1 次提交
  15. 11 10月, 2007 1 次提交
  16. 12 7月, 2007 1 次提交
  17. 11 7月, 2007 1 次提交
  18. 26 4月, 2007 3 次提交
  19. 25 4月, 2007 1 次提交
  20. 01 3月, 2007 1 次提交
  21. 03 12月, 2006 3 次提交
  22. 04 10月, 2006 2 次提交
  23. 23 9月, 2006 2 次提交
  24. 18 9月, 2006 1 次提交
  25. 18 8月, 2006 1 次提交
  26. 18 6月, 2006 1 次提交
  27. 21 3月, 2006 4 次提交