On 07/22/2009 12:00 PM, Mike Christie wrote:
>> No, wrong. The check in queuecommand is by no means relevant
>> to the actual window.
>> We're checking the target window at the time queuecommand is run,
>> but we're _generating_ the CmdSN only much later after we've
>> dequeued the command.
>
>
> The check in queuecommand is for scsi cmd pdus and checks the
> session->queued_cmdsn against the MaxCmdSn. The queued_cmdsn is just a
> preallocation of CmdSn values. So if the scsi layer sends us X commands,
> the initiator checks if the window has X spaces open. If it does, then
> we add the task to the cmdqueue, and increase queued_cmdsn. This is
> supposed to prevent the scsi layer from sending us too many commands and
> them sitting in the driver cmdqueue and timing out.
>
> The cmdsn is then allocated when we put the cmd on the wire. So the
> session->CmdSn should always be lower than the MaxCmdSn value (as long
> as the MaxCmdSn value does not suddenly decrease on us (it cannot do
> that can it?)), because the session->queued_cmdsn value is always lower
> than the MaxCmdSn.
>

Here is an example of what I am seeing when I run the code.


- Login done and we are in FFP.
iscsi_conn_start()
{
        session->queued_cmdsn = session->cmdsn;
}

(here session->cmdsn is probably 1 and MaxCmdSn we will say is 4)

- The scsi layer then sends a scsi command. queuecommand checks 
queued_cmdsn(1) < MaxCmdSn(4). It is ok so it gets incremnted to 
queued_cmdsn = 2.

The queuecommand does queue_work to wake the xmit thread.

- Let's say the scsi layer is really quick. And calls the queuecommand 
again. queuecommand checks queued_cmdsn(2) < MaxCmdSn(4). It is ok so it 
gets incremnted to queued_cmdsn = 3.


- Let's say the scsi layer is really quick. And calls the queuecommand 
again. queuecommand checks queued_cmdsn(3) < MaxCmdSn(4). It is ok so 
gets incremnted to queued_cmdsn = 4.


- Let's say the scsi layer is really quick. And calls the queuecommand 
again. queuecommand checks queued_cmdsn(4) < MaxCmdSn(4). Window is not 
open so queuecommand requeus command.


- Now the xmit thread finally wakes up. It takes a task from the 
cmdqueue, and preps it. This does

hdr->cmdsn = session->cmdsn;

So here hdr->cmdsn and session->cmdsn is 1;

Then we do

session->cmdsn++

so the session->cmdsn is now 2;


- we loop in the xmit thread and it takes a task from the cmdqueue, and 
preps it. This does

hdr->cmdsn = session->cmdsn;

So here hdr->cmdsn and session->cmdsn is 2;

Then we do

session->cmdsn++

so the session->cmdsn is now 3;

- we loop in the xmit thread and it takes a task from the cmdqueue, and 
preps it. This does

hdr->cmdsn = session->cmdsn;

So here hdr->cmdsn and session->cmdsn is 3;

Then we do

session->cmdsn++

so the session->cmdsn is now 4;

- We now return from iscsi_data_xmit because there was only 3 cmds 
queued and there is nothing left on the cmdqueue list.

- Now when the the window opens and iscsi_update_cmdsn will update the 
session->max_cmdsn. At this point we should call something like 
scsi_run_queue but we don't. We wait for a scsi cmd to complete and then 
the scsi_done/scsi_io_completion completion path will run the scsi 
queues again.

And so we start again, but with a higher MaxCmdSn.



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to