1. 03 8月, 2006 1 次提交
    • W
      [TCP]: SNMPv2 tcpAttemptFails counter error · 3687b1dc
      Wei Yongjun 提交于
      Refer to RFC2012, tcpAttemptFails is defined as following:
        tcpAttemptFails OBJECT-TYPE
            SYNTAX      Counter32
            MAX-ACCESS  read-only
            STATUS      current
            DESCRIPTION
                    "The number of times TCP connections have made a direct
                    transition to the CLOSED state from either the SYN-SENT
                    state or the SYN-RCVD state, plus the number of times TCP
                    connections have made a direct transition to the LISTEN
                    state from the SYN-RCVD state."
            ::= { tcp 7 }
      
      When I lookup into RFC793, I found that the state change should occured
      under following condition:
        1. SYN-SENT -> CLOSED
           a) Received ACK,RST segment when SYN-SENT state.
      
        2. SYN-RCVD -> CLOSED
           b) Received SYN segment when SYN-RCVD state(came from LISTEN).
           c) Received RST segment when SYN-RCVD state(came from SYN-SENT).
           d) Received SYN segment when SYN-RCVD state(came from SYN-SENT).
      
        3. SYN-RCVD -> LISTEN
           e) Received RST segment when SYN-RCVD state(came from LISTEN).
      
      In my test, those direct state transition can not be counted to
      tcpAttemptFails.
      Signed-off-by: NWei Yongjun <yjwei@nanjing-fnst.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3687b1dc
  2. 04 7月, 2006 1 次提交
  3. 01 7月, 2006 1 次提交
  4. 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
  5. 04 1月, 2006 2 次提交
  6. 11 11月, 2005 2 次提交
  7. 21 9月, 2005 1 次提交
  8. 30 8月, 2005 15 次提交
  9. 24 6月, 2005 1 次提交
  10. 19 6月, 2005 3 次提交
    • A
      [NET] Generalise tcp_listen_opt · 0e87506f
      Arnaldo Carvalho de Melo 提交于
      This chunks out the accept_queue and tcp_listen_opt code and moves
      them to net/core/request_sock.c and include/net/request_sock.h, to
      make it useful for other transport protocols, DCCP being the first one
      to use it.
      
      Next patches will rename tcp_listen_opt to accept_sock and remove the
      inline tcp functions that just call a reqsk_queue_ function.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0e87506f
    • A
      [NET] Rename open_request to request_sock · 60236fdd
      Arnaldo Carvalho de Melo 提交于
      Ok, this one just renames some stuff to have a better namespace and to
      dissassociate it from TCP:
      
      struct open_request  -> struct request_sock
      tcp_openreq_alloc    -> reqsk_alloc
      tcp_openreq_free     -> reqsk_free
      tcp_openreq_fastfree -> __reqsk_free
      
      With this most of the infrastructure closely resembles a struct
      sock methods subset.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      60236fdd
    • A
      [NET] Generalise TCP's struct open_request minisock infrastructure · 2e6599cb
      Arnaldo Carvalho de Melo 提交于
      Kept this first changeset minimal, without changing existing names to
      ease peer review.
      
      Basicaly tcp_openreq_alloc now receives the or_calltable, that in turn
      has two new members:
      
      ->slab, that replaces tcp_openreq_cachep
      ->obj_size, to inform the size of the openreq descendant for
        a specific protocol
      
      The protocol specific fields in struct open_request were moved to a
      class hierarchy, with the things that are common to all connection
      oriented PF_INET protocols in struct inet_request_sock, the TCP ones
      in tcp_request_sock, that is an inet_request_sock, that is an
      open_request.
      
      I.e. this uses the same approach used for the struct sock class
      hierarchy, with sk_prot indicating if the protocol wants to use the
      open_request infrastructure by filling in sk_prot->rsk_prot with an
      or_calltable.
      
      Results? Performance is improved and TCP v4 now uses only 64 bytes per
      open request minisock, down from 96 without this patch :-)
      
      Next changeset will rename some of the structs, fields and functions
      mentioned above, struct or_calltable is way unclear, better name it
      struct request_sock_ops, s/struct open_request/struct request_sock/g,
      etc.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e6599cb
  11. 06 5月, 2005 1 次提交
  12. 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