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
Maybe this is causing some confusion. We do not increment the cmdsn value for immediate commands (how we send a tmf or nop) and for data-out pdus. We only increment it for scsi cmd pdus, so the only place I check for the window having space is in queuecommand. If you are worried about a nop or data out increasing the cmdsn value in one thread and a scsi cmd pdu increasing it in another, then it will not happen. We only this one path to worry about. > 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. > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
