Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 153
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 18 3月, 2011 2 次提交
  3. 16 3月, 2011 1 次提交
  5. 12 1月, 2011 2 次提交
    • J
      rpc: allow xprt_class->setup to return a preexisting xprt · f0418aa4
      由 J. Bruce Fields 提交于 
      This allows us to reuse the xprt associated with a server connection if
one has already been set up.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      f0418aa4
    • J
      rpc: keep backchannel xprt as long as server connection · 99de8ea9
      由 J. Bruce Fields 提交于 
      Multiple backchannels can share the same tcp connection; from rfc 5661 section
2.10.3.1:

	A connection's association with a session is not exclusive.  A
	connection associated with the channel(s) of one session may be
	simultaneously associated with the channel(s) of other sessions
	including sessions associated with other client IDs.

However, multiple backchannels share a connection, they must all share
the same xid stream (hence the same rpc_xprt); the only way we have to
match replies with calls at the rpc layer is using the xid.

So, keep the rpc_xprt around as long as the connection lasts, in case
we're asked to use the connection as a backchannel again.

Requests to create new backchannel clients over a given server
connection should results in creating new clients that reuse the
existing rpc_xprt.

But to start, just reject attempts to associate multiple rpc_xprt's with
the same underlying bc_xprt.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      99de8ea9
  7. 19 10月, 2010 2 次提交
  9. 02 10月, 2010 3 次提交
  11. 04 8月, 2010 2 次提交
  13. 25 5月, 2010 1 次提交
  15. 18 5月, 2010 1 次提交
  17. 15 5月, 2010 6 次提交
  19. 21 4月, 2010 1 次提交
  21. 22 3月, 2010 1 次提交
  23. 03 12月, 2009 1 次提交
  25. 12 9月, 2009 1 次提交
  27. 18 6月, 2009 4 次提交
  29. 03 5月, 2009 1 次提交
  31. 12 3月, 2009 4 次提交
  33. 08 10月, 2008 1 次提交
  35. 10 7月, 2008 2 次提交
    • C
      SUNRPC: Ensure all transports set rq_xtime consistently · b22602a6
      由 Chuck Lever 提交于 
      The RPC client uses the rq_xtime field in each RPC request to determine the
round-trip time of the request.  Currently, the rq_xtime field is
initialized by each transport just before it starts enqueing a request to
be sent.  However, transports do not handle initializing this value
consistently; sometimes they don't initialize it at all.

To make the measurement of request round-trip time consistent for all
RPC client transport capabilities, pull rq_xtime initialization into the
RPC client's generic transport logic.  Now all transports will get a
standardized RTT measure automatically, from:

  xprt_transmit()

to

  xprt_complete_rqst()

This makes round-trip time calculation more accurate for the TCP transport.
The socket ->sendmsg() method can return "-EAGAIN" if the socket's output
buffer is full, so the TCP transport's ->send_request() method may call
the ->sendmsg() method repeatedly until it gets all of the request's bytes
queued in the socket's buffer.

Currently, the TCP transport sets the rq_xtime field every time through
that loop so the final value is the timestamp just before the *last* call
to the underlying socket's ->sendmsg() method.  After this patch, the
rq_xtime field contains a timestamp that reflects the time just before the
*first* call to ->sendmsg().

This is consequential under heavy workloads because large requests often
take multiple ->sendmsg() calls to get all the bytes of a request queued.
The TCP transport causes the request to sleep until the remote end of the
socket has received enough bytes to clear space in the socket's local
output buffer.  This delay can be quite significant.

The method introduced by this patch is a more accurate measure of RTT
for stream transports, since the server can cause enough back pressure
to delay (ie increase the latency of) requests from the client.

Additionally, this patch corrects the behavior of the RDMA transport, which
entirely neglected to initialize the rq_xtime field.  RPC performance
metrics for RDMA transports now display correct RPC request round trip
times.
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Acked-by: NTom Talpey <thomas.talpey@netapp.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      b22602a6
    • C
      SUNRPC: Remove obsolete messages during transport connect · cd983ef8
      由 Chuck Lever 提交于 
      Recent changes to the RPC client's transport connect logic make connect
status values ECONNREFUSED and ECONNRESET impossible.

Clean up xprt_connect_status() to account for these changes.
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      cd983ef8
  37. 28 4月, 2008 1 次提交
  39. 20 4月, 2008 3 次提交