1. 04 11月, 2009 1 次提交
  2. 29 10月, 2009 1 次提交
  3. 21 10月, 2009 1 次提交
  4. 02 9月, 2009 1 次提交
    • A
      netns: embed ip6_dst_ops directly · 86393e52
      Alexey Dobriyan 提交于
      struct net::ipv6.ip6_dst_ops is separatedly dynamically allocated,
      but there is no fundamental reason for it. Embed it directly into
      struct netns_ipv6.
      
      For that:
      * move struct dst_ops into separate header to fix circular dependencies
      	I honestly tried not to, it's pretty impossible to do other way
      * drop dynamical allocation, allocate together with netns
      
      For a change, remove struct dst_ops::dst_net, it's deducible
      by using container_of() given dst_ops pointer.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      86393e52
  5. 03 6月, 2009 1 次提交
  6. 26 11月, 2008 1 次提交
  7. 17 11月, 2008 1 次提交
    • E
      net: make sure struct dst_entry refcount is aligned on 64 bytes · 5635c10d
      Eric Dumazet 提交于
      As found in the past (commit f1dd9c37
      [NET]: Fix tbench regression in 2.6.25-rc1), it is really
      important that struct dst_entry refcount is aligned on a cache line.
      
      We cannot use __atribute((aligned)), so manually pad the structure
      for 32 and 64 bit arches.
      
      for 32bit : offsetof(truct dst_entry, __refcnt) is 0x80
      for 64bit : offsetof(truct dst_entry, __refcnt) is 0xc0
      
      As it is not possible to guess at compile time cache line size,
      we use a generic value of 64 bytes, that satisfies many current arches.
      (Using 128 bytes alignment on 64bit arches would waste 64 bytes)
      
      Add a BUILD_BUG_ON to catch future updates to "struct dst_entry" dont
      break this alignment.
      
      "tbench 8" is 4.4 % faster on a dual quad core (HP BL460c G1), Intel E5450 @3.00GHz
      (2350 MB/s instead of 2250 MB/s)
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5635c10d
  8. 12 11月, 2008 1 次提交
  9. 29 10月, 2008 1 次提交
  10. 05 8月, 2008 1 次提交
  11. 19 7月, 2008 1 次提交
    • S
      tcp: RTT metrics scaling · c1e20f7c
      Stephen Hemminger 提交于
      Some of the metrics (RTT, RTTVAR and RTAX_RTO_MIN) are stored in
      kernel units (jiffies) and this leaks out through the netlink API to
      user space where the units for jiffies are unknown.
      
      This patches changes the kernel to convert to/from milliseconds. This
      changes the ABI, but milliseconds seemed like the most natural unit
      for these parameters.  Values available via syscall in
      /proc/net/rt_cache and netlink will be in milliseconds.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c1e20f7c
  12. 28 3月, 2008 1 次提交
  13. 13 3月, 2008 1 次提交
    • Z
      [NET]: Fix tbench regression in 2.6.25-rc1 · f1dd9c37
      Zhang Yanmin 提交于
      Comparing with kernel 2.6.24, tbench result has regression with
      2.6.25-rc1.
      
      1) On 2 quad-core processor stoakley: 4%.
      2) On 4 quad-core processor tigerton: more than 30%.
      
      bisect located below patch.
      
      b4ce9277 is first bad commit
      commit b4ce9277
      Author: Herbert Xu <herbert@gondor.apana.org.au>
      Date:   Tue Nov 13 21:33:32 2007 -0800
      
          [IPV6]: Move nfheader_len into rt6_info
      
          The dst member nfheader_len is only used by IPv6.  It's also currently
          creating a rather ugly alignment hole in struct dst.  Therefore this patch
          moves it from there into struct rt6_info.
      
      Above patch changes the cache line alignment, especially member
      __refcnt. I did a testing by adding 2 unsigned long pading before
      lastuse, so the 3 members, lastuse/__refcnt/__use, are moved to next
      cache line. The performance is recovered.
      
      I created a patch to rearrange the members in struct dst_entry.
      
      With Eric and Valdis Kletnieks's suggestion, I made finer arrangement.
      
      1) Move tclassid under ops in case CONFIG_NET_CLS_ROUTE=y. So
         sizeof(dst_entry)=200 no matter if CONFIG_NET_CLS_ROUTE=y/n. I
         tested many patches on my 16-core tigerton by moving tclassid to
         different place. It looks like tclassid could also have impact on
         performance.  If moving tclassid before metrics, or just don't move
         tclassid, the performance isn't good. So I move it behind metrics.
      
      2) Add comments before __refcnt.
      
      On 16-core tigerton:
      
      If CONFIG_NET_CLS_ROUTE=y, the result with below patch is about 18%
      better than the one without the patch;
      
      If CONFIG_NET_CLS_ROUTE=n, the result with below patch is about 30%
      better than the one without the patch.
      
      With 32bit 2.6.25-rc1 on 8-core stoakley, the new patch doesn't
      introduce regression.
      
      Thank Eric, Valdis, and David!
      Signed-off-by: NZhang Yanmin <yanmin.zhang@intel.com>
      Acked-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f1dd9c37
  14. 29 1月, 2008 9 次提交
  15. 11 11月, 2007 1 次提交
  16. 11 7月, 2007 1 次提交
  17. 25 5月, 2007 1 次提交
    • D
      [XFRM]: Allow packet drops during larval state resolution. · 14e50e57
      David S. Miller 提交于
      The current IPSEC rule resolution behavior we have does not work for a
      lot of people, even though technically it's an improvement from the
      -EAGAIN buisness we had before.
      
      Right now we'll block until the key manager resolves the route.  That
      works for simple cases, but many folks would rather packets get
      silently dropped until the key manager resolves the IPSEC rules.
      
      We can't tell these folks to "set the socket non-blocking" because
      they don't have control over the non-block setting of things like the
      sockets used to resolve DNS deep inside of the resolver libraries in
      libc.
      
      With that in mind I coded up the patch below with some help from
      Herbert Xu which provides packet-drop behavior during larval state
      resolution, controllable via sysctl and off by default.
      
      This lays the framework to either:
      
      1) Make this default at some point or...
      
      2) Move this logic into xfrm{4,6}_policy.c and implement the
         ARP-like resolution queue we've all been dreaming of.
         The idea would be to queue packets to the policy, then
         once the larval state is resolved by the key manager we
         re-resolve the route and push the packets out.  The
         packets would timeout if the rule didn't get resolved
         in a certain amount of time.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14e50e57
  18. 11 2月, 2007 2 次提交
  19. 08 12月, 2006 1 次提交
  20. 29 9月, 2006 1 次提交
  21. 23 9月, 2006 1 次提交
  22. 26 4月, 2006 1 次提交
  23. 08 1月, 2006 1 次提交
    • P
      [XFRM]: Netfilter IPsec output hooks · 16a6677f
      Patrick McHardy 提交于
      Call netfilter hooks before IPsec transforms. Packets visit the
      FORWARD/LOCAL_OUT and POST_ROUTING hook before the first encapsulation
      and the LOCAL_OUT and POST_ROUTING hook before each following tunnel mode
      transform.
      
      Patch from Herbert Xu <herbert@gondor.apana.org.au>:
      
      Move the loop from dst_output into xfrm4_output/xfrm6_output since they're
      the only ones who need to it. xfrm{4,6}_output_one() processes the first SA
      all subsequent transport mode SAs and is called in a loop that calls the
      netfilter hooks between each two calls.
      
      In order to avoid the tail call issue, I've added the inline function
      nf_hook which is nf_hook_slow plus the empty list check.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      16a6677f
  24. 04 1月, 2006 1 次提交
  25. 26 10月, 2005 1 次提交
  26. 20 4月, 2005 1 次提交
  27. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4