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.
Mike, Nic is not using the new locking framework patches for libiscsi,
as you know they are not upstream
yet...
Or.
--
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
