Mike Christie wrote:
> We were discussing this on the fcoe list, and I mentioned it here on the 
> scsi cmd timer patch. What I thought we might want to do is instead of 
> doing it based on cmdsn window rejects which can sometimes be static, we 
> can take into account how often commands are timing while they are still 
> pending. For example if a cmd is still pending and the scsi command 
> timer fires, then can_queue is probably too high at that time.
> But we probably also need to check the cmdsn window rejects, because I 
> think that can also change on some targets. So it can be separate 
> patches, and I am not against what you are trying to do.

Actually, I am not sure what it is buying us except extra complexity 
just so we can avoid a debug printk. What is the reason for the 
threshhold code? In your previous patch you just set the can_queue to 
the cmdsn window size, which seemed fine except the window size could be 
larger than the number of commands that user had set for 

> We could also then add some code to try and dynamically increase it like 
> Vasu is doing for the device queue_depth. This can_queue rampup would be 
> for the target port resources/limitations instead of Vasu's device one.

Oh yeah, just to be clear when I say can_queue I sometimes meant both 
and sometimes just mean one or the other. The host port can be connected 
to multiple target ports. Then the target port could be connected to 
multiple initiator ports. Some of the ports can be on the same target or 
initiator, but they can also be on completely different boxes, so you 
end up with both the host and target can_queue limits fluctuating for 
different reasons. In the end I think you would want to handle both.

For the target can_queue you could do something where we never send more 
than cmdsn window commands, then you could time commands and track if it 
was taking longer or shorter with different number of commands and you 
cold track if cmds were timing out, and depending on the results you 
could increase/decrease the target can_queue similar to what is done 
with the fc drives and the device queue_depth.

We would want to do something similar for the host can queue too, and 
then also we will want to hook into Vasu's device queue_depth 
rampup/down code as well. Also did you try the QUEUE_FULL patch I sent 
with the MSA target?

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 
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to