On 8/19/2013 10:12 PM, Jason Gunthorpe wrote:
On Sun, Aug 18, 2013 at 12:05:48PM +0300, Yishai Hadas wrote:
On 8/16/2013 06:11 PM, Sean Hefty wrote:
@@ -884,6 +884,13 @@ int main(int argc, char *argv[])
        if (ctx.use_event)
                ibv_ack_cq_events(ctx.recv_cq, num_cq_events);

+       /* Process should wait before closing its resources to make sure
+         * latest daemon's response sent via its target QP destined to an XSRQ
+         * created by another client won't be lost.
+         * Failure to do so will cause the client to wait for that sent message
forever.
+         * See comment on pp_post_send.
+       */
+       sleep(1);
I dislike adding sleep calls into code.  Isn't there a more robust way to 
handle this?
In general I agree this sleep is a workaround that comes to solve a
synchronization hole in this sample application.  For that reason I
put 5 lines comment to describe the problem and the reason for that
sleep statement.  Long term you could think of synchronizing all the
processes through the sockets mechanism to assure they terminate
when all packets are received.
This example is very close to the only code that people will have
access to when trying to work with XRC.
Latest perftest package also contains a use case of XRC.
No sleep.

Ido
It should be complete and correct under all cases. So no sleeps, IMHO.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to