1. 18 6月, 2006 2 次提交
    • W
      [TCP]: TCP Low Priority congestion control · 7c106d7e
      Wong Hoi Sing Edison 提交于
       TCP Low Priority is a distributed algorithm whose goal is to utilize only
       the excess network bandwidth as compared to the ``fair share`` of
       bandwidth as targeted by TCP. Available from:
         http://www.ece.rice.edu/~akuzma/Doc/akuzma/TCP-LP.pdf
      
      Original Author:
       Aleksandar Kuzmanovic <akuzma@northwestern.edu>
      
      See http://www-ece.rice.edu/networks/TCP-LP/ for their implementation.
      As of 2.6.13, Linux supports pluggable congestion control algorithms.
      Due to the limitation of the API, we take the following changes from
      the original TCP-LP implementation:
       o We use newReno in most core CA handling. Only add some checking
         within cong_avoid.
       o Error correcting in remote HZ, therefore remote HZ will be keeped
         on checking and updating.
       o Handling calculation of One-Way-Delay (OWD) within rtt_sample, sicne
         OWD have a similar meaning as RTT. Also correct the buggy formular.
       o Handle reaction for Early Congestion Indication (ECI) within
         pkts_acked, as mentioned within pseudo code.
       o OWD is handled in relative format, where local time stamp will in
         tcp_time_stamp format.
      
      Port from 2.4.19 to 2.6.16 as module by:
       Wong Hoi Sing Edison <hswong3i@gmail.com>
       Hung Hing Lun <hlhung3i@gmail.com>
      Signed-off-by: NWong Hoi Sing Edison <hswong3i@gmail.com>
      Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c106d7e
    • H
      [IPSEC] xfrm: Abstract out encapsulation modes · b59f45d0
      Herbert Xu 提交于
      This patch adds the structure xfrm_mode.  It is meant to represent
      the operations carried out by transport/tunnel modes.
      
      By doing this we allow additional encapsulation modes to be added
      without clogging up the xfrm_input/xfrm_output paths.
      
      Candidate modes include 4-to-6 tunnel mode, 6-to-4 tunnel mode, and
      BEET modes.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b59f45d0
  2. 29 3月, 2006 1 次提交
    • H
      [INET]: Introduce tunnel4/tunnel6 · d2acc347
      Herbert Xu 提交于
      Basically this patch moves the generic tunnel protocol stuff out of
      xfrm4_tunnel/xfrm6_tunnel and moves it into the new files of tunnel4.c
      and tunnel6 respectively.
      
      The reason for this is that the problem that Hugo uncovered is only
      the tip of the iceberg.  The real problem is that when we removed the
      dependency of ipip on xfrm4_tunnel we didn't really consider the module
      case at all.
      
      For instance, as it is it's possible to build both ipip and xfrm4_tunnel
      as modules and if the latter is loaded then ipip simply won't load.
      
      After considering the alternatives I've decided that the best way out of
      this is to restore the dependency of ipip on the non-xfrm-specific part
      of xfrm4_tunnel.  This is acceptable IMHO because the intention of the
      removal was really to be able to use ipip without the xfrm subsystem.
      This is still preserved by this patch.
      
      So now both ipip/xfrm4_tunnel depend on the new tunnel4.c which handles
      the arbitration between the two.  The order of processing is determined
      by a simple integer which ensures that ipip gets processed before
      xfrm4_tunnel.
      
      The situation for ICMP handling is a little bit more complicated since
      we may not have enough information to determine who it's for.  It's not
      a big deal at the moment since the xfrm ICMP handlers are basically
      no-ops.  In future we can deal with this when we look at ICMP caching
      in general.
      
      The user-visible change to this is the removal of the TUNNEL Kconfig
      prompts.  This makes sense because it can only be used through IPCOMP
      as it stands.
      
      The addition of the new modules shouldn't introduce any problems since
      module dependency will cause them to be loaded.
      
      Oh and I also turned some unnecessary pskb's in IPv6 related to this
      patch to skb's.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d2acc347
  3. 11 1月, 2006 1 次提交
  4. 04 1月, 2006 1 次提交
  5. 30 8月, 2005 7 次提交
  6. 28 7月, 2005 1 次提交
  7. 24 6月, 2005 8 次提交
  8. 22 6月, 2005 1 次提交
  9. 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