[ofa-general] [PATCH] iser: avoid recv buf exhaustion

[Or Gerlitz]

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.