Re: RDMA_CM_EVENT_REJECTED and ressources release

Yann Droneaud
2012-06-21T06:11:47Z

Le mercredi 20 juin 2012 à 21:27 -0400, Veerendra Allada a écrit :
> Is it possible to delay the memory registrations (ibv_reg_mr) and the
> ibv_post_recv()'s until the connection is established ? Based on what
> i understood, i am suggesting the following sequence of calls on
> Client and Server. See if it helps.
>
> Client
> rdma_create_event_channel()
> rdma_create_id()
> rdma_resolve_addr()
> ibv_alloc_pd()
> ibv_create_comp_channel()
> ibv_create_cq()
> rdma_create_qp()
> rdma_resolve_route()
> rdma_connect()
>
> If the connection is not successful, call the corresponding destroy
> calls in the the reverse order.
> If the connection is successful, register memory and post the receive
> calls.
>
> Server
> rdma_create_event_channel()
> rdma_create_id()
> rdma_bind_addr()
> rdma_listen()
>
> Up on a new incoming connection request, do the following sequence.
>
> ibv_alloc_pd()
> ibv_create_comp_channel()
> ibv_create_cq()
> rdma_create_qp()
> rdma_accept()
>
> After the connection is successful, register memory and then post
> receive requests.
> At this point you should be able to post ibv_post_send requests and
> poll your completion queue's, etc.
>

Thanks for your answer, but it's not applicable on my case:

I have to post receive works before doing rdma_accept()/rdma_connect()
so that both side are ready to receive messages sent by other peer.

Not doing so will lead to races, RNR errors will be triggered on the
sending side if it's faster than the receiving side.

If the protocol implemented above the RDMA connection is
request/response based and initiated by the client, the client could
follow your proposed scheme, but on the server side, it will have to
post receive works before calling rdma_accept().

Regards.

--
Yann Droneaud
OPTEYA

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