1. 31 8月, 2010 1 次提交
    • J
      tcp: Add TCP_USER_TIMEOUT socket option. · dca43c75
      Jerry Chu 提交于
      This patch provides a "user timeout" support as described in RFC793. The
      socket option is also needed for the the local half of RFC5482 "TCP User
      Timeout Option".
      
      TCP_USER_TIMEOUT is a TCP level socket option that takes an unsigned int,
      when > 0, to specify the maximum amount of time in ms that transmitted
      data may remain unacknowledged before TCP will forcefully close the
      corresponding connection and return ETIMEDOUT to the application. If
      0 is given, TCP will continue to use the system default.
      
      Increasing the user timeouts allows a TCP connection to survive extended
      periods without end-to-end connectivity. Decreasing the user timeouts
      allows applications to "fail fast" if so desired. Otherwise it may take
      upto 20 minutes with the current system defaults in a normal WAN
      environment.
      
      The socket option can be made during any state of a TCP connection, but
      is only effective during the synchronized states of a connection
      (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK).
      Moreover, when used with the TCP keepalive (SO_KEEPALIVE) option,
      TCP_USER_TIMEOUT will overtake keepalive to determine when to close a
      connection due to keepalive failure.
      
      The option does not change in anyway when TCP retransmits a packet, nor
      when a keepalive probe will be sent.
      
      This option, like many others, will be inherited by an acceptor from its
      listener.
      Signed-off-by: NH.K. Jerry Chu <hkchu@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dca43c75
  2. 25 8月, 2010 1 次提交
  3. 23 8月, 2010 2 次提交
    • D
      net: Rename skb_has_frags to skb_has_frag_list · 21dc3301
      David S. Miller 提交于
      SKBs can be "fragmented" in two ways, via a page array (called
      skb_shinfo(skb)->frags[]) and via a list of SKBs (called
      skb_shinfo(skb)->frag_list).
      
      Since skb_has_frags() tests the latter, it's name is confusing
      since it sounds more like it's testing the former.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      21dc3301
    • H
      tcp: allow effective reduction of TCP's rcv-buffer via setsockopt · e88c64f0
      Hagen Paul Pfeifer 提交于
      Via setsockopt it is possible to reduce the socket RX buffer
      (SO_RCVBUF). TCP method to select the initial window and window scaling
      option in tcp_select_initial_window() currently misbehaves and do not
      consider a reduced RX socket buffer via setsockopt.
      
      Even though the server's RX buffer is reduced via setsockopt() to 256
      byte (Initial Window 384 byte => 256 * 2 - (256 * 2 / 4)) the window
      scale option is still 7:
      
      192.168.1.38.40676 > 78.47.222.210.5001: Flags [S], seq 2577214362, win 5840, options [mss 1460,sackOK,TS val 338417 ecr 0,nop,wscale 0], length 0
      78.47.222.210.5001 > 192.168.1.38.40676: Flags [S.], seq 1570631029, ack 2577214363, win 384, options [mss 1452,sackOK,TS val 2435248895 ecr 338417,nop,wscale 7], length 0
      192.168.1.38.40676 > 78.47.222.210.5001: Flags [.], ack 1, win 5840, options [nop,nop,TS val 338421 ecr 2435248895], length 0
      
      Within tcp_select_initial_window() the original space argument - a
      representation of the rx buffer size - is expanded during
      tcp_select_initial_window(). Only sysctl_tcp_rmem[2], sysctl_rmem_max
      and window_clamp are considered to calculate the initial window.
      
      This patch adjust the window_clamp argument if the user explicitly
      reduce the receive buffer.
      Signed-off-by: NHagen Paul Pfeifer <hagen@jauu.net>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e88c64f0
  4. 22 8月, 2010 1 次提交
    • D
      PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol) · 00959ade
      Dmitry Kozlov 提交于
      PPP: introduce "pptp" module which implements point-to-point tunneling protocol using pppox framework
      NET: introduce the "gre" module for demultiplexing GRE packets on version criteria
           (required to pptp and ip_gre may coexists)
      NET: ip_gre: update to use the "gre" module
      
      This patch introduces then pptp support to the linux kernel which
      dramatically speeds up pptp vpn connections and decreases cpu usage in
      comparison of existing user-space implementation
      (poptop/pptpclient). There is accel-pptp project
      (https://sourceforge.net/projects/accel-pptp/) to utilize this module,
      it contains plugin for pppd to use pptp in client-mode and modified
      pptpd (poptop) to build high-performance pptp NAS.
      
      There was many changes from initial submitted patch, most important are:
      1. using rcu instead of read-write locks
      2. using static bitmap instead of dynamically allocated
      3. using vmalloc for memory allocation instead of BITS_PER_LONG + __get_free_pages
      4. fixed many coding style issues
      Thanks to Eric Dumazet.
      Signed-off-by: NDmitry Kozlov <xeb@mail.ru>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      00959ade
  5. 20 8月, 2010 2 次提交
  6. 19 8月, 2010 1 次提交
  7. 18 8月, 2010 1 次提交
  8. 08 8月, 2010 1 次提交
  9. 03 8月, 2010 2 次提交
  10. 02 8月, 2010 4 次提交
  11. 31 7月, 2010 1 次提交
  12. 23 7月, 2010 4 次提交
  13. 22 7月, 2010 1 次提交
  14. 20 7月, 2010 1 次提交
  15. 16 7月, 2010 1 次提交
  16. 15 7月, 2010 1 次提交
  17. 13 7月, 2010 2 次提交
  18. 09 7月, 2010 1 次提交
    • S
      gre: propagate ipv6 transport class · dd4ba83d
      Stephen Hemminger 提交于
      This patch makes IPV6 over IPv4 GRE tunnel propagate the transport
      class field from the underlying IPV6 header to the IPV4 Type Of Service
      field. Without the patch, all IPV6 packets in tunnel look the same to QoS.
      
      This assumes that IPV6 transport class is exactly the same
      as IPv4 TOS. Not sure if that is always the case?  Maybe need
      to mask off some bits.
      
      The mask and shift to get tclass is copied from ipv6/datagram.c
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dd4ba83d
  19. 08 7月, 2010 1 次提交
  20. 06 7月, 2010 1 次提交
  21. 05 7月, 2010 3 次提交
  22. 01 7月, 2010 2 次提交
    • C
      fragment: add fast path for in-order fragments · d6bebca9
      Changli Gao 提交于
      add fast path for in-order fragments
      
      As the fragments are sent in order in most of OSes, such as Windows, Darwin and
      FreeBSD, it is likely the new fragments are at the end of the inet_frag_queue.
      In the fast path, we check if the skb at the end of the inet_frag_queue is the
      prev we expect.
      Signed-off-by: NChangli Gao <xiaosuo@gmail.com>
      ----
       include/net/inet_frag.h |    1 +
       net/ipv4/ip_fragment.c  |   12 ++++++++++++
       net/ipv6/reassembly.c   |   11 +++++++++++
       3 files changed, 24 insertions(+)
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d6bebca9
    • E
      snmp: 64bit ipstats_mib for all arches · 4ce3c183
      Eric Dumazet 提交于
      /proc/net/snmp and /proc/net/netstat expose SNMP counters.
      
      Width of these counters is either 32 or 64 bits, depending on the size
      of "unsigned long" in kernel.
      
      This means user program parsing these files must already be prepared to
      deal with 64bit values, regardless of user program being 32 or 64 bit.
      
      This patch introduces 64bit snmp values for IPSTAT mib, where some
      counters can wrap pretty fast if they are 32bit wide.
      
      # netstat -s|egrep "InOctets|OutOctets"
          InOctets: 244068329096
          OutOctets: 244069348848
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4ce3c183
  23. 29 6月, 2010 2 次提交
  24. 28 6月, 2010 2 次提交
  25. 27 6月, 2010 1 次提交