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 node.session.cmds_max. > > 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
