Lines Matching refs:and
7 between client and server machines using RDMA (InfiniBand, RoCE, iWarp)
15 RTRS provides I/O fail-over and load-balancing capabilities by using
16 multipath I/O (see "add_path" and "mp_policy" configuration entries in
27 An established connection between a client and a server is called rtrs
31 between client and server. Those are used for load balancing and failover.
36 chunks reserved for him on the server side. Their number, size and addresses
37 need to be exchanged between client and server during the connection
39 inform the server about the session name and identify each path and connection
44 acknowledged and for errno. Client uses immediate field to tell the server
45 which of the memory chunks has been accessed and at which offset the message
50 invalidate each rdma buffer before we hand it over to RNBD server and
51 then pass it to the block layer. A new rkey is generated and registered for the
52 buffer after it returns back from the block layer and RNBD server.
54 The procedure is the default behaviour of the driver. This invalidation and
57 (always_invalidate=N), if he understands and can take the risk of a malicious
59 be a reasonable option in a scenario where all the clients and all the servers
68 Those include uuid of the session and uuid of the path to be
71 version and magic for compatibility, total number of connections per session
72 (as many as cpus on the client), the id of the current connection and
77 2. Server accepts the connection requests one by one and attaches
78 RTRS_MSG_CONN_RSP messages to the rdma_accept. Apart from magic and
81 session) and the maximum size of one io, RTRS_MSG_NEW_RKEY_F flags is set
89 which contains the addresses and keys of the RDMA buffers allocated for that
95 6. Server and client exchange periodically heartbeat messages (empty rdma
101 healthy path, if any, and the reconnect mechanism is triggered.
104 *for each connection belonging to a path and for each path:
123 on the server side and rdma writes there the user data, user header and the
126 been accessed and at what offset the RTRS_MSG_RDMA_WRITE can be found by
131 inflight IO and for the error code.
140 on the server side and rdma writes there the user data, user header and the
143 been accessed and at what offset the RTRS_MSG_RDMA_WRITE can be found by
149 inflight IO and for the error code. The new rkey is sent back using
151 the message and finished IO after update rkey for the rbuffer, then post
163 on the server side and rdma writes there the user header and the
165 the user header, flags (specifying if memory invalidation is necessary) and the
169 attaches an invalidation message if requested and finally an "empty" rdma
171 outstanding inflight IO and the error code.
182 on the server side and rdma writes there the user header and the
184 the user header, flags (specifying if memory invalidation is necessary) and the
190 attaches an invalidation message if requested and finally an "empty" rdma
192 outstanding inflight IO and the error code. The new rkey is sent back using
194 the message and finished IO after update rkey for the rbuffer, then post