On 11/12/13 9:37 AM, Mike Christie wrote:
if (max_cmdsn != session->max_cmdsn && !iscsi_sna_lt(max_cmdsn, session->max_cmdsn)) { session->max_cmdsn = max_cmdsn; /* * if the window closed with IO queued, then kick the * xmit thread */ if (!list_empty(&session->leadconn->cmdqueue) || !list_empty(&session->leadconn->mgmtqueue)) iscsi_conn_queue_work(session->leadconn); } } Once iscsi_conn_queue_work() is invoked here to start process context execution of iscsi_xmitworker() -> iscsi_data_xmit() code, AFAICT there is no logic in place within iscsi_data_xmit() to honor the last received MaxCmdSN. Or to put it another way: what is preventing iscsi_data_xmit() from completely draining both conn->cmdqueue + conn->requeue, even when the CmdSN window has potentially been closed again..?If the window was not big enough we would have not accepted the cmd from scsi-ml in iscsi_queuecommand. We would have never put it on the list above then.
Oh yeah, if you are asking yourself why that code exists then, it is because we used to internally queue cmds when the window closed. In iscsi_data_xmit we then checked the window like in your patch. We switched to having the scsi layer queue for us, but that code above got left there.
Or sent a patch the other day to remove it: http://marc.info/?l=linux-scsi&m=138288022619303&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
