<br><font size=2 face="sans-serif">Steve, thanks for your advice.</font>
<br>
<br><font size=2 face="sans-serif">Is it possible that there is a bug in
OFED 1.3 with regard to non-signaled send work requests?</font>
<br><font size=2 face="sans-serif">I noticed that when I post send work
requests onto my send queue, It eventually fills up until I</font>
<br><font size=2 face="sans-serif">cannot post sends anymore.</font>
<br><font size=2 face="sans-serif">This happens with the Chelsio T3 RNIC
and OFED 1.3 whenever I post send WR's that have</font>
<br><font size=2 face="sans-serif">their flags set to 0. It does not happen
though when I post sends with IBV_SEND_SIGNALED.</font>
<br><font size=2 face="sans-serif">The CQ is empty in the case of non-signaled
WR's (as expected) but they somehow seem to</font>
<br><font size=2 face="sans-serif">be stuck on the send queue.</font>
<br>
<br><font size=2 face="sans-serif">I use the following code:</font>
<br><tt><font size=2>static struct ibv_send_wr tx_wr, *bad_wr;</font></tt>
<br>
<br><tt><font size=2>/* create send work request */</font></tt>
<br><tt><font size=2>tx_wr.wr_id = tx_wr_id++;</font></tt>
<br><tt><font size=2>tx_wr.next = NULL;</font></tt>
<br><tt><font size=2>tx_wr.sg_list = sg_list;</font></tt>
<br><tt><font size=2>tx_wr.num_sge = num_sge;</font></tt>
<br><tt><font size=2>tx_wr.opcode = IBV_WR_SEND;</font></tt>
<br><tt><font size=2>tx_wr.send_flags = 0;</font></tt>
<br><tt><font size=2>        </font></tt>
<br><tt><font size=2>/* post send work request */</font></tt>
<br><tt><font size=2>ret = ibv_post_send(qp, &tx_wr, &bad_wr);</font></tt>
<br><tt><font size=2>if (ret) {</font></tt>
<br><tt><font size=2>        //error</font></tt>
<br><tt><font size=2>}</font></tt>
<br>
<br><font size=2 face="sans-serif">I learned that it might be necessary
to post a signaled send WR after posting a number of non-signaled</font>
<br><font size=2 face="sans-serif">ones in order to clean up the SQ. Is
that the case and is there no way to post non-signaled WR's that</font>
<br><font size=2 face="sans-serif">do not get stuck on the SQ?</font>
<br>
<br><font size=2 face="sans-serif">Cheers,<br>
 Philip</font>
<br>
<br><tt><font size=2>general-bounces@lists.openfabrics.org wrote on 09.06.2008
18:28:08:<br>
<br>
> Philip Frey1 wrote: </font></tt>
<br><tt><font size=2>> <br>
> You are right. Thanks! <br>
> <br>
> I have yet another issue:<br>
> <br>
> Sometimes I get the following message in /var/log/messages of the
local host:<br>
> <br>
> post_qp_event - AE qpid 0x4e0 opcode 3 status 0x13 type 0 wrid.hi
<br>
> 0x0 wrid.lo 0x65000000 <br>
> <br>
> I was looking for the status and opcode in the source and found that
<br>
> opcode 3 means T3_SEND and status 0x13 means TPT_ERR_OUT_OF_RQE. <br>
> At the remote host I get and opcode 7 (T3_TERMINATE) and status 0x0
(SUCCESS).<br>
> <br>
> Clearly there is someone running out of Receive Queue Elements. The
<br>
> error occurred when <br>
> doing an ibv_post_send() at the local host. Is this a coincidence
or<br>
> does the local host <br>
> somehow know that there are not enough RQE's available at the remote<br>
> host? In other words, <br>
> does the TPT_ERR_OUT_OF_RQE refer to the local or to the remote receive
queue?<br>
</font></tt>
<br><tt><font size=2>> <br>
> You have to consider the type too. type 0 indicates ingress errors,
<br>
> and type 1 indicates egress.<br>
> <br>
> So the host that logged opcode 3, status 0x13, type 0 received an
<br>
> incoming SEND but there were no RECV's posted at that time.  The
<br>
> result is a connection termination, which results in the TERMINATE
<br>
> event on the peer side.<br>
> <br>
> Steve._______________________________________________<br>
> general mailing list<br>
> general@lists.openfabrics.org<br>
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general<br>
> <br>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general</font></tt>