On Wed, 2008-01-23 at 19:22 -0800, Roland Dreier wrote: > So thinking about this some more... does it make more sense to leave > our can_queue alone, use scsi_adjust_queue_depth() to limit the queue > to the initial request limit,
I don't think we can use scsi_adjust_queue_depth() -- that's used per scsi_device (ie, LUN), and is not the host's overall queue depth. When not using tagged queuing, it looks to be equivalent to cmds_per_lun. > and then add a .change_queue_depth > method so that the user can adjust the queue depth via the standard > scsi sysfs entry? I like the idea of being able to tune this on the fly via sysfs, but I'm not sure what to call it, since the mid-layer already registers a "can_queue" file which is read-only. Other than that, it looks possible to just update can_queue at will, as long as we make sure it is >= 1 and we can accept a few extra commands in flight until the queue drains below the new setting. Ideas? There's another reason to have some ability to change can_queue, either dynamically or at add-target time -- there are some devices out there that report a slightly inflated initial credit limit, which lets us drive into unspecified territory. I expect there to be a fix released soon, but not everyone will be able to upgrade and will need to limited the queue length manually to stay out of trouble. -- Dave Dillow National Center for Computational Science Oak Ridge National Laboratory (865) 241-6602 office _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
