On Tue, 2013-11-12 at 09:27 +0200, Or Gerlitz wrote: > On 12/11/2013 06:34, Nicholas A. Bellinger wrote: > > 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..? > > Guys, > > Note that the iser initiator transport uses the pass-through command > submission mode of libiscsi, that is > iscsi_conn_queue_work isn't called from queuecommand at all. > > This is b/c we call iscsi_host_allocwith xmit_can_sleep = 0. Hence no > workqueue is used for the command processing/submission over the wire, > just a call toiscsi_prep_scsi_cmd_pdu and following that to iser's > xmit_task callbackwhich isiscsi_iser_task_xmit that calls > iser_send_command, etc.
Grrrr, managed to miss the fact that iser is using xmit_can_sleep=0, and avoids iscsi_data_xmit() processing all together.. > Mike, Nic is not using the new locking framework patches for libiscsi, > as you know they are not upstream > yet... > In any event, back to debugging then.. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
