1. 26 4月, 2007 2 次提交
  2. 10 4月, 2007 1 次提交
    • D
      [TCP]: slow_start_after_idle should influence cwnd validation too · 15d33c07
      David S. Miller 提交于
      For the cases that slow_start_after_idle are meant to deal
      with, it is almost a certainty that the congestion window
      tests will think the connection is application limited and
      we'll thus decrease the cwnd there too.  This defeats the
      whole point of setting slow_start_after_idle to zero.
      
      So test it there too.
      
      We do not cancel out the entire tcp_cwnd_validate() function
      so that if the sysctl is changed we still have the validation
      state maintained.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      15d33c07
  3. 03 4月, 2007 1 次提交
  4. 14 2月, 2007 1 次提交
    • I
      [TCP]: Prevent pseudo garbage in SYN's advertized window · 600ff0c2
      Ilpo Järvinen 提交于
      TCP may advertize up to 16-bits window in SYN packets (no window
      scaling allowed). At the same time, TCP may have rcv_wnd
      (32-bits) that does not fit to 16-bits without window scaling
      resulting in pseudo garbage into advertized window from the
      low-order bits of rcv_wnd. This can happen at least when
      mss <= (1<<wscale) (see tcp_select_initial_window). This patch
      fixes the handling of SYN advertized windows (compile tested
      only).
      
      In worst case (which is unlikely to occur though), the receiver
      advertized window could be just couple of bytes. I'm not sure
      that such situation would be handled very well at all by the
      receiver!? Fortunately, the situation normalizes after the
      first non-SYN ACK is received because it has the correct,
      scaled window.
      
      Alternatively, tcp_select_initial_window could be changed to
      prevent too large rcv_wnd in the first place.
      
      [ tcp_make_synack() has the same bug, and I've added a fix for
        that to this patch -DaveM ]
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      600ff0c2
  5. 11 2月, 2007 1 次提交
  6. 09 2月, 2007 1 次提交
  7. 26 1月, 2007 1 次提交
  8. 24 1月, 2007 1 次提交
  9. 03 12月, 2006 3 次提交
  10. 19 10月, 2006 1 次提交
    • J
      [TCP]: Bound TSO defer time · ae8064ac
      John Heffner 提交于
      This patch limits the amount of time you will defer sending a TSO segment
      to less than two clock ticks, or the time between two acks, whichever is
      longer.
      
      On slow links, deferring causes significant bursts.  See attached plots,
      which show RTT through a 1 Mbps link with a 100 ms RTT and ~100 ms queue
      for (a) non-TSO, (b) currnet TSO, and (c) patched TSO.  This burstiness
      causes significant jitter, tends to overflow queues early (bad for short
      queues), and makes delay-based congestion control more difficult.
      
      Deferring by a couple clock ticks I believe will have a relatively small
      impact on performance.
      Signed-off-by: NJohn Heffner <jheffner@psc.edu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae8064ac
  11. 12 10月, 2006 1 次提交
  12. 29 9月, 2006 1 次提交
  13. 23 9月, 2006 2 次提交
  14. 23 8月, 2006 1 次提交
  15. 08 8月, 2006 1 次提交
  16. 01 7月, 2006 1 次提交
  17. 30 6月, 2006 1 次提交
    • M
      [NET]: Add ECN support for TSO · b0da8537
      Michael Chan 提交于
      In the current TSO implementation, NETIF_F_TSO and ECN cannot be
      turned on together in a TCP connection.  The problem is that most
      hardware that supports TSO does not handle CWR correctly if it is set
      in the TSO packet.  Correct handling requires CWR to be set in the
      first packet only if it is set in the TSO header.
      
      This patch adds the ability to turn on NETIF_F_TSO and ECN using
      GSO if necessary to handle TSO packets with CWR set.  Hardware
      that handles CWR correctly can turn on NETIF_F_TSO_ECN in the dev->
      features flag.
      
      All TSO packets with CWR set will have the SKB_GSO_TCPV4_ECN set.  If
      the output device does not have the NETIF_F_TSO_ECN feature set, GSO
      will split the packet up correctly with CWR only set in the first
      segment.
      
      With help from Herbert Xu <herbert@gondor.apana.org.au>.
      
      Since ECN can always be enabled with TSO, the SOCK_NO_LARGESEND sock
      flag is completely removed.
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b0da8537
  18. 23 6月, 2006 1 次提交
    • H
      [NET]: Merge TSO/UFO fields in sk_buff · 7967168c
      Herbert Xu 提交于
      Having separate fields in sk_buff for TSO/UFO (tso_size/ufo_size) is not
      going to scale if we add any more segmentation methods (e.g., DCCP).  So
      let's merge them.
      
      They were used to tell the protocol of a packet.  This function has been
      subsumed by the new gso_type field.  This is essentially a set of netdev
      feature bits (shifted by 16 bits) that are required to process a specific
      skb.  As such it's easy to tell whether a given device can process a GSO
      skb: you just have to and the gso_type field and the netdev's features
      field.
      
      I've made gso_type a conjunction.  The idea is that you have a base type
      (e.g., SKB_GSO_TCPV4) that can be modified further to support new features.
      For example, if we add a hardware TSO type that supports ECN, they would
      declare NETIF_F_TSO | NETIF_F_TSO_ECN.  All TSO packets with CWR set would
      have a gso_type of SKB_GSO_TCPV4 | SKB_GSO_TCPV4_ECN while all other TSO
      packets would be SKB_GSO_TCPV4.  This means that only the CWR packets need
      to be emulated in software.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7967168c
  19. 18 6月, 2006 1 次提交
  20. 06 6月, 2006 1 次提交
    • H
      [TCP]: Avoid skb_pull if possible when trimming head · f2911969
      Herbert Xu ~{PmVHI~} 提交于
      Trimming the head of an skb by calling skb_pull can cause the packet
      to become unaligned if the length pulled is odd.  Since the length is
      entirely arbitrary for a FIN packet carrying data, this is actually
      quite common.
      
      Unaligned data is not the end of the world, but we should avoid it if
      it's easily done.  In this case it is trivial.  Since we're discarding
      all of the head data it doesn't matter whether we move skb->data forward
      or back.
      
      However, it is still possible to have unaligned skb->data in general.
      So network drivers should be prepared to handle it instead of crashing.
      
      This patch also adds an unlikely marking on len < headlen since partial
      ACKs on head data are extremely rare in the wild.  As the return value
      of __pskb_trim_head is no longer ever NULL that has been removed.
      Signed-off-by: NHerbert Xu ~{PmV&gt;HI~} <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f2911969
  21. 30 4月, 2006 1 次提交
  22. 20 4月, 2006 1 次提交
  23. 19 4月, 2006 1 次提交
    • H
      [TCP]: Fix truesize underflow · ef5cb973
      Herbert Xu 提交于
      There is a problem with the TSO packet trimming code.  The cause of
      this lies in the tcp_fragment() function.
      
      When we allocate a fragment for a completely non-linear packet the
      truesize is calculated for a payload length of zero.  This means that
      truesize could in fact be less than the real payload length.
      
      When that happens the TSO packet trimming can cause truesize to become
      negative.  This in turn can cause sk_forward_alloc to be -n * PAGE_SIZE
      which would trigger the warning.
      
      I've copied the code DaveM used in tso_fragment which should work here.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ef5cb973
  24. 15 4月, 2006 1 次提交
    • A
      [IPV4]: Possible cleanups. · 6c97e72a
      Adrian Bunk 提交于
      This patch contains the following possible cleanups:
      - make the following needlessly global function static:
        - arp.c: arp_rcv()
      - remove the following unused EXPORT_SYMBOL's:
        - devinet.c: devinet_ioctl
        - fib_frontend.c: ip_rt_ioctl
        - inet_hashtables.c: inet_bind_bucket_create
        - inet_hashtables.c: inet_bind_hash
        - tcp_input.c: sysctl_tcp_abc
        - tcp_ipv4.c: sysctl_tcp_tw_reuse
        - tcp_output.c: sysctl_tcp_mtu_probing
        - tcp_output.c: sysctl_tcp_base_mss
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c97e72a
  25. 21 3月, 2006 3 次提交
  26. 12 3月, 2006 1 次提交
  27. 04 1月, 2006 3 次提交
  28. 07 12月, 2005 1 次提交
    • D
      [TCP] Vegas: timestamp before clone · dfb4b9dc
      David S. Miller 提交于
      We have to store the congestion control timestamp on the SKB before we
      clone it, not after.  Else we get no timestamping information at all.
      
      tcp_transmit_skb() has been reworked so that we can do the timestamp
      still in one spot, instead of at all the call sites.
      
      Problem discovered, and initial fix, from Tom Young
      <tyo@ee.unimelb.edu.au>.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dfb4b9dc
  29. 11 11月, 2005 3 次提交
  30. 21 10月, 2005 1 次提交