Thanks for the feedback Or, comments below. On Sun, 23 Nov 2008 11:23:37 +0200 Or Gerlitz <[EMAIL PROTECTED]> 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 _______________________________________________ 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
