> Quoting Pradeep Satyanarayana <[EMAIL PROTECTED]>: > Subject: Re: [openib-general] IPoIB CM for merge? > > > Hello Michael, > > Here are a few more observations :
Pradeep, I think you are posting in the wrong thread: it seems you are not talking about my code, but rather about the project you mentioned of implementing IPoIB CM without SRQ. IPoIB CM currently falls back on UD mode for HCAs that do not support SRQ, so there should be no problem for the ehca - as new code won't be activated. As I said already, I do not see a clean way to address this limitation, so I would rather have current IPoIB CM code merged upstream first, and think about enhancements later. > > 1. For the SRQ case, the skbs and recieve biffers are posted during init and > even before the rx_qp is created. This causes a problem (atleast for non > SRQs) for the ehca. We need to call the ipoib_cm_alloc_skb() and > ipoib_cm_post_recieve() after the rx_qp > is in the RTR state. > > 2. Also found that in ipoib_cm_create_rx_qp() one needs to initialize > .cap.max_recv_wr and .cap.max_recv_sge. Otherwise this leads to some problems > like rq overflows and causing communication failures. Yes, I think these are some of the things that would need to be done to make IPoIB CM work without SRQ. It is clearly not something we want to do for SRQ case however: for example, posting WRs to SRQ during connection setup would race against completion events for other connections. And assigning .cap.max_recv_wr > 0 for a QP not connected to SRQ does not make sense, and might thinkably confuse low level drivers. -- MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
