1. 18 Feb, 2008 1 commit
  2. 03 Feb, 2008 1 commit
    • Arnaldo Carvalho de Melo's avatar
      [SOCK] proto: Add hashinfo member to struct proto · ab1e0a13
      Arnaldo Carvalho de Melo authored
      This way we can remove TCP and DCCP specific versions of
      sk->sk_prot->get_port: both v4 and v6 use inet_csk_get_port
      sk->sk_prot->hash:     inet_hash is directly used, only v6 need
                             a specific version to deal with mapped sockets
      sk->sk_prot->unhash:   both v4 and v6 use inet_hash directly
      struct inet_connection_sock_af_ops also gets a new member, bind_conflict, so
      that inet_csk_get_port can find the per family routine.
      Now only the lookup routines receive as a parameter a struct inet_hashtable.
      With this we further reuse code, reducing the difference among INET transport
      Eventually work has to be done on UDP and SCTP to make them share this
      infrastructure and get as a bonus inet_diag interfaces so that iproute can be
      used with these protocols.
        struct proto			     |   +8
        struct inet_connection_sock_af_ops |   +8
       2 structs changed
        __inet_hash_nolisten               |  +18
        __inet_hash                        | -210
        inet_put_port                      |   +8
        inet_bind_bucket_create            |   +1
        __inet_hash_connect                |   -8
       5 functions changed, 27 bytes added, 218 bytes removed, diff: -191
        proto_seq_show                     |   +3
       1 function changed, 3 bytes added, diff: +3
        inet_csk_get_port                  |  +15
       1 function changed, 15 bytes added, diff: +15
        tcp_set_state                      |   -7
       1 function changed, 7 bytes removed, diff: -7
        tcp_v4_get_port                    |  -31
        tcp_v4_hash                        |  -48
        tcp_v4_destroy_sock                |   -7
        tcp_v4_syn_recv_sock               |   -2
        tcp_unhash                         | -179
       5 functions changed, 267 bytes removed, diff: -267
        __inet6_hash |   +8
       1 function changed, 8 bytes added, diff: +8
        inet_unhash                        | +190
        inet_hash                          | +242
       2 functions changed, 432 bytes added, diff: +432
       16 functions changed, 485 bytes added, 492 bytes removed, diff: -7
        tcp_v6_get_port                    |  -31
        tcp_v6_hash                        |   -7
        tcp_v6_syn_recv_sock               |   -9
       3 functions changed, 47 bytes removed, diff: -47
        dccp_destroy_sock                  |   -7
        dccp_unhash                        | -179
        dccp_hash                          |  -49
        dccp_set_state                     |   -7
        dccp_done                          |   +1
       5 functions changed, 1 bytes added, 242 bytes removed, diff: -241
        dccp_v4_get_port                   |  -31
        dccp_v4_request_recv_sock          |   -2
       2 functions changed, 33 bytes removed, diff: -33
        dccp_v6_get_port                   |  -31
        dccp_v6_hash                       |   -7
        dccp_v6_request_recv_sock          |   +5
       3 functions changed, 5 bytes added, 38 bytes removed, diff: -33
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  3. 31 Jan, 2008 1 commit
  4. 28 Jan, 2008 13 commits
  5. 09 Jan, 2008 1 commit
  6. 18 Nov, 2007 1 commit
    • Herbert Xu's avatar
      [TCP]: Fix TCP header misalignment · 21df56c6
      Herbert Xu authored
      Indeed my previous change to alloc_pskb has made it possible
      for the TCP header to be misaligned iff the MTU is not a multiple
      of 4 (and less than a page).  So I suspect the optimised IPsec
      MTU calculation is giving you just such an MTU :)
      This patch fixes it by changing alloc_pskb to make sure that
      the size is at least 32-bit aligned.  This does not cause the
      problem fixed by the previous patch because max_header is always
      32-bit aligned which means that in the SG/NOTSO case this will
      be a no-op.
      I thought about putting this in the callers but all the current
      callers are from TCP.  If and when we get a non-TCP caller we
      can always create a TCP wrapper for this function and move the
      alignment over there.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  7. 14 Nov, 2007 1 commit
    • Herbert Xu's avatar
      [TCP]: Fix size calculation in sk_stream_alloc_pskb · fb93134d
      Herbert Xu authored
      We round up the header size in sk_stream_alloc_pskb so that
      TSO packets get zero tail room.  Unfortunately this rounding
      up is not coordinated with the select_size() function used by
      TCP to calculate the second parameter of sk_stream_alloc_pskb.
      As a result, we may allocate more than a page of data in the
      non-TSO case when exactly one page is desired.
      In fact, rounding up the head room is detrimental in the non-TSO
      case because it makes memory that would otherwise be available to
      the payload head room.  TSO doesn't need this either, all it wants
      is the guarantee that there is no tail room.
      So this patch fixes this by adjusting the skb_reserve call so that
      exactly the requested amount (which all callers have calculated in
      a precise way) is made available as tail room.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  8. 07 Nov, 2007 1 commit
    • Eric Dumazet's avatar
      [NET]: Define infrastructure to keep 'inuse' changes in an efficent SMP/NUMA way. · 286ab3d4
      Eric Dumazet authored
      "struct proto" currently uses an array stats[NR_CPUS] to track change on
      'inuse' sockets per protocol.
      If NR_CPUS is big, this means we use a big memory area for this.
      Moreover, all this memory area is located on a single node on NUMA
      machines, increasing memory pressure on the boot node.
      In this patch, I tried to :
      - Keep a fast !CONFIG_SMP implementation
      - Keep a fast CONFIG_SMP implementation for often used protocols
      - Introduce a NUMA efficient implementation
      Some helper macros are defined in include/net/sock.h
      These macros take into account CONFIG_SMP
      If a "struct proto" is declared without using DEFINE_PROTO_INUSE /
      macros, it will automatically use a default implementation, using a
      dynamically allocated percpu zone.
      This default implementation will be NUMA efficient, but might use 32/64
      bytes per possible cpu
      because of current alloc_percpu() implementation.
      However it still should be better than previous implementation based on
      stats[NR_CPUS] field.
      When a "struct proto" is changed to use the new macros, we use a single
      static "int" percpu variable,
      lowering the memory and cpu costs, still preserving NUMA efficiency.
      Signed-off-by: default avatarEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  9. 01 Nov, 2007 2 commits
  10. 17 Oct, 2007 2 commits
  11. 10 Oct, 2007 5 commits
  12. 31 May, 2007 1 commit
  13. 08 May, 2007 1 commit
  14. 25 Apr, 2007 7 commits
  15. 06 Mar, 2007 1 commit
  16. 02 Mar, 2007 1 commit
    • Wei Dong's avatar
      [NET]: Fix bugs in "Whether sock accept queue is full" checking · 8488df89
      Wei Dong authored
      	when I use linux TCP socket, and find there is a bug in function
      	When a new SYN comes, TCP module first checks its validation. If valid,
      send SYN,ACK to the client and add the sock to the syn hash table. Next
      time if received the valid ACK for SYN,ACK from the client. server will
      accept this connection and increase the sk->sk_ack_backlog -- which is
      done in function tcp_check_req().We check wether acceptq is full in
      function tcp_v4_syn_recv_sock().
      Consider an example:
       After listen(sockfd, 1) system call, sk->sk_max_ack_backlog is set to
      1. As we know, sk->sk_ack_backlog is initialized to 0. Assuming accept()
      system call is not invoked now.
      1. 1st connection comes. invoke sk_acceptq_is_full(). sk-
      >sk_ack_backlog=0 sk->sk_max_ack_backlog=1, function return 0 accept
      this connection. Increase the sk->sk_ack_backlog
      2. 2nd connection comes. invoke sk_acceptq_is_full(). sk-
      >sk_ack_backlog=1 sk->sk_max_ack_backlog=1, function return 0 accept
      this connection. Increase the sk->sk_ack_backlog
      3. 3rd connection comes. invoke sk_acceptq_is_full(). sk-
      >sk_ack_backlog=2 sk->sk_max_ack_backlog=1, function return 1. Refuse
      this connection.
      I think it has bugs. after listen system call. sk->sk_max_ack_backlog=1
      but now it can accept 2 connections.
      Signed-off-by: default avatarWei Dong <weid@np.css.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>