David Disseldorp wrote:
iSCSI/iSER targets may send PDUs without a prior request from the initiator, RFC 5046 refers to these PDUs as
"unexpected". NOP-In PDUs with itt=RESERVED and Asynchronous Message PDUs occupy this category.
Currently when an iSER target sends an "unexpected" PDU, the initiators recv buffer consumed by the
PDU is not replaced. If over initial_post_recv_bufs_num "unexpected" PDUs are received then the
receive queue will run out of receive work requests.
Assuming these target initiated NOP-Ins are echoed back by the
initiator, the current code of iser_send_control would post a receive
buffer when sending the NOP-Out which will account for the buffer
consumed by the NOP-In. So we are remained with the Asynchronous PDUs
for which your patch indeed seems to fix a hole in the implementation.
This patch ensures recv buffers consumed by "unexpected" PDUs are replaced
prior to sending the next control-type PDU.
The practice used by the patch is account unexpected receives and refill
the receive buffer queue when ever possible with as many as unexpected
receives that took place since the last refill attempt. To ease with
future maintainance and debugging / simplicity of the code, I would
prefer a patch with zero foot-print at the iser_send_xxx functions,
something like account --async-- receives and when calling
iser_post_receive_control fill-in the missing buffers.
@@ -586,6 +635,21 @@ void iser_rcv_completion(struct iser_desc *rx_desc,
* parallel to the execution of iser_conn_term. So the code that waits *
* for the posted rx bufs refcount to become zero handles everything
*/
atomic_dec(&conn->ib_conn->post_recv_buf_count);
+
+ /*
+ * if an unexpected PDU was received then the recv wr consumed must
+ * be replaced, this is done in the next send of a control-type PDU
+ */
+ if ((opcode == ISCSI_OP_NOOP_IN)
+ && (hdr->itt == RESERVED_ITT)) {
+ /* nop-in with itt = 0xffffffff */
+ atomic_inc(&conn->ib_conn->unexpected_pdu_count);
+ }
As I wrote above, this seems to be unneeded
Or.
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
