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

David Disseldorp ddiss at sgi.com
Tue Nov 25 21:12:13 PST 2008


Thanks for the feedback Or, comments below.

On Sun, 23 Nov 2008 11:23:37 +0200
Or Gerlitz <ogerlitz at voltaire.com> wrote:

> 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.

Yes, target initiated "ping" NOP-Ins with a valid TTT do not currently
result in receive buffer depletion, however targets may use a NOP-In PDU
with both ITT and TTT set to RESERVED for the sole purpose of advertising
the command window counters (ExpCmdSN and MaxCmdSN). These PDUs do not
require a NOP-Out PDU from the initiator.

Likewise the Initiator may send a NOP-Out with both ITT and TTT set to
RESERVED, in this case a recv buf for a target response should not be
posted.

> >
> > 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.

No problems, i'll rework the patch to post "unexpected" buffers along
with the response buffer in iser_post_receive_control().

Cheers, Dave



More information about the general mailing list