1. 11 Jan, 2011 1 commit
  2. 17 Dec, 2010 1 commit
  3. 25 Oct, 2010 1 commit
  4. 19 Oct, 2010 1 commit
  5. 01 Oct, 2010 2 commits
  6. 18 May, 2010 1 commit
  7. 03 May, 2010 1 commit
    • Neil Brown's avatar
      sunrpc: centralise most calls to svc_xprt_received · b48fa6b9
      Neil Brown authored
      svc_xprt_received must be called when ->xpo_recvfrom has finished
      receiving a message, so that the XPT_BUSY flag will be cleared and
      if necessary, requeued for further work.
      This call is currently made in each ->xpo_recvfrom function, often
      from multiple different points.  In each case it is the earliest point
      on a particular path where it is known that the protection provided by
      XPT_BUSY is no longer needed.
      However there are (still) some error paths which do not call
      svc_xprt_received, and requiring each ->xpo_recvfrom to make the call
      does not encourage robustness.
      So: move the svc_xprt_received call to be made just after the
      call to ->xpo_recvfrom(), and move it of the various ->xpo_recvfrom
      This means that it may not be called at the earliest possible instant,
      but this is unlikely to be a measurable performance issue.
      Note that there are still other calls to svc_xprt_received as it is
      also needed when an xprt is newly created.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
  8. 20 Apr, 2010 1 commit
  9. 28 Feb, 2010 1 commit
    • Neil Brown's avatar
      nfsd: ensure sockets are closed on error · 301e99ce
      Neil Brown authored
      One the changes in commit d7979ae4 "svc: Move close processing to a
      single place" is:
      -       svc_delete_socket(svsk);
      +       set_bit(SK_CLOSE, &svsk->sk_flags);
              return -EAGAIN;
      This is insufficient. The recvfrom methods must always call
      svc_xprt_received on completion so that the socket gets re-queued if
      there is any more work to do.  This particular path did not make that
      call because it actually destroyed the svsk, making requeue pointless.
      When the svc_delete_socket was change to just set a bit, we should have
      added a call to svc_xprt_received,
      This is the problem that b0401d72
       attempted to fix, incorrectly.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
  10. 26 Jan, 2010 1 commit
  11. 30 Oct, 2009 1 commit
  12. 18 Oct, 2009 1 commit
    • Eric Dumazet's avatar
      inet: rename some inet_sock fields · c720c7e8
      Eric Dumazet authored
      In order to have better cache layouts of struct sock (separate zones
      for rx/tx paths), we need this preliminary patch.
      Goal is to transfert fields used at lookup time in the first
      read-mostly cache line (inside struct sock_common) and move sk_refcnt
      to a separate cache line (only written by rx path)
      This patch adds inet_ prefix to daddr, rcv_saddr, dport, num, saddr,
      sport and id fields. This allows a future patch to define these
      fields as macros, like sk_refcnt, without name clashes.
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  13. 11 Sep, 2009 1 commit
  14. 24 Aug, 2009 1 commit
  15. 14 Jul, 2009 1 commit
  16. 18 Jun, 2009 1 commit
    • Trond Myklebust's avatar
      SUNRPC: Fix the TCP server's send buffer accounting · 47fcb03f
      Trond Myklebust authored
      Currently, the sunrpc server is refusing to allow us to process new RPC
      calls if the TCP send buffer is 2/3 full, even if we do actually have
      enough free space to guarantee that we can send another request.
      The following patch fixes svc_tcp_has_wspace() so that we only stop
      processing requests if we know that the socket buffer cannot possibly fit
      another reply.
      It also fixes the tcp write_space() callback so that we only clear the
      SOCK_NOSPACE flag when the TCP send buffer is less than 2/3 full.
      This should ensure that the send window will grow as per the standard TCP
      socket code.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
  17. 17 Jun, 2009 1 commit
  18. 27 May, 2009 1 commit
  19. 28 Apr, 2009 6 commits
  20. 01 Apr, 2009 1 commit
  21. 28 Mar, 2009 3 commits
  22. 18 Mar, 2009 1 commit
    • Olga Kornievskaia's avatar
      svcrpc: take advantage of tcp autotuning · 47a14ef1
      Olga Kornievskaia authored
      Allow the NFSv4 server to make use of TCP autotuning behaviour, which
      was previously disabled by setting the sk_userlocks variable.
      Set the receive buffers to be big enough to receive the whole RPC
      request, and set this for the listening socket, not the accept socket.
      Remove the code that readjusts the receive/send buffer sizes for the
      accepted socket. Previously this code was used to influence the TCP
      window management behaviour, which is no longer needed when autotuning
      is enabled.
      This can improve IO bandwidth on networks with high bandwidth-delay
      products, where a large tcp window is required.  It also simplifies
      performance tuning, since getting adequate tcp buffers previously
      required increasing the number of nfsd threads.
      Signed-off-by: default avatarOlga Kornievskaia <aglo@citi.umich.edu>
      Cc: Jim Rees <rees@umich.edu>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
  23. 07 Jan, 2009 2 commits
  24. 06 Jan, 2009 1 commit
  25. 24 Nov, 2008 1 commit
  26. 31 Oct, 2008 1 commit
  27. 04 Oct, 2008 1 commit
  28. 29 Sep, 2008 1 commit
    • Chuck Lever's avatar
      SUNRPC: Set V6ONLY socket option for RPC listener sockets · b6632339
      Chuck Lever authored
      My plan is to use an AF_INET listener on systems that support only IPv4,
      and an AF_INET6 listener on systems that can support IPv6. Incoming
      IPv4 packets will be posted to an AF_INET6 listener with a mapped IPv4
      Max Matveev <makc@sgi.com> says:
        Creating a single listener can be dangerous - if net.ipv6.bindv6only
        is enabled then it's possible to create another listener in v4
        namespace on the same port and steal the traffic from the "unifed"
        listener. You need to disable V6ONLY explicitly via a sockopt to stop
      Set appropriate socket option on RPC server listener sockets to prevent
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
  29. 23 Apr, 2008 3 commits